[jsr294-modularity-eg] Simple Module System Proposal

[Bryan Atsatt]

I missed that you intended SMS to be concrete; ok, so then we have three 
module systems. But that does not change my argument: for the sake of 
being able to write down partial module-system semantics in the JLS, we 
introduce a great deal of complexity. I question your 80% figure, but 
even granting it for the moment it seems to me that those same people 
would be just as well served by using a subset of Jigsaw or of OSGi, 
where they can then naturally and easily move to use more advanced 
features as required. Same descriptor syntax and file, same tool chain, 
same deployment artifacts, same runtime model: no major disruption when 
their needs stray beyond the lowest common denominator.

I don't think most people care where the rules for modularity are 
recorded, they just want to get their job done as simply as possible. 
And it is hard to see how three choices is simpler than two, especially 
when you consider the chasm that must be crossed when a transition is 
forced.




BJ Hargrave wrote:
> 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_ <http://www.osgi.org/>_
> __hargrave at us.ibm.com_ <mailto:hargrave at us.ibm.com> 	
>
> office: +1 386 848 1781
> mobile: +1 386 848 3788
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-observer/attachments/20090914/85984511/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