Project Coin: For further consideration, round 2

The first group of proposals selected for further consideration were:

After due deliberation, and next set of proposals meeting the Project Coin criteria for further consideration are:

All the selected proposals were reviewed and judged to have favorable effort to reward ratios and to preserve the essential character of the language.

Work should continue refining the selected proposals and producing prototypes. In particular, a unified proposal for integer literals should be produced.

Language change proposals not on the combined "for further consideration" list will not be included in JDK 7; there is no need for continued discussion about them on the Project Coin mailing list. Detailed rationales for why particular proposals were not selected will not be provided.

Final selection of the five or so proposals to be included in the platform will occur within the next few months.


Thumbs of for almost everything... these proposals range from "nice" (like Strings in switch) to "sorely missing" (like Collection literals).

Thumbs down for Underscores in numbers. I understand the need but that's just plain horrible, sorry.

The proposal Large arrays must be implemented carefully, because we ca't take even the slightest performance hit in small arrays. This means in practice that the JVM will have to support both "small" and "large" arrays as separate types internally, but somehow, consider them equivalent types as far as the Java language and APIs are concerned. Perhaps I'm overreacting, as the whle issue is only relevant to 64-bit JVMs and even thee, without compressed references. But there are other problems, for example GC hates huge monolithic objects, these big arrays (even much smaller than 2G elements) are typically allocated in a "large object area" that complicates VM tuning. The best design is usually breaking the array, or using a NIO buffer.

Posted by Osvaldo Pinali Doederlein on May 27, 2009 at 11:25 PM PDT #

Not to get collection literals would be disappointing, to say the least..

Posted by Valerio Schiavoni on May 28, 2009 at 06:18 AM PDT #

All of those are great proposals! I don't much care about automatic resource management or JSR292, but I hope all of them get into JDK7.

I wish they had considered the operator overloading proposal though. At least, I THINK I remember seeing one. That's one thing that's sorely missing in Java.

> Thumbs down for Underscores in numbers. I understand the need but that's just plain
> horrible, sorry.
If you don't like it, don't use it!

Posted by Celtic Minstrel on May 29, 2009 at 01:54 AM PDT #

> If you don't like it, don't use it!

Ok, but I will also need to write a new Checkstyle rule to make sure that nobody else in the whole company uses it so I won't burn my eyes when reading other people's code. ;-)

Posted by Osvaldo Doederlein on May 29, 2009 at 02:24 AM PDT #

Hmm, it appears that one of the examples in the "Underscores in Numbers" proposal is not actually valid according to the grammar...

-> "double whyWouldYouEverDoThis = 0x1_.ffff_ffff_ffff_fp10_23;"

That leftmost underscore does not appear between two digits; it appears between a digit and an underscore, which as far as I can make out is not in accordance with the grammar of the proposal.

Hardly important, just something I noticed.

Posted by Celtic Minstrel on May 29, 2009 at 11:47 AM PDT #

I have to wonder, why don't people just propose some of the same things that are already in .NET? i.e. for type inference, why not just use var like .NET? The same thing with collection literals. Why not implement a more general purpose "object initializer" syntax like what .NET has? Microsoft ripped off a lot from Java, I don't know why Java doesn't do the same thing to .NET. Also, I would like to see partial classes. If it works for .NET, I don't see why it can't work for Java. Also, I think properties and events are long overdue. While I think it's good to think all this stuff through and make sure it's done right, Java really does seem to be moving at a snails pace anymore. Some of what's listed here has been in .NET for a long time now and there's still a lot of stuff that's missing.

Posted by Jon on June 03, 2009 at 05:59 AM PDT #


It is a non-goal for Java to achieve "checkbox parity" with the features in C# or any other language.

The mere fact that a widely used language, such as Java or C#, has adopted a particular feature does not imply the feature is suitable in other languages.

During the open call for proposals period, any interested party was free to send in ideas for changes.

Posted by Joe Darcy on June 03, 2009 at 08:07 AM PDT #

While looking into the "Elvis" operations, what about other cases for comparison operations:

Integer x;

The following can throw a NPE
if ( x > 0)

But could we have
if (x ?> 0)
which would be false if x==null.

There are a lot of cases where it would be great to have a more expressive language to save on boilerplate

Posted by Neale Upstone on June 18, 2009 at 06:45 PM PDT #

Sure, x>?0 can avoid an NPE but the else block is now faced with using an x that might be null or <=0. So you'll want to use ?+ and ?- operators to avoid further NPEs, and you'll want to pass x to methods that only touch it using null-safe operators. Those operators will either have to use a default non-null value for x (specified with each operator, errr not so great) ... or the operators will simply fail silently and your program will do very little.

If x wasn't null in the first place, but a good <=0 integer, then all those null-safe operators were redundant. Just do the null check already, and let the rest of the program continue in peace!

Posted by Alex Buckley on June 19, 2009 at 11:50 AM PDT #

Post a Comment:
Comments are closed for this entry.



« June 2016

No bookmarks in folder