Co-bundling for christmas

[Tom Eugelink]

> With jigsaw you have this feature whether JavaFX is bundled with the
> full JRE download&  update cycle or not. If you require 2.0.2 in your
> app and even if there's a 2.1, 3.0, ... available in your local module
> repo, you're app will resolve 2.0.2.
>
> It's like it is today if you'd use OSGi with the difference that using
> multiple versions of the same module in one application is not possible
> (or at least not all use cases are supported).
>

I read the JigSaw specs Mark released and this indeed seems to be the case. Basically it is Maven at runtime.

In the spec I see a lot of good things; modules are based on packages, there a concept of a view, which allows to subgroup dependencies for different contexts (e.g. JEE for web, JEE for JMS, etc).

But some things worry me as well; for example the dependency versions are specified using operators like > and <. But since (like Maven) version conflicts are resolved by using the highest version after resolving all dependencies, basically all dependency declarations actually are "this version or higher". So specifying = or < may pretty quickly cause problems. That is why Maven 3 AFAIK tries to get rid of version ranges; just specify the minimum required version of a dependency.

This approach means in real life that all artifacts must be 100% backwards compatible. This is something that puts a strain on developing a library. It would be good to be able to indicate a break in backwards compatibility, and be able to run these versions side-by-side. In Maven this is solved by starting a new artifact, and so you can end up with running a Artifact1 and Artifact2 (basically the same project) side by side. Not a pretty solution IMHO.

Now, I can understand that running things side by side seems like a big problem, if one were to have to do this from scratch, but a tried and tested implementation is available. Knowing that the Java team is not very fluent in the whole area of dependency and modularization (since they don't even support Maven), I am curious / afraid if I'm detecting a slight hint of "not invented here" concerning a.o. OSGi.

Future will tell.

Tom