In above replace "modular" and "un-modular" with "dynamic", "not-dynamic".
- Ray On Fri, Mar 11, 2016 at 11:23 AM, Raymond Auge <raymond.a...@liferay.com> wrote: > 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) > -- *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
