> On 11 mrt. 2016, at 16:50, 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" :)
Since 2005 … :-) I feel a bit desperate because what is there so far is
incredibly underwhelming …
> 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.
This has always been the problem. :-( That said, in this process I think we
will be vindicated because people will realize that OSGi is not difficult, real
modularity is difficult. I hope, pray, despair that people will then realize
the value of OSGi and make us all happy by making proper modules.
If Jigsaw modules will be packaged as proper modules, I am convinced we will be
able to load them. Dynamics is of course always going to be hard since no code
outside OSGi is designed for that.
> 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?
I think you see this right. That said, some of the murky details seem to allow
for a module manager though currently the API is too poor to do anything
useful. If this would be strong enough then we could probably do some stuff
dynamic. That said, we could of course always take the packaged Jigsaw module
and load it ourselves. Too many details are not clear yet but you can be
convinced that enough OSGi members will try to find the best solution.
> 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.
Though there have been hickups Java is actually pretty good in backward
compatibility. Of course if Java 42 has those hickups nobody can do anything
about that. I was referring to the modular aspects. Since OSGi allows you to
really hide yourself from the world it is much less coupled to the environment
than most non-OSGi code.
Hope this helps more …
Kind regards,
Peter Kriens
>
> Regards,
> Milen
>
>
>
>
>
> On Fri, Mar 11, 2016 at 3:09 PM, Peter Kriens <peter.kri...@aqute.biz
> <mailto: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
>> <mailto: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
>> <http://about.me/milen>_______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>
>
>
> --
> http://about.me/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
