[jsr294-modularity-eg] New keywords and "superpackage"
Andreas.Sterbenz at Sun.COM
Wed Oct 24 19:00:25 EDT 2007
Michal Cierniak wrote:
> 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
Strictly speaking, we are not adding new keywords to the language. The
grammar includes productions that use certain character sequences such as
"export". We have termed them "restricted keywords", but they are not
keywords and can still be used as identifiers elsewhere in the program
(see 7.4.5 in the spec).
In other words, this is very different from JDK 5, where "enum" was made a
keyword. Restricted keywords have no impact at all on existing Java
programs. Developers will NOT have to change their programs to make them
compile again if they used "export" or "superpackage" as e.g. a variable
name or a type name.
> 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).
Given that adding restricted keywords does not cause compatibility issues,
we believe the main concern is readability of the code. Readability seems
better when we can use appropriate terms than when we have to repurpose
existing keywords. For example, by making "public" mean "export" in a
superpackage file. It is of course arguable if the current choice of
restricted keywords and the current syntax is the best we can do.
Do you have a concern regarding the addition of restricted keywords or the
current choice of terms?
> 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.
The danger with using an existing term that has a defined meaning (for
some audiences) is that it may cause more confusion than it helps. In
particular, "module" is used by JSR 277, but using superpackages does not
imply using 277 modules, nor does using 277 modules imply that they are
based on superpackages (although I expect that in most cases they will be).
> 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.
Java has an existing concept of modularity by using packages. The JLS just
does not use that term, presumably at least in part for historical
reasons. Alex may have more to say about this.
More information about the jsr294-modularity-eg