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:
import ���; // imports something that contains "assert", e.g. an early JUnit API
_assert_( ��� );
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.