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

[Michal Cierniak]

On 10/24/07, Andreas Sterbenz <Andreas.Sterbenz at sun.com> wrote:
> Michal Cierniak wrote:
> 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.

I understand this and this is what I meant by saying "no correctness
issues" although in hindsight I see that I wasn't clear.  Yes,
developers will not have to change existing programs.  But IMO this is
not a good reason for adding new keywords (even if they are
"restricted" and cause no conflicts with existing identifiers).  We
shouldn't add a feature just because we can prove that it will not
break existing programs.

Reading your message, your rationale seems to be this:

> 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.

I sympathize with this desire and I agree that those new keywords make
it more clear what the intention is.  But at the same time in my mind
there should be a high bar to adding new keywords.  I can live with
this though if all the other experts agree that adding restricted
keywords is a good idea.


> Do you have a concern regarding the addition of restricted keywords

The former.  But it is a *small* issue to me.


> 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).

Hmm...  I don't buy this.  Then why does Java use names like "class"
(or "package", "interface", "enum" etc) that before Java had
well-defined meanings quite different from the Java meanings of those
terms?  I think that the answer is that in general people prefer
existing words that are close in meaning to what you want to convey.
And "module" is an existing word that is close in meaning to what
JSR-294 wants to define.  Yeah, there may be some confusion the same
way that some people may confuse a Java class with, say, a Smalltalk
class but we would convey the idea much easier by using an existing
name than by making up a new word.

Both issues raised by me in this thread are minor, so we probably
shouldn't spend too much time on them and focus on bigger issues (if
any) that we find after reading the draft more carefully.

Michal