[jsr294-modularity-eg] Simple Module System Proposal
peter.kriens at aqute.biz
Thu Sep 10 13:16:24 EDT 2009
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
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?
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the jsr294-modularity-eg