Late for the train

[Alex Buckley]

On 7/19/2012 3:02 PM, mark.reinhold at oracle.com wrote:
> 2012/7/19 12:57 -0700, daniel.latremoliere at gmail.com:
>> ...
>>
>> 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.
>
> Superpackages aren't quite that simple, I'm afraid.  (I'm sure Alex
> could say more ...).

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