Late for the train

[Daniel Latrémolière]

> As some of you are already aware, I've concluded with regret that Project
> Jigsaw isn't going to make Java 8 as planned.  I've set out my reasoning
> in a blog entry [1], and I've asked the Java SE 8 EG to consider dropping
> the module system and modularization from the release [2].
I understand the choice of no modularity in JDK 8 and really hope to see 
a core profile of Java SE 8.

Would it be possible to see a reborn, in JavaSE 8, of JSR 294 
superpackages for modularity in user applications running on Java SE 8 
(not in code internal to JDK8). Having this would be useful for all 
developers and need mostly a new java.lang.reflect.Modifier for module 
access rights.

Currently package access right is already externally defined, because 
ClassLoader is responsible of loading and then choosing (modifying, 
removing or adding) classes of the package. With a module access right, 
a ModuleLoader (SuperPackageLoader) can define members of module 
(SuperPackage) and enforce access rights.

Only an unique identifier (organisation, name, version) of module need 
to be defined, by example in some attributes of the manifest of current 
JAR (without computing any dependencies resolution nor lifecycle 
management of module, by letting this to external tools if really used 
by the developer).

It would be useful for developers to have a clean border between 
potentially public API and always private parts of classes of module. 
This can already improve code quality, by removing access to some public 
API not to be called [1], by allowing methods on public classes but 
callable only from others packages of the same module, without being 
publicly callable.

In future, Jigsaw views can refine access to potentially public API (by 
selecting some views of it), but code with module access right will 
always be internal to module and used by nobody else.

Hoping for some modularity in source code, even without modularity in 
deployment,
Thanks,
Daniel Latrémolière.

[1]: 
http://wiki.eclipse.org/Naming_Conventions#Internal_Implementation_Packages