Project Coin: For further consideration...

In the first three weeks of Project Coin over two dozen proposals have been sent to the mailing list for evaluation. The proposals have ranged the gamut from new kinds of expressions, to new statements forms, to improved generics support. Thanks to all Java community members who have sent in interesting, thoughtful proposals and contributed to informative discussions on the list!

While there is a bit less than a week left in the call for proposals period, there has been enough discussion on the list to winnow the slate of proposals sent in so far to those that merit further consideration for possible inclusion in the platform.

First, Bruce Chapman's proposal to extend the scope of imports to include package annotations will be implemented under JLS maintenance so further action is unnecessary on this matter as part of Project Coin. Second, since the JSR 294 expert group is discussing adding a module level of accessibility to the language, the decision of whether or not to include Adrian Kuhn's proposal of letting "package" explicitly name the default accessibility level will be deferred to that body. Working with Alex, I reviewed the remaining proposals. Sun believes that the following proposals are small enough, have favorable estimated reward to effort ratios, and advance the stated criteria of making things programmers do everyday easier or supporting platform changes in JDK 7:

As this is just an initial cut and the proposals are not yet in a form suitable for direct inclusion in the JLS, work should continue to refine these proposed specifications and preferably also to produce prototype implementations to allow a more thorough evaluation of the utility and scope of the changes. The email list should focus on improving the selected proposals and on getting any remaining new proposals submitted; continued discussion of the other proposals is discouraged.

The final list of small language changes will be determined after the call for proposals is over so proposals sent in this week are certainly still in the running! The final list will only have around five items so it is possible not all the changes above will be on the eventual final list.



I'm surprised I didn't see "Bracket notation to access collections". What happen to this proposal? I thought there would be a lot of interest around that one.

Posted by sboulay on March 24, 2009 at 10:34 AM PDT #


The bracket notation to access collections proposal hasn't been written up yet, but it is on my to-do list before next Monday!

Posted by Joe Darcy on March 24, 2009 at 10:38 AM PDT #

Multi-line strings.

Posted by SQL Developer on March 25, 2009 at 01:15 AM PDT #

Is there any hope for having complex number support in Java at the level of a complex primitive? This seems a perfect candidate for a "small language change". I know there are many Complex object libraries available (and I use several of them), but they're just a real pain to use when translating existing (read "FORTRAN") algorithms. In the early days of Java, this was an oft requested feature by the numerical analysis community, but as far as I can tell they've given up all hope of seeing this. If I had time, and the expertise, I'd submit a coin proposal for this. Here's hoping someone else will.

Posted by Bruce A Johnson on March 25, 2009 at 11:53 PM PDT #

regarding to Add extensible arrays and dictionaries to the syntax

i also was looking for a JSON like syntax and similar like this:

String[] h = { "value1", "value2", "value3"};

and here the HashTable Syntax:

Hashtable h = {

"key1": "value1",



Posted by arno nyhm on March 27, 2009 at 02:46 AM PDT #


I was heavily involved in the early Java Grande efforts so I'm very familiar with the numerical community's desire for a complex type.

Adding another true primitive type would be a large undertaking, requiring changes in JNI and the JVM. A more tractable approach would be a complex type with some operator overloading, but numerical operator overloading is not in the cards for Project Coin.

Supporting complex numbers is actually better done with a paired Complex and Imaginary type; the reasoning is discussed in

Jim Thomas and Jerome T. Coonen, Issues Regarding Imaginary Types for C and C++, The Journal of C Language Translation, vol. 5, no. 3, pp. 134-138, March 1994.

and this reasoning informed the C99 specification.

Including the mathematical libraries for complex arithmetic would also be a nontrivial task.

Posted by Joseph Darcy on March 28, 2009 at 04:28 PM PDT #


Java has really been made unusable for numerical computations simple because it lacks a "bracket notation to access collections". Really. I've tried. I had given up hope. Make this happen and I'll believe in Java again.

The real reason from writing though is to ask you to also consider in your proposal the case of bracket notation to access multidimensional collections (matrices). Matrices are HUGE in numerical computation. Maybe too much to ask but please consider not only:

int v = a[i]; → mapping to int v = a.get(i);


int v = m[i,j]; → mapping to int v = m.get(i,j);

If you make the proposal general enough and use 'get' and 'set' operators for the collections access then multidimensional access shouldn't be too much of a stretch.

Just asking. Thanks for the consideration.

Posted by John Piersol on March 31, 2009 at 12:35 AM PDT #

Hello John,
The Matrix class in JAMA has what you want:
(We use it for Entrance tools)
- Tod

Posted by Tod Landis on April 15, 2009 at 07:22 AM PDT #

Post a Comment:
Comments are closed for this entry.



« July 2016

No bookmarks in folder