[jsr294-modularity-eg] Simple Module System Proposal
Alex.Buckley at Sun.COM
Wed Sep 30 17:21:07 EDT 2009
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,
> > 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.
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.
More information about the jsr294-modularity-eg