JDK-6519124 : RFE: Add Keyword Management
  • Type: Enhancement
  • Component: specification
  • Sub-Component: language
  • Affected Version: 6
  • Priority: P5
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-01-30
  • Updated: 2011-10-31
  • Resolved: 2011-10-31
Description
A DESCRIPTION OF THE REQUEST :
This proposal is a mechanism to allow API���s to be written that contain Java keywords that can still be called from Java, e.g. an API not written in Java. In addition new keywords can be added to Java without braking old code. The proposal is to name mangle a name that is a keyword if it is imported into the name space of a compilation unit (file) by either a "package" or "import" statement.

The idea is simple:

1. Add a new keyword ���source��� that gives the Java source version, e.g. ���source 6;��� would mean this file is written in Java 6.

2. The ���source��� keyword goes before the ���package��� statement and therefore  doesn���t break old code, since no statement could previously have been at this position in the file.

3. Any ���package��� or ���import��� statements that import a name into the files name space gets name mangled by putting an underscore either side, e.g. ���assert��� would become ���_assert_���.

4. If no source statement is given in a file then the source version is taken from the source switch on the command line, as it is at present. But note that name mangling still occurs and a source statement overrides a source switch.

5. The name mangling is two way, so that an API can be written in Java that uses a mangled keyword as a name that appears in the compiled class file but in the class file  the non-mangled name is used. Hence the JVM doesn���t see mangled names.

So for example suppose an API, from either an early version of Java or from some other language contained the name ���assert��� and this API was to be used in a Java 6 program, then:

  source 6;

  package ���;

  import ���; // imports something that contains "assert", e.g. an early JUnit API

    ���

    _assert_( ��� );

JUSTIFICATION :
With increasing use of languages other than Java on the JVM it is inevitable that some Java keywords will be used by APIs written in these non-Java languages and therefore these APIs will be unusable from Java, e.g. an API with a method called ���final���. Also there are increasing calls to enhance Java and because of backward compatibility concerns these proposed enhancements are handicapped because they cannot introduce new keywords to support the enhancements.


CUSTOMER SUBMITTED WORKAROUND :
1. For an API that contains a Java keyword you can write a wrapper, in a language other than Java that does not use that particular keyword, which translates the API into something that Java can use.

2. If the source and a suitable compiler is available the API can be refactored to avoid the keyword, this is what happened to JUnit, which originally used ���assert���.

3. In the case of extensions to Java symbols can be used instead of keywords. This looks odd in Java that has a tradition of unabbreviated keywords and is a barrier to readability. The readability issue is why Java uses unabbreviated keywords. E.G. ���extends��� is much clearer than ���:��� (as used in some other OO languages).

All these options are messy and second best.
Comments
EVALUATION Proposals for new features in the Java programming language are no longer being accepted or maintained in the bug database at http://bugs.sun.com/. This also applies to proposals for new features in the Java Virtual Machine (that is, in the abstract JVM, as opposed to a JVM implementation like HotSpot). All proposals for new features should be made through the "JDK Enhancement - Proposal & Roadmap Process" described at http://openjdk.java.net/jeps/1. Consequently, this specific request to change the Java programming language will not be considered further. The bug database continues to accept and maintain submissions about technical errors in the design and specification of the Java programming language and the Java Virtual Machine.
31-10-2011
EVALUATION (As an aside, #3 seems a bit unclear: 3. Any ���package��� or ���import��� statements that import a name into the files name space gets name mangled by putting an underscore either side, e.g. ���assert��� would become ���_assert_���. I believe the intention is that if an import statement causes a type to be imported whose simple name clashes with a keyword, then the type's name is manged via _..._) This part of the justification is reasonable: With increasing use of languages other than Java on the JVM it is inevitable that some Java keywords will be used by APIs written in these non-Java languages and therefore these APIs will be unusable from Java, e.g. an API with a method called ���final���. I think #5 supports it by allowing an invocation _assert_(...), _final_(...), etc, to be written in Java source, and appear in the classfile as method descriptors called assert(), final(), etc. Two points spring to mind: 1) Source code could already define methods called _assert_, and using 'source' would mangle it into assert() in the classfile, and that would be very odd. The defining code could find that calls to its pre-existing _assert_ now invoke the imported JUnit version. Other, un-recompiled, code that calls _assert_ will now fail to link, so 'source' essentially breaks binary compatibility. 2) What 'source' level would cause _final_(...) to be translated to final() ? If we make it 'source 7', someone will want it to be enabled by 'source 6'. Furthermore, Sun cannot possibly know which keywords cause difficulty, so we will constantly get requests to add keywords to the list of escapable (via _..._) keywords. Now, this part of the justification is less reasonable: Also there are increasing calls to enhance Java and because of backward compatibility concerns these proposed enhancements are handicapped because they cannot introduce new keywords to support the enhancements. because we CAN introduce new keywords provided they are in a context-sensitive position. For example, in a proposal for type aliasing - import ... as ...; - 'as' is a context-sensitive keyword and doesn't preclude 'as' being used as an identifier elsewhere. Overall, this request identifies a reasonable problem, but I am not sure it's the right way to solve it. But I will leave it open for the time being.
07-02-2007