👍👍😎😎 Luís Carlos Moreira da Costa OSGi, Eclipse, D and Android Evangelist Representative Eclipse Regional Communities Brazil OSGi Alliance Supporter OPAL SWT Widgets Committer RoboVM Committer http://eclipsebrazil.wordpress.com Em 11/03/2016 11:09, "Peter Kriens" <peter.kri...@aqute.biz> escreveu:
> I think the scope of OSGi is quite different from the scope of Jigsaw. > Jigsaw is oriented towards the VM’s modularity to minimize the footprint > and incrementally load the VM, OSGi is about how to architect an > application. > > Jigsaw OSGi Difference > module bundle Jigsaw modules are too closed for third parties that need > access to classes, e.g. a CDI provider > packages packages OSGi uses an advanced package wiring model with > extensive checks (uses constraints), Jigsaw’s is quite primitive and not > supporting multiple version > serviceloader service Jigsaw is about classes, OSGi is about (configured) > instances > > The major difference is that the Jigsaw modules are as minimal as it gets. > In OSGi, the bundle model enables the extender pattern. A pattern where a > bundle provides functionality based on another bundle’s content. Again, for > example a CDI like mechanism as OSGi’s Declarative Services. Similar for > services. Jigsaw provides the class loader hack they call Service Loader > that only provides access to a service class. OSGi provides access to > service instances, which is MUCH more modular, flexible, easier, and more > powerful in all aspects. > > The recent history in Jigsaw is excellent for OSGi because it clearly > demonstrates that what OSGi was blamed for is actually too often a problem > inherent in modularity. Modularity is about fencing your code. However, > fencing your code is trivial. Just like security, a perfectly secure device > is trivially to make. However, it is not useful because it won’t do > anything. If you do not provide ‘holes’ then nothing can get executed. In > Jigsaw they clearly were missing some of the necessary holes to make even > the most simple Java program work. A helper like CDI could not work because > it could not get access to the classes (and thus) annotations of another > module. (Might have changed since I looked.) In practice this is worse, > since any class loading hack in the Java universe (and that is a lot of > hacks) will fail with the current Jigsaw module design. We’ve been blamed > for these fails but it is clear that it is not OSGi. Jigsaw is now going > through the process where they have to design the required holes without > throwing away the benefits of modularity. However, it will also become > clear that many of the ubiquitous Java class loading hacks are > fundamentally problematic. It will be interestingly to see how long it will > take to come with a solution for this, and what that solution is going to > look like. Will they do it right (which breaks a LOT of existing code, as > we did) or buckle and throw away the benefits of modularity? Whatever > happens, I am pretty sure we will be vindicated > > Taking a step back. The essence of modularity is “not knowing”. The more > ignorant your code is to more places where it can live. It is all about > high cohesiveness and low coupling. If there is one thing I’m pretty > satisfied with in the OSGi is the fact that we’ve made that message quite > clear, the OSGi specifications are very alone at the top with respect to > these principles. The Java 9 dilemma you sketch is a perfect illustration > of these principles. The litmus test is really what happens when Java 9 (or > 10) will provide new useful features. Do you have to change your bundles to > leverage them or can they be leveraged without any effort on your side? I > think that bundles that leveraged the cohesion and coupling lessons we’ve > taught will give you a resounding yes. And I think Neil showed that once > Jigsaw provides useful features we can leverage those features (like the > extra protection level) without you having to change your code. > > I am not the official OSGi voice. However, I’ve been influential in the > past. I will do my utmost to leverage Java 9 (or 10, or 11, or 99) where it > makes sense. We are part of the Java eco system and we must leverage what > is out there as long as it makes technical sense. > > So what to do? Well,you asked a biased person :-) Use OSGi to the hilt, as > we show in OSGi enRoute. Write your code in a no-compromise way: OSGi > services everywhere. I am pretty confident then that you code will run on > Java 42 AND leverage the oh so cool features of Java 42 when possible. > > Kind regards, > > Peter Kriens > > > > > > > > > > > > > > > On 11 mrt. 2016, at 13:44, Milen Dyankov <milendyan...@gmail.com> wrote: > > Hello, > > can someone please point me to some resource that describes the plans for > OSGi / JSR 276 interoperability? > > I'm sorry if this has been already discussed here, I just joined the list > after trying without success to search through archives. I was also pretty > sure it would be easy to find this information online but it seams it's > either not available or I don't know how to find it. > > To put some more context to my question, at the moment I'm interested to > know how people who make decisions about OSGi's future, would describes the > general approach of building applications with Java9 and OSGi, rather than > discuss deep technical details. > > It seams to me that Penrose project is inactive (judging by source code > and mailing list activities) from around 2012/2013. Not that I'm very > familiar with it, but IIRC it was supposed to provide that > interoperability. From what I can tell, there is no much interest (if at > all) in this subject from the Java platform engineers. So, assuming Java 9 > will be released soon (let's just say 2017 is soon enough for long term > planning) what will be the recommended way to run OSGi on top of it? Would > one just continue to use classpath and ignore modulepath? If not, then are > there any plans for future versions of OSGi to allow to dynamically load > java modules? Will bundles need to be converted to java modules (perhaps > automatically behind the scenes) or vice versa? > > I would really appreciate it, if someone can share a vision of how would > one build applications with Java 9 and OSGi in the foreseeable future. > > Thank you, > Milen > > -- > http://about.me/milen > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
