[jsr294-modularity-eg] Simple Module System Proposal

[BJ Hargrave]

> Thanks Peter. In a nutshell, you're saying the simple module system is 
> the Reference Implementation of JSR 294.

I think it is more correct to say JSR 294 specifies the Simple Module 
System. The RI for JSR 294 could just implement the Simple Module System. 
The RI could also be Jigsaw(runtime) and javac(compile-time). Jigsaw will 
have many more features beyond those specified in the Simple Module 
System. But any modules developed to conform to the Simple Module System 
specification can be deployed on Jigsaw as well as other module systems 
which will provide support for the Simple Module System specification.

> 
> At compile-time, modifications to javac already provide simple module 
> system functionality. javac uses a modulepath to determine module 
> membership - I think everyone liked that - and performs very simple 
> resolution on dependencies in module-info.java to set up the compilation 

> environment. There are no class loaders at compile-time so only one 
> version of a module is visible to code being compiled. It's not 
> analogous to the simple module system proposal at runtime, but it's 
> better than classpath because javac can ban split packages in visible 
> modules.
> 
> This raises the question: who determines what is "in" a visible module? 
> I expect javac could use Jigsaw metadata, if present, to determine the 
> answer. 

I would assume that javac would use the Simple Module System metadata to 
make this determination since javac would be the reference implementation 
of the compiler portion of the Simple Module System in the JSR 294 spec. 

> A Jigsaw local dependency allows a physically split package to 
> be logically unsplit; the contents of multiple physical modules become 
> the content of one logical module. javac could work at the logical 
> level, resolving classes in the same package against different physical 
> modules unified through local dependencies. An OSGi-aware compiler could 

> do the same for fragment bundles.

javac providing support for Jigsaw modules is beyond the specification of 
the Simple Module System. 

> 
> Just trying to find the boundary between the simple module system 
> (assuming it is indeed 'physical') and other module systems.
> 
> At runtime, it is attractive to initially rely on a simple class loading 

> model and then refine it with Jigsaw/OSGi-specific metadata as your 
> application grows. But why one class loader per module in the simple 
> module system? It will cause great headaches for legacy code. One class 
> loader per application would be far more familiar. Don't underestimate 
> the learning curve already coming from dependencies and versioning.

One class loader per module is the easiest mapping. It is a mapping that 
is already supported by Jigsaw and OSGi. Other M:N mappings (where either 
M or N can be 1) require some metadata to be defined to establish the 
mapping. This metadata will be brittle and quickly become out of date if 
it is maintained in the modules. If it is kept outside of the modules, 
then it is another artifact to be defined and managed.

Given that the Simple Module System has wide visibility (no export package 
like restricted visibility), I am not sure there will be a difficult 
situation for users. If module A declares it depends upon module B, then 
module A has full visibility to module B. 

There will of course be applications which will require modifications to 
move onto the Simple Module System. But they will likely require changes 
to move to any system providing any amount of modularity. For those 
applications, they can of course continue to run using the traditional 
flat classpath.

> 
> Alex

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave at us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-observer/attachments/20090909/c49e4b2a/attachment.html>
-------------- next part --------------
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg