OSGi，Java模块化和拼图 [英] OSGi, Java Modularity and Jigsaw
问题描述
截至昨天早上，我对OSGi的情况一无所知。 OSGi 只是一些流行语，我一直看到它一遍又一遍地出现，所以我终于留出一些时间来刷它。
<它实际上看起来很酷，所以我想首先说明（对于记录）我在任何方面都不反OSGi，这也不是一个OSGi-bashing问题。 / p>
在一天结束时，似乎OSGi已经 - 基本上 - 解决了 JSR 277 ，它认识到 JAR 文件规范存在缺陷，可导致名称空间某些极端情况下的分辨率和类加载问题。 OSGi还做了很多其他非常酷的东西，但从我可以确定的，这是它最大的吸引力（或者其中之一）。
对我来说 - 作为一个公平的新的（现在几年）Java EE开发人员，我们在2011年并且目前生活在Java 7时代，并且这些类加载问题仍然存在，这绝对令人难以置信。特别是在企业环境中，一个应用服务器上可能有数百个JAR，其中许多依赖于彼此的不同版本，并且所有并发运行（或多或少）。
我的问题：
我对OSGi感兴趣，并且我想开始学习它，看看哪里/如果它可以用于我的项目，我就没有时间坐下来学习一些大的东西，至少现在。
所以当这些问题出现时，非OSGi开发人员应该做些什么？目前存在哪些 Java （Oracle / Sun / JCP）解决方案？为什么Jigsaw从J7切入？ Jigsaw明年将在J8实施的社区有多确定？即使它不是Java平台的一部分，是否有可能为你的项目获得Jigsaw？
我想我在这里问的是恐慌的组合，阴谋和一个facepalm。现在我终于明白了OSGi是什么，我只是不得到像Jigsaw这样的东西已经花了20多年的时间才实现，然后如何才能从一个版本中获得。 这看起来很基本。
而且，作为开发人员，我也很好奇我的解决方案是什么，没有OSGi。
此外，注意：我知道这不是纯编程 - 类型问题，但在你们之前让你的鼻子弯曲变形，我想说（再次，记录）我故意把这个问题放在SO上。那是因为我对SOERS同事一无所知，而且我正在寻找一些我每天潜伏在这里的IT之神的建筑级答案。
但是，对于那些绝对坚持的人来说，某个代码段支持SO问题：
int x = 9;
（感谢任何可以权衡这个OSGi / Jigsaw / classloader / namespace / JAR hell的人东西！）
首先要了解Jigsaw的主要用例是将JRE本身模块化。作为次要目标，它将提供可供其他Java库和应用程序使用的模块系统。
我的位置是类似 Jigsaw对于JRE来说可能是必要的，但如果被其他Java库或应用程序使用它会产生比它声称解决的问题更多的问题。
JRE非常困难和特殊情况。它已经超过12年了，是一个可怕的混乱，充满了依赖循环和荒谬的依赖。与此同时，大约有<900万的开发人员可能使用数十亿的运行系统。因此，如果重构会产生重大变化，你绝对无法重构JRE。
OSGi是一个模块系统，它可以帮助你（甚至强迫你你）创建模块化软件。您不能简单地在现有的非模块化代码库之上使用模块化。将非模块化代码库变为模块化代码库不可避免地需要进行一些重构：将类移动到正确的包中，使用解耦服务替换直接实例化等等。
这使得很难将OSGi直接应用于JRE代码库，但我们仍然需要将JRE拆分为单独的部分或模块，以便可以交付JRE的简化版本。
因此，我认为Jigsaw是一种极端措施，可以在分割JRE代码时保持JRE代码的存在。它确实不帮助代码变得更加模块化，并且我确信它实际上会增加进化使用它的任何库或应用程序所需的维护。
最后：OSGi存在，而Jigsaw尚不存在，可能永远不存在。 OSGi社区在开发模块化应用程序方面拥有12年的经验。如果您对开发模块化应用程序非常感兴趣，那么OSGi是城里唯一的游戏。
So as of yesterday morning I hadn't a clue as to what OSGi even was. OSGi was just some buzzword that I kept seeing cropping up over and over again, and so I finally set aside some time to brush up on it.
It actually seems like pretty cool stuff, so I'd like to start off by stating (for the record) that I'm not anti-OSGi in any respect, nor is this is some "OSGi-bashing" question.
At the end of the day, it seems that OSGi has - essentially - addressed JSR 277 on Java Modularity, which recognized that there are shortcomings with the JAR file specification that can lead to namespace resolution and classloading issues in certain corner cases. OSGi also does a lot of other really cool stuff, but from what I can ascertain, that's its biggest draw (or one of them).
To me - as a fairly new (a few years now) Java EE developer, it is absolutely mind-boggling that we are in the year 2011 and currently living in the era of Java 7, and that these classloading issues are still present; particularly in enterprise environments where one app server could have hundreds of JARs on it, with many of them depending on different versions of one another and all running (more or less) concurrently.
My question:
As interested as I am in OSGi, and as much as I want to start learning about it to see where/if it could be of use to my projects, I just don't have the time to sit down and learn something that large, at least now.
So what are non-OSGi developers to do when these problems arise? What Java (Oracle/Sun/JCP) solutions currently exist, if any? Why was Jigsaw cut from J7? How sure is the community that Jigsaw will get implemented next year in J8? Is it possible to get Jigsaw for your project even though its not a part of the Java platform yet?
I guess what I'm asking here is a combination of panic, intrigue and a facepalm. Now that I finally understand what OSGi is, I just don't "get" how something like Jigsaw has taken 20+ years to come to fruition, and then how that could have been canned from a release. It just seems fundamental.
And, as a developer, I am also curious as to what my solutions are, sans OSGi.
Also, Note: I know this isn't a "pure programming"-type question, but before some of you get your noses bent out of shape, I wanted to state (again, for the record) that I deliberately put this question on SO. That's because I have nothing but the utmost respect for my fellow SOers and I'm looking for an architectural-level answer from some of the "Gods of IT" that I see lurking around here every day.
But, for those of you who absolutely insist that a SO question be backed with some code segment:
int x = 9;
(Thanks to anybody who can weigh-in on this OSGi/Jigsaw/classloader/namespace/JAR hell stuff!)
First understand that Jigsaw's primary use case is to modularise the JRE itself. As a secondary goal it will offer a module system that may be used by other Java libraries and applications.
My position is that something like Jigsaw is probably necessary for the JRE only, but that it will create far more problems than it claims to solve if used by other Java libraries or apps.
The JRE is a very difficult and special case. It is over 12 years old and is a frightful mess, riddled with dependency cycles and nonsensical dependencies. At the same time is is used by approximately 9 million developers and probably billions of running systems. Therefore you absolutely cannot refactor the JRE if that refactoring creates breaking changes.
OSGi is a module system that helps you (or even forces you to) create software that is modular. You cannot simply sprinkle modularity on top of an existing non-modular codebase. Making a non-modular codebase into a modular one inevitably requires some refactoring: moving classes into the correct package, replacing direct instantiation with the use of decoupled services, and so on.
This makes it hard to apply OSGi directly to the JRE codebase, yet we still have a requirement to split the JRE into separate pieces or "modules" so that cut-down versions of the JRE can be delivered.
I therefore regard Jigsaw as a kind of "extreme measure" to keep the JRE code alive while splitting it up. It does not help code to become more modular, and I'm convinced that it will actually increase the maintenance required to evolve any library or application that uses it.
Finally: OSGi exists whereas Jigsaw does not exist yet and may never exist. The OSGi community has 12 years of experience in developing modular applications. If you are seriously interested in developing modular applications, OSGi is the only game in town.
这篇关于OSGi，Java模块化和拼图的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
