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

[Andreas Sterbenz]

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.

Andreas.