Late for the train

[Daniel Latrémolière]

Le 20/07/2012 01:54, Alex Buckley a écrit :
> Package-private access control works by a) embedding package identity 
> in class declarations at compile-time (good enough for a compiler), 
> and b) augmenting that package identity at runtime by recording a 
> type's defining class loader (necessary for the JVM to avoid type 
> spoofing).
>
> Module-private access control would work by a) embedding module 
> identity in or near class declarations at compile-time, and b) 
> reifying that module identity when class loaders define classes. 
> (Notice I've said nothing about module dependencies or locating types 
> by searching graphs rather than linear classpaths.)
>
> (a) is a big topic that goes far beyond storing a module name/version 
> in a JAR manifest. Because the compiler needs to know every type's 
> module membership (module name _and_ version), and assuming you want 
> to compile multiple modules in one compiler invocation, and assuming 
> you might start compilation with only sources (not JARs), it becomes 
> necessary to rework your Java compiler - a lot. The "Modules and 
> javac" presentation on the OpenJDK Project Jigsaw page goes into detail.
>
> (b) is actually a fairly small topic. Since class loaders are god-like 
> in their power, they can associate defined classes with module 
> identities as they see fit, and the JVM can enforce 
> same-module-identity checks on accessor and accessee. It's a small 
> matter of API design and JVM rule tweaking. Of course there needs to 
> be a "front-end" to direct class loaders to associate classes with 
> modules; JAR membership is fine.
>
> So module-private access control a.k.a. superpackages is somewhat 
> trickier at compile-time than runtime - the opposite of 
> package-private access control. There was a lot to like in Daniel's 
> assessment, but my observation is that if you're going to reify module 
> membership for access control, then you may as well go the whole way 
> and reify dependencies too - managed dependencies are the heart of 
> modularity and access control is merely the enforcement mechanism.
>
> Alex
I was only simply hoping for a simple solution for simple developers 
needing to make exactly one javac invocation per module and particularly 
avoiding cyclic dependencies between modules as a good practice (more 
difficult to evolve because needing co-evolution of cyclic modules and 
simpler after merging in only one module). Co-compilation of module 
would not be necessary if modules were compilable one by one (no cyclic 
dependencies).

Allowing extensions (like not standardized javac switches or annotations 
in a module-info.java containing only mandatory name-version) for 
beginning evaluation of more complex features, like co-compilation of 
modules, automatic dependencies management, global module configuration 
of bytecode tools like Findbugs, would be sufficient for preparing 
future features and test their future specification (replacing, only at 
this future release, the useful annotations from a org.openjdk.* package 
by a real language construct).

It was only a hope for a simple solution to begin improvements to source 
code quality (by one small step, not a big jump slow to be adopted). 
With a small feature added in release, there is much more real-world 
use-cases, creation of good practices (which seems to me to be more 
useful for prioritisation of good features than a big project not 
directly usable on a released stable JVM with vendor-specific 
annotations). For me, having module access control, even without a full 
module system seems to be more useful than having public access control 
with a comment not-to-be-used (and even only this feature is useful by 
itself, for me).

Thanks,
Daniel.