Joseph D. Darcy's Sun Weblog

Tuesday January 27, 2009

Project Coin: Small Language Change Proposal Form Available

The name of the OpenJDK project hosting small language changes for JDK 7 will be Project Coin. Besides a coin literally being small change, to "coin a phrase" is to create a little bit of new language.

The website for the project and its mailing lists will come into being this February. In the mean time, the initial form to use to propose a language change is listed below. If you have an idea for a change, please work on the form and post it the Project Coin mailing list once that gets started.

Small language changes I think would improve the language according to the previously discussed criteria include (related Sun bugs in parentheses):

• Strings in switch: A simple change that improves regularity in the language (5012262, 4269827).

• More concise calls to constructors with type parameters: A large pain point when using generics occurs with the need to specify type parameters both on the left hand side of a declaration of a generic variable as well as on the right hand side in a constructor call to initialize the variable (4879776).

• Exception enhancements: multi-catch and final rethrow: Exception handling would be streamlined if semantically the same code for distinct exceptions could be shared (4432337).

• Ability to call with methods with exotic names: As the Java platform gets better support for non-Java languages via the Da Vinci Machine project, it is useful to allow Java programs to call methods from foreign languages hosted on the JVM, even if those languages have different naming restrictions than Java (6746458).

• (Possibly) Bracket notation to access collections: Collections like List and Map are nearly ubiquitous in Java programs and they offer many advantages over arrays, including better integration with the generic type system, availability of growable data structures, and the possibility to use immutability. However, arrays do have their more concise [] notation; allowing lists and maps and similar data structures to use this notation would encourage their use even more widely (4632701, 4877954).

PROJECT COIN SMALL LANGUAGE CHANGE PROPOSAL FORM v1.0

INSTRUCTIONS: For a proposal to be considered, this document must be complete and stand-alone in and of itself. No URLs, citations of papers, etc. can appear except for the limited supplementary information requested in the "REFERENCES" section. A new class file version number can be assumed to be available for -target 7. The proposal must not remove existing features of the language; for example, "Get rid of checked exceptions" would not be considered. As part of being stand-alone, the proposal must not rely on any other language changes that have not already been accepted.

AUTHOR(S): Who are you?

OVERVIEW
Provide a two sentence or shorter description of these five aspects of the feature:
FEATURE SUMMARY: Should be suitable as a summary in a language tutorial.

MAJOR ADVANTAGE: What makes the proposal a favorable change?

MAJOR BENEFIT: Why is the platform better if the proposal is adopted?

MAJOR DISADVANTAGE: There is always a cost.

ALTERNATIVES: Can the benefits and advantages be had some way without a language change?

EXAMPLES
Show us the code!
SIMPLE EXAMPLE: Show the simplest possible program utilizing the new feature.

ADVANCED EXAMPLE: Show advanced usage(s) of the feature.

DETAILS
SPECIFICATION: Describe how the proposal affects the grammar, type system, and meaning of expressions and statements in the Java Programming Language as well as any other known impacts.

COMPILATION: How would the feature be compiled to class files? Show how the simple and advanced examples would be compiled. Compilation can be expressed as at least one of a desugaring to existing source constructs and a translation down to bytecode. If a new bytecode is used or the semantics of an existing bytecode are changed, describe those changes, including how they impact verification. Also discuss any new class file attributes that are introduced. Note that there are many downstream tools that consume class files and that they may to be updated to support the proposal!

TESTING: How can the feature be tested?

LIBRARY SUPPORT: Are any supporting libraries needed for the feature?

REFLECTIVE APIS: Do any of the various and sundry reflection APIs need to be updated? This list of reflective APIs includes but is not limited to core reflection (java.lang.Class and java.lang.reflect.*), javax.lang.model.*, the doclet API, and JPDA.

OTHER CHANGES: Do any other parts of the platform need be updated too? Possibilities include but are not limited to JNI, serialization, and output of the javadoc tool.

MIGRATION: Sketch how a code base could be converted, manually or automatically, to use the new feature.

COMPATIBILITY
BREAKING CHANGES: Are any previously valid programs now invalid? If so, list one.

EXISTING PROGRAMS: How do source and class files of earlier platform versions interact with the feature? Can any new overloadings occur? Can any new overriding occur?

REFERENCES
EXISTING BUGS: Please include a list of any existing Sun bug ids related to this proposal.

URL FOR PROTOTYPE (optional):