[jsr294-modularity-eg] Simple Module System Proposal

Mon Sep 14 17:17:27 EDT 2009

Following this line of reasoning, it would appear that you would also  
believe that one choice is simpler than two and that where the  
specifications for that one were recorded were, in fact, also  
irrelevant.  Is that an option?

JC (Mobile)

On Sep 14, 2009, at 4:01 PM, "Bryan Atsatt" <bryan.atsatt at oracle.com>  
wrote:

> 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
>> 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
>>
> _______________________________________________
> 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/2f7e1f5c/attachment-0001.html>