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
> <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
