[jsr294-modularity-eg] Simple Module System Proposal

[BJ Hargrave]

Hi Bryan. Thanks for joining the discussion.

> I agree with the idea of a standardized version syntax and with defining 

> semantics for the 'requires' directive (if possible :^); however, I 
> can't support this proposal. It trades off usability for a form of 
> purity, introducing considerable extra complexity for all non-trivial 
> use cases.

I am not sure I understand. The goal is to have the Java platforms specs 
(JLS, JVMS) have a complete module system specification. I don't know if I 
consider that purity as much as a good spec. Without defining something 
concrete, we are left with Java specs which rely upon others (e.g. Jigsaw 
project of OpenJDK, OSGi spec) to provide a complete story which is very 
bad for the Java platform specs.

> 
> This 'simple' proposal is anything but, turning two module systems into 
> *four*: simple-osgi, simple-jigsaw, full-osgi, full-jigsaw. Syntax is 
> common between the simple variants, but... bizarrely contorted 
> otherwise. 

I am not sure why you think there are four module systems here. There is 
the simple module system(SMS), OSGi and Jigsaw (plus whateever other 
module systems exist in the world). The proposal has Java specifying the 
SMS and having OSGi and Jigsaw support SMS artifacts. We define SMS to be 
simple, support 80% of peoples needs and be a subset of current module 
system features.

> Interoperation is possible between the simple variants but 
> not with the full ones. 

I don't think we are proposing an interop story. Just a module system spec 
whose artifacts can be used in other, more feature rich module systems.

> Compile time error checking is possible with the 
> simple variants but not the others, resulting in a confusing, frail and 
> ultimately unreliable feature.

It certainly is possible but is not part of the JLS. In the current 
proposal it would not be part of the JLS either as the delegation or 
processing the module info statements to a module system would be a 
compiler implementation detail. There is no reason a Java compiler, in 
addition to supporting the SMS specified module info statements, could not 
also support the module information for other module systems (e.g. Jigsaw 
or OSGi annotations, OSGi manifest header, etc.) But how that is done is 
not part of the JLS.

> 
> All so we can insist that a subset of module system semantics is written 

> down in a 'language' spec? 

It is a subset of the features of Jigsaw and OSGi, but nonetheless it 
should meet many people's needs. And allow the Java platform specs to be 
closed (that is, not require reference to external module system details.)

> Where a single, tiny step beyond that subset 
> forces a leap to a distant document/specification?

As opposed to always mandating a "leap"?

> 
> The word "morass" comes to mind.

I think the morass already exists. This proposal is an attempt to shrink 
to morass by providing a concretely specified module system that should 
meet many people's needs for modularity.

> 
> 
> I'm sorry if this all sounds harsh, but I'm in this to make modularity 
> more usable; to me this means simple syntax, in a single file, with good 

> compile-time error checking and fidelity with the runtime. 

That is exactly the purpose of the SMS proposal :-)

> If that means 
> we have to point at separate documentation to define semantics, at least 

> it will all be in one place. 

How will it be all in one place? The Java platform specs will state as set 
of things and then leave the reader to select Jigsaw or OSGi or some other 
module system to fill in the rest. With SMS, it is all one place, the Java 
platform specs, if SMS is sufficient for your needs.

> And if it means extending the compiler to 
> leverage module-system implementations, so be it; I'll be well satisfied 

> that we made the right tradeoff.

But the compiler hooks to support module system statement processing was 
never part of the JSR. It is and was compiler implementation detail beyond 
the Java platform specifications.

-- 

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/20090910/a2a3ce9e/attachment-0001.html>
-------------- next part --------------
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg