You'll never be able to take for granted that un-modular code can easily be massaged to modular code.
This goes for Java modules which won't have been designed with dynamicity in mind... which will be all java modules built by the JVM team and everyone who doesn't take dynamicity to heart. The only approach that will be completely safe will be to use java modules on the module path and then take an approach like Neil's to "dynamically" generate a view of the world presented to an OSGi runtime which reflects that. Putting any random java module into an OSGi runtime will incur the same risk and/or techniques used to put non-osgi artifacts into osgi: 1) turn it an osgi bundle (risky, but we all do it sometimes and it _can_ work) 2) embed it in another osgi bundle (also risky, can also work with sometimes less pain than 1, but less benefits also) But note that both of these approaches NEVER come without risk. If you can't figure out a way to satisfy the un-modular code inside there's really nothing you can do about it. As Peter stated in his response, Jigsaw is NOT about dynamicity. OSGi is _totally_ about dynamicity so you can barely compare them to each other. You can pretty much only compare them on the packaging front and that's about it. Sincerely, - Ray On Fri, Mar 11, 2016 at 10:50 AM, Milen Dyankov <milendyan...@gmail.com> wrote: > Thank you very much Peter, > > in fact I'm fully aware and I totally agree with your point of view (to > the point I have actually quoted you a number of times in the past). My > question however was a bit different and perhaps I didn't make myself clear > enough. It's not about should one use Java modules instead of OSGi or > compare the two. It's more reflecting the fact that Oracle is recently > trying hard to promote jigsaw as the right way to "architect an > application" :) Regardless how accurate that statement is, there will be > people that will choose to release their libraries as java modules only and > not OSGi bundles. Adding to that the fact that core JVM features are java > modules an important question seems to arise. Namely how to make use of > those in OSGi application. For example, let's say I have a OSGi bundle that > needs module X (that being either Java native module ot 3rd party only > available as such) and one wants to be able to dynamically install and > remove the bundle as needed. Would that mean that one will have to always > start java with module X on the module path? Or perhaps restart Java every > time a bundle is added to also add the java module? Needles to say this is > not what a OSGi developer would like. The other option I can imagine is to > make OSGi dynamically load java modules. To my understanding this is what > core Java engineers expect JavaEE to do by making use of layers > functionality. So I was wandering if OSGi Alliance’s plans go in that > direction? Also in this sense I disagree with the statement that if one > writes code properly it should work on Java 42. That would be the case if > Java was not introducing backward incompatible architectural changes. I'm > aware that for Java 9 one can still ignore modules and put everything on > "good" old classpath but then again this as well may change in the future. > > Regards, > Milen > > > > > > On Fri, Mar 11, 2016 at 3:09 PM, Peter Kriens <peter.kri...@aqute.biz> > wrote: > >> 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 >> > > > > -- > http://about.me/milen > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
