[jsr294-modularity-eg] Simple Module System Proposal
hargrave at us.ibm.com
Wed Sep 30 16:30:50 EDT 2009
> BJ Hargrave wrote:
> > > For the users I have in mind, multiple loaders and dynamism are
> > > cases, configurable through module-system-specific annotations.
> > The set of users you have in mind is not interested in modularity.
> > 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
> > 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". 
> 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 , 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
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?
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...
More information about the jsr294-modularity-eg