[jsr294-modularity-eg] Simple Module System Proposal

[Alex Buckley]

BJ Hargrave wrote:
> That is not my view or what I was saying. I am not claiming that all 
> applications can be partitioned into the 2 sets you list above. I was 
> saying that the set of users that you have in mind which are not willing 
> to deal with class loaders are also not willing to deal with real 
> modularity. That set of users may be quite content with named and 
> versioned jar files such as used in maven.

I find it much more likely that they will see the dependency and 
versioning features offered in the language and welcome it with open 
arms. That it is not "real" modularity (according to some Wikipedia 
definition) will matter not a jot. That it is not capable of multiple 
loaders will matter not a jot. A single loader is familiar to these 
users and we have a rich opportunity to enforce good versioning practice 
and a consistent class space from Day One. Maven uptake will, I suspect, 
suffer greatly.

>  > If Maven suffices for versioning and dependency tracking - not "real"
>  > modularity but still of some value, in your view - why does the Simple
>  > Module System claim the same ground by standardizing versions and
>  > dependencies in the language?
> 
> I claim that the purpose of JSR 294 was to define real modularity in the 
> langauge. From [2], which is referenced by the JSR page, we see 
> enforcement at runtime was an original requirement which SMS addresses. 

Runtime enforcement of module boundaries within and across class loaders 
is a given in 294, and we had made good progress on it pre-SMS.

> The point of taking the pain to change the language is to have real 
> modularty in the language. Doing only named and versioned jars can 
> easily be done without changing the language which could make it more 
> easily used by the exisiting universe of jars since they don't need to 
> be recompiled. But doing real modularity in the language will need 
> modules which are named and versioned. The SMS proposal suggests a 1-1 
> mapping of module to artifact(jar).

I completely agree that named and versioned modules are needed at 
compile-time and runtime, and that mapping them 1:1 to JARs is 
desirable. The only issue is whether SMS maps each module/JAR (doesn't 
matter since they're 1:1) to a common loader or a unique loader. I 
recommend the former for reasons given earlier, and exotic policies 
supported by other module systems can be requested in metadata.

Alex