[jsr294-modularity-eg] New keywords and "superpackage"

[Michal Cierniak]

Like Bryan I haven't had time to fully review the draft but skimming
it I noticed one small issue: is it really necessary to add new
keywords to the language?  I browsed the draft really quickly, so I
might have missed it but I think that there is no discussion of pros
and cons of new keywords in the draft.  Can you provide a rationale
for adding new keywords?  My intuition is that we should add new
keywords to an existing, wide-spread language only if necessary (and
yes, I understand that there are probably no correctness issues).

On a related note, why do you call this construct a "superpackage"?
Until now I assumed that this weird term was coined to avoid adding
new keywords and to combine existing "super" and "package" keywords.
But apparently my rationalization of this term was wrong since you're
adding new keywords.  Why wouldn't we call this new construct using an
existing word.  "Module" comes to mind but certainly other words could
be used.

Strangely enough the title of JSR-294 includes the word "modularity"
but my quick scan of the draft didn't find any uses of words "module"
or "modularity".  I might have missed some references or you
intentionally chose to not use those terms.  Can you comment on this a
bit?  The original text of JSR (http://jcp.org/en/jsr/detail?id=294)
introduced the term "superpackage" but at least the word module was
used there extensively to explain the proposed feature.

Michal

On 10/22/07, Andreas Sterbenz <Andreas.Sterbenz at sun.com> wrote:
> [My earlier mail seems to have been lost, resending...]
>
> Experts,
>
> reminder to send us your comments about the draft spec by next Monday
> October 29. After this expert group review, we should proceed to JCP Early
> Draft Review so that we can gather feedback from the larger community.
>
> Andreas.
>
> Andreas Sterbenz wrote:
> > Experts,
> >
> > based on our earlier discussions Alex and I have prepared a draft
> > specification for Superpackages. It consists of updates to the Java
> > Language Specification, the Java Virtual Machine Specification, and the
> > reflection API.
> >
> > The specification reflects our past discussions in the EG, except in a few
> > cases where we are suggesting changes based on our experience in the
> > prototype implementation. For example, we changed the proposed name of the
> > compiled superpackage file from super-package.spkg to super-package.class.
> > That should avoid some tool compatibility issues and makes more sense
> > given our later decision about the file format. We have also allowed a
> > Java source file (compilation unit) to optionally identify which
> > superpackage its types are in. There are some minor updates to the
> > reflective API: the addition of SuperpackageFormatError and the method
> > Superpackage.forName().
> >
> > You can find the documents on the EG page,
> > http://jcp.org/en/eg/view?id=294 . We believe these drafts can serve as
> > the basis for the JCP Early Draft Review.
> >
> > We would appreciate if you could send us your comments by Monday, October 29.
> >
> > Alex and Andreas.
> > _______________________________________________
> > jsr294-modularity-eg mailing list
> > jsr294-modularity-eg at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>
>