Comment on state of Project Jigsaw

[Peter Kriens]

I think at JavaOne 2006 Gilad Bracha claimed that he did not trust the deployment engineers to touch his precious language and spun off JSR 294 from JSR 277 for exactly this reason :-)

And I actually now do agree with him after watching the story of Java modularity story for the last 6 years ... :-(

The purity of the separation between JLS and implementation of the environment has tremendous value in reducing conceptual complexity. Purity seems to have gotten a bad name but too many people are doing shortcuts only to get bitten later. Using a dummy class file's attributes to store Jigsaw data could be the archetypical example of Conway's law.

That said, I think there are two issues that are not always obvious to observers. 

First, Jigsaw attempts to address the class path assembly problem (maven, unix package dependency managers) and not the software complexity problem. It fights for split packages and module friends, clearly the antithesis of modularity as a tool to reduce software complexity. With Jigsaw it will be easy to call your existing code modular but it will provide few of its benefits since these benefits require unfettered encapsulation.

Second, confusingly the JLS already has modules, they're called packages ...  the only complaint I hear is about the granularity of packages, it is often too small. 

This could easily be fixed with a module concept that leverages the package/type namespace. I.e. it encapsulates a set of packages that are below it in the namespace. The normal access keywords plus an additional module keyword can then be used to encapsulate packages and types. 

	module org.foo;
		package bar;
			class Baz {}		org.foo.bar.Baz

One could call this concept super packages ... :-) Anyway, maybe in another life.

Kind regards,

	Peter Kriens








On 21 dec. 2011, at 19:33, Neal Gafter wrote:

> My main high-level comment on project Jigsaw is that is fails its first
> principle: modularity appears in the draft not to be a language construct,
> but at best a completely separate language from the Java programming
> language.  This appears to be an example of Conway's
> law<http://en.wikipedia.org/wiki/Conway's_Law>
> .
> 
> If you think this is the best approach, then it is not clear why it is
> described as part of the Java programming language at all.