DRAFT: Project Jigsaw: The Big Picture (part 1)

[Papick Garcia Taboada]

Hello Mark, hello all others reading here.

Sorry for my bad english, I am not a native speaker. I am just a brazilian java developer (living in old germany for 20 years now) that did in fact have to implement some modular applications/ architectures - sometimes at compiletime, sometimes at runtime. I did some OSGi, but mostly I got away with some maven or ivy magic on compile/ build time and spring components/ configurations at runtime. I am trying to follow news on jigsaw for a while now, but I was never involved in building something any close to a jvm. I even managed to build and showcase jigsaw lately here in a conference, but again, I am not a java rock star.

Unfortunately, I can't reply directly to the mail because I joined the mailing list too late. It was my understanding, that the jigsaw mailing list was for implementation matters only, not for discussing proposals/ requirements/ documents. So my reply comes out of thread.

Reading the "big picture" is see more questions than answers. I simply don't understand what this draft is for. It is titled big picture, but it is draft and part 1. There is no way to address such a topic in so few lines, so my apology if I am not getting it or reading wrongly between the lines. Besides, you have a draft 12 (I did miss the 11 other ones) requirement document online that would better fit the title "big picture".

The whole "we don't have a JSR" and we have some bits of information here and there is - IMHO - doing more damage than helping the cause. I share the 2008 visions (wouldn't it be cool(*), there is not a moment to loose, Mark, do you remember?). But meanwhile the world around java shifted surprisingly, and my focus is now on "there is not a moment to loose" and lesser on "wouldn't it be cool".

Here some thoughts. 

Big picture, the design principles:

(1) Modularity is a language construct
(2) Module boundaries should be strongly enforced
(3) Static, single-version module resolution is usually sufficient

Sounds good, but (1) is the whole point of adding modularization to the jdk, or we could just stick to OSGi. A modularization that is not enforced is not (read enforcement as explained here(**) ), so we all agree on (2). That we are going to need split packages loaded in a common class loader because of the mess in the jdk (see java.util package) goes against (2). From the requirements document, draft 12:

In support of platform modularization, it must be possible to declare that the types defined in a specific set of modules must be loaded by the same class loader.

But (3) is something that I really do not get. Again, from the requirements document:

Multi-version support should only be enabled when type collisions can be detected and reported as errors. This most likely means that it cannot be enabled for run-time linking since detecting collisions is nontrivial.

This most likely means?!? Seriously – just one version at runtime? The whole point of versioning and modularization is that we HAVE version collisions, and we are witnessing repackaging of all sorts circumventing our version conflicts. This is why we started using something like OSGi, despite of all the doing, tooling and architectural pain.

If we can have only one version resolved, we aren’t getting any better than with  ivy or maven dependency management and dependency mediation. By the way, the new Big picture is messing around with the terminology we are used to: from maven, spring – and somehow from common sense – we know „scopes“ as where to use the artifacts/ components (runtime, compile-time, test-time, etc.). Then we have different life cycles: maven defines a concise project lifecicle. Every single component model defines its own component life cycle, and regarding modules (at the same level of granularity) we have a bundle life cycle defined by OSGi. In this context, take a look at „Phases“ in the big picture…




  (*)  http://mreinhold.org/blog/cool
(**)  http://www.theserverside.com/feature/OSGi-Because-Sharing-Shouldnt-Be-Painful