[jsr294-modularity-eg] Simple Module System Proposal

[BJ Hargrave]

> BJ Hargrave wrote:
> >  > For the users I have in mind, multiple loaders and dynamism are 
edge
> >  > cases, configurable through module-system-specific annotations.
> > 
> > The set of users you have in mind is not interested in modularity. 
Just 
> > named and versions jar files which express dependencies on other named 

> > and versioned jar files. Having named and versioned jars files is fine 

> > and has proven useful to a large audience of maven users. But doing 
that 
> > does not require Java language changes and module-info source files. 
> > Putting a name and a version on a jar file does not make it a module.
> 
> If I may summarize: Applications are, in your view, either so simple as 
> to need only basic Maven-like functionality, or so complex as to need 
> dynamic visibility over multiple versions with strong encapsulation.

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. 

> 
> This echoes Peter's view that "Nobody needs modularity for a Hello World 

> program, and letting this use case drive the design seems plain wrong" 
> and "small applications do not have to bother with modularity". [1]
> 
> 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. 
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).

> 
> Alex
> 
> [1]http://www.osgi.org/blog/2009/06/classpath-hell-just-froze-over.html

It seems like the EG could make a fair amount of progress in coming to a 
better understanding of the SMS proposal if we could schedule an EG call. 
I have asked before for a call. We are not making any progress in the EG 
and I think a call will help. Can we please schedule an EG call?

[2] 
http://altair.cs.oswego.edu/pipermail/jsr294-modularity-observer/2009-January/000002.html


-- 

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-eg/attachments/20090930/bffe8014/attachment.html>