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