[jsr294-modularity-eg] Simple Module System Proposal

[Richard S. Hall]

Hey Bryan,

I would also add that you seem to be operating under the impression that 
we are still proposing a module system interoperation API, but we 
aren't. This is a concrete module system for Java to support, as Peter 
said, the "80% case", which we have discussed before as being JAR-to-JAR 
dependencies. That's it.

It is more of a side benefit (but a real benefit) if we do this in a way 
that the resulting "simple modules" can be used easily in Jigsaw, OSGi, 
NetBeans, etc. However, this is not interoperation, this is merely 
consuming "simple modules".

-> richard

On 9/10/09 13:16, Peter Kriens wrote:
> Bryan,
> Our key design goal for the SMS was to make 80% of the use cases 
> simple and the remainder possible. That is, make simple things simple 
> and allow more complex things.
>
> So there seem to be two possibilities:
>
>   - We have the wrong design goal, or
>   - We do not cover 80% of the use cases
>
> It is hard to see which of the two is your concern? If the coverage is 
> your concern, could you propose use cases that should fall under the 80%?
>
> That said, I am a bit surprised with your last paragraph. In this you 
> mention the following requirements:
>
>         Requirement                        Before            SMS
> Simple syntax                      annotations++     fixed keyword
> In a single file                   module-info       module-info
> Compile-time error checking        mod. system       compiler
> Fidelity with the runtime          mod. system       VM
> Semantics                          mod. system       JLS
> Extending the compiler             yes               no
>
> All these seem to be highly in favor of the SMS from a simplicity 
> point of view?
>
> Kind regards,
>
> Peter Kriens
>
> On 10 sep 2009, at 02:21, Bryan Atsatt wrote:
>
>> 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.
>>
>> 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. Interoperation is possible between the simple 
>> variants but not with the full ones. Compile time error checking is 
>> possible with the simple variants but not the others, resulting in a 
>> confusing, frail and ultimately unreliable feature.
>>
>> All so we can insist that a subset of module system semantics is 
>> written down in a 'language' spec? Where a single, tiny step beyond 
>> that subset forces a leap to a distant document/specification?
>>
>> The word "morass" comes to mind.
>>
>>
>> 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. If that means we have to point at separate documentation to 
>> define semantics, at least it will all be in one place.  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.
>>
>>
>> _______________________________________________
>> jsr294-modularity-eg mailing list
>> jsr294-modularity-eg at cs.oswego.edu 
>> <mailto: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
>    
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg