Java EE 做了很多事情，但这并不是 Java EE 所解决的问题。 Jigsaw 项目充其量只是在解决同样的问题。 Java EE / OSGi 混淆的地方在于，大多数 OSGi 捆绑的早期采用者都是那些实现与 Java EE 中提供的某些库类似的功能的人。也就是说，实际的容器连接框架 (OSGi) 与捆绑功能无关（尽管某些发现在结构上进行了修改以符合 OSGi 捆绑要求）。
An OSGi bundle is more of a "software module" than a "jar", "war", or "ear" file. OSGi bundles rarely provide benefit if they bundle an entire application; however, they are very beneficial in the automation and correct handling of hooking up lots of libraries.
So consider the problem OSGi attempted to solve, and you will better understand where it fits. It is the Java equivalent of the "diamond inheritance" pattern from C++. You include two libraries, which each need a common logging library, but in this case it's not because of multiple inheritance, it's because of multiple include statements.
If the two libraries both work with the same version of the common logging library, you're in luck. If they don't, then to get each library working correctly independently, you need to load two copies of the same library, each which likely uses the same name spaces (and often the same class names).
OSGi is a means of bundling which allows two versions of the same library to be loaded which use the same name spaces, the same class names, but were created at different times. It also hooks up the "right" version to the "right" OSGi bundle, preventing a bundle from using the "wrong" release of the "right" library.
Java EE does a lot, but this isn't something that Java EE even addresses. At best, project Jigsaw was working on the same problem. Where the Java EE / OSGi confusion comes into play is that most of the early adopters of OSGi bundling were those who were implementing functionality similar to some of the libraries offered in Java EE. That said, the actual container-connection framework (OSGi) had nothing to do with the bundled functionality (although some of the discovery was structurally modified to comply with OSGi bundling requirements).
Comparing Java EE with OSGi is like comparing apples and oranges with the additional bonus of not knowing what is what.
Java EE focus is on scalable multi-tier business applications in heterogenous environments and enterprise wide integration of information systems.
OSGi started at another corner by integrating several independent codebases into one JVM (please excuse me for being extremely brief).
Of course some problems (e.g. hot deployment) are common to both environments - but to a varying degree.
Of course you can upgrade, downgrade and crossbreed both of them and they will meet somewhere in the middle.
So the question should not be "What benefit has A over B" but something like "In what field A has clear advantages over B and vice versa?" Let me rephrase that: "When do I need a hammer and when do I need a saw?"
I'm sorry but ALL answers here are completely laughable. Dependency version issues solved with OSGi? Pooooohlease.... Ever heard of class loader policies in app servers?
OSGi seems like an idea to keep selling new books and training, while the functional needs have been covered for eons by the JAR/EAR packaging & deployment in JEE. Those who buy into it simply never got to understand how they're being manipulated. There's also a question of trends and fashion. I.e. non-engineering considerations that are a shame to this industry.
Reinventing the wheel is profitable because there are tons of fools out there. Unfortunately, there are tons of management-type simpletons who want to be on the "bleeding edge of technology" who will gladly fund their employees' courses, absorb the learning curve, and then pay through their nose in "re-engineering" of things that had nothing wrong with them to begin with.
It's not a question of "am I to use a screwdriver of a hammer". It's more a question of "hey boss, there's this new thing out there called HEMMAR, and it's really cool!". "Isn't it a HAMMER?", "No no, it's waaaaay better, it's a HEMMAR, it's for driving nails into boards, it will revolutionize the world".
发布评论
评论（4）
OSGi 包更像是一个“软件模块”，而不是“jar”、“war”或“ear”文件。如果 OSGi 捆绑包捆绑了整个应用程序，那么它们很少能带来好处；然而，它们对于连接大量库的自动化和正确处理非常有益。
因此，考虑一下 OSGi 试图解决的问题，您将更好地理解它适合什么地方。它在 Java 中相当于 C++ 中的“钻石继承”模式。您包含两个库，每个库都需要一个公共日志记录库，但在本例中，这不是因为多重继承，而是因为多个 include 语句。
如果这两个库都使用相同版本的公共日志记录库，那么您很幸运。如果不这样做，那么为了让每个库独立正确工作，您需要加载同一库的两个副本，每个副本可能使用相同的名称空间（通常是相同的类名）。
OSGi 是一种捆绑方式，允许加载同一库的两个版本，它们使用相同的名称空间、相同的类名，但在不同的时间创建。它还将“正确”版本连接到“正确”OSGi 捆绑包，防止捆绑包使用“正确”库的“错误”版本。
Java EE 做了很多事情，但这并不是 Java EE 所解决的问题。 Jigsaw 项目充其量只是在解决同样的问题。 Java EE / OSGi 混淆的地方在于，大多数 OSGi 捆绑的早期采用者都是那些实现与 Java EE 中提供的某些库类似的功能的人。也就是说，实际的容器连接框架 (OSGi) 与捆绑功能无关（尽管某些发现在结构上进行了修改以符合 OSGi 捆绑要求）。
An OSGi bundle is more of a "software module" than a "jar", "war", or "ear" file. OSGi bundles rarely provide benefit if they bundle an entire application; however, they are very beneficial in the automation and correct handling of hooking up lots of libraries.
So consider the problem OSGi attempted to solve, and you will better understand where it fits. It is the Java equivalent of the "diamond inheritance" pattern from C++. You include two libraries, which each need a common logging library, but in this case it's not because of multiple inheritance, it's because of multiple include statements.
If the two libraries both work with the same version of the common logging library, you're in luck. If they don't, then to get each library working correctly independently, you need to load two copies of the same library, each which likely uses the same name spaces (and often the same class names).
OSGi is a means of bundling which allows two versions of the same library to be loaded which use the same name spaces, the same class names, but were created at different times. It also hooks up the "right" version to the "right" OSGi bundle, preventing a bundle from using the "wrong" release of the "right" library.
Java EE does a lot, but this isn't something that Java EE even addresses. At best, project Jigsaw was working on the same problem. Where the Java EE / OSGi confusion comes into play is that most of the early adopters of OSGi bundling were those who were implementing functionality similar to some of the libraries offered in Java EE. That said, the actual container-connection framework (OSGi) had nothing to do with the bundled functionality (although some of the discovery was structurally modified to comply with OSGi bundling requirements).
将 Java EE 与 OSGi 进行比较就像比较苹果和橘子，但还有一个额外的好处就是不知道什么是什么。
Java EE 的重点是异构环境中的可扩展多层业务应用程序以及企业范围内的信息系统集成。
OSGi 从另一个角度开始，将几个独立的代码库集成到一个 JVM 中（请原谅我说得太简短了）。
当然，一些问题（例如热部署）对于这两种环境来说都是常见的 - 但程度不同。
当然，你可以升级、降级和杂交它们，它们会在中间的某个地方相遇。
因此，问题不应该是“A相对于B有什么好处”，而应该是“在哪些领域A比B有明显的优势，反之亦然？”让我重新表述一下：“我什么时候需要锤子，什么时候需要锯？”
Comparing Java EE with OSGi is like comparing apples and oranges with the additional bonus of not knowing what is what.
Java EE focus is on scalable multi-tier business applications in heterogenous environments and enterprise wide integration of information systems.
OSGi started at another corner by integrating several independent codebases into one JVM (please excuse me for being extremely brief).
Of course some problems (e.g. hot deployment) are common to both environments - but to a varying degree.
Of course you can upgrade, downgrade and crossbreed both of them and they will meet somewhere in the middle.
So the question should not be "What benefit has A over B" but something like "In what field A has clear advantages over B and vice versa?" Let me rephrase that: "When do I need a hammer and when do I need a saw?"
我很抱歉，但这里的所有答案都是完全可笑的。 OSGi 解决了依赖版本问题吗？ Poooooohlease...听说过应用程序服务器中的类加载器策略吗？
OSGi 似乎是一个不断销售新书和培训的想法，而功能需求已经通过 JAR/EAR 包装和版本满足了亿万年。在 JEE 中部署。那些相信它的人根本无法理解他们是如何被操纵的。还有一个趋势和时尚的问题。即非工程考虑对这个行业来说是一种耻辱。
重新发明轮子是有利可图的，因为那里有很多傻瓜。不幸的是，有大量的管理型傻瓜想要处于“技术的前沿”，他们会很乐意资助员工的课程，吸收学习曲线，然后在事物的“重新设计”中付出高昂的代价他们本来就没有什么问题。
这不是“我该用螺丝刀还是锤子”的问题。这更像是一个“嘿老板，有一个叫做 HEMMAR 的新东西，它真的很酷！”的问题。 “这不是锤子吗？”，“不，不，它更好，它是 HEMMAR，它用于将钉子钉入木板上，它将彻底改变世界”。
I'm sorry but ALL answers here are completely laughable. Dependency version issues solved with OSGi? Pooooohlease.... Ever heard of class loader policies in app servers?
OSGi seems like an idea to keep selling new books and training, while the functional needs have been covered for eons by the JAR/EAR packaging & deployment in JEE. Those who buy into it simply never got to understand how they're being manipulated. There's also a question of trends and fashion. I.e. non-engineering considerations that are a shame to this industry.
Reinventing the wheel is profitable because there are tons of fools out there. Unfortunately, there are tons of management-type simpletons who want to be on the "bleeding edge of technology" who will gladly fund their employees' courses, absorb the learning curve, and then pay through their nose in "re-engineering" of things that had nothing wrong with them to begin with.
It's not a question of "am I to use a screwdriver of a hammer". It's more a question of "hey boss, there's this new thing out there called HEMMAR, and it's really cool!". "Isn't it a HAMMER?", "No no, it's waaaaay better, it's a HEMMAR, it's for driving nails into boards, it will revolutionize the world".
大多数主要好处，至少是我们使用 OSGi 的原因，都列于 http://karaf.apache.org/ ，特别是前两个。
此外，OSGi 联盟还有很多好处：https://www .osgi.org/developer/benefits-of-using-osgi/。
Most of the major benefits, at least the reasons we use OSGi, are listed at http://karaf.apache.org/, notably the first two.
Additionally, the OSGi alliance has a long list of benefits: https://www.osgi.org/developer/benefits-of-using-osgi/.