Project Coin: The Final Five (Or So)

First, thanks to all those who submitted interesting proposals and thoughtful comments to Project Coin; a demonstrably vibrant community wants to evolve the Java programming language!

Without further ado, the final Project Coin changes accepted for inclusion in JDK 7 are:

The specification, implementation, and testing of these changes are not final and will continue to evolve as interactions are explored and issues cleared. Two of the listed items are combinations of multiple submitted proposals. The omnibus proposal for improved integer literals includes at least binary literals and underscores in numbers; a way to better handle unsigned literals is desired too. Language support for Collections covers collection literals and allows for developing indexing access for Lists and Maps, assuming the technical problems are resolved.

That leaves a few proposals that went through further consideration, but were not accepted on the final list:

Improved exception handling would be a fine change for the language, but it ventures near the type system and we do not estimate we have resources to fully develop the feature within JDK 7. I would like to see improved exception handling reconsidered in subsequent efforts to evolve the language. While the Elvis operator and related operators are helpful in Groovy, differences between Groovy and Java, such as the presence of primitive types and interactions with boxing/unboxing render the operators less useful in Java. JDK 7 will support other ways to ease the pain of null-handling, such as the null checking enabled by JSR 308. Aggregates natively supporting more than 32-bits worth of entries will no doubt be increasingly needed over time. Language support for collections may allow such facilities to be developed as libraries until the platform directly handles large data structures.

The coin-dev list will remain available for the continued refinement of the accepted changes. Further discussion of proposals not selected is off-topic for the list.

The majority of the implementation of the Project Coin changes should be in JDK 7's development Mercurial repositories by the end of October 2009.

In due course, we intend to file a JSR covering the Project Coin changes.


Good to hear that. I like changes from Project Coin.

Posted by Silveira Neto on August 28, 2009 at 07:13 PM PDT #

[Trackback] Friday Joseph Darcy announced through a blog post that Project Coin is final. Project Coin is just one of the changes coming to JDK 7. But, since the changes in Project Coin are all small changes to the Java language, every single Java developer will h...

Posted by on August 28, 2009 at 08:13 PM PDT #

What kind of signed number representation will you be using for binary literals?


Posted by Porco Tino on August 28, 2009 at 10:45 PM PDT #

That leaves a few proposals that went through further consideration, but were not accepted on the final list:


Improved Exception Handling for Java


Intruding anti O-O garbage like strings in switch but passing over this very useful and simplifying feature?

Posted by paulo on August 29, 2009 at 09:21 AM PDT #

Agree - very surprised improved exception handling for Java didn't make it in. Overall a pretty underwhelming set of Language changes for Java 7.

Posted by sboulay on August 29, 2009 at 10:00 AM PDT #

I'm also very negatively surprised by the exclusion of improved exception handling. This would eliminate a lot of boilerplate code...

Posted by katz on August 29, 2009 at 11:07 AM PDT #

Well there needs to be at least some incentive to make people switch to Scala. Otherwise they 'd just wait till jdk7!

Posted by Sakuraba on August 30, 2009 at 10:55 PM PDT #

unfortunately pretty meager :(
quite much like the rest of jdk 7

Posted by guest on August 31, 2009 at 01:44 AM PDT #

It saddens me how Sun chose to spend the time and money on JavaFX rather than modernizing Java and the libraries. I would switch to Scala if it wasn't for the way it makes my head hurt.

Posted by Martin S. on August 31, 2009 at 05:46 AM PDT #


The formal grammar changes including binary literals have been written about before:

In source code, the binary literals would look like "0b0011".

Posted by Joe Darcy on August 31, 2009 at 11:36 AM PDT #

@paulo, @sboulay, @katz, and AC from Austria,

The source code for javac and the rest of the JDK needed to implement language changes has been published under an open source license for several years now.

The Java Language Specification has been available online for over a decade.

I've published multiple blog entries outlining the many facets of what needs to happen in the platform as a whole to support a language change.

Project Coin explicitly encouraged prototypes as a way to demonstrate the feasibility and utility of a change via an existence proof.

Yet, despite all this, most of the proposals sent to Project Coin did not have a corresponding prototype, including improved exception handling.

Rather than complaining after the fact, a more constructive way to influence future language decision is helping to hack prototypes ahead of time.

Posted by Joe Darcy on August 31, 2009 at 11:54 AM PDT #

all juicy bits are being left out. It`s a shame!!!! A very poor release it will be IMHO!

Posted by Stephan Oudmaijer on August 31, 2009 at 04:03 PM PDT #

With all due respect Joe, few developers have the skill or insight to do any meaningful hacking on javac - that includes myself. These same developers might still have an opinion though regarding the unsharpened tools they are provided. It's the same as somebody who doesn't know how to cook can still crave for great gourmet food.

It's not a critique of your work at all, but rather the lack of commitment and leadership from Sun who's the captain of this ship. A ship that for all practical purposes is looking more and more dead in the water. Being Sun's greatest commodity, I can't understand why they would let this happen to Java.

Posted by Casper Bang on August 31, 2009 at 09:41 PM PDT #

Could you be a bit more explicit about "Language support for Collections"? Where can one find the spec draft and a prototype?



Posted by Cay Horstmann on August 31, 2009 at 11:24 PM PDT #

Nowadays i just catch exception (and yes, also the runtime exceptions) rather that reproduce the catch body n times. I know it is wrong, finbugs annoys me with it being wrong. But i don't multiplex the catch, because it is plain retarded. This problem has two possible solutions that sun apparently refuses to implement. First, nicer IMO, introduce a compiletimeexception tipe has the counterpart to runtime. Then we could catch that instead of exception. Second, the proposal refused here. Or both.

I am not a compiler programmer. I don't have the resources, the brains, the patience or the expertise.
Some leadership would be appreciated.

Posted by paulo on August 31, 2009 at 11:38 PM PDT #

Do we get multi-line string literals?

Posted by SQL Developer on August 31, 2009 at 11:39 PM PDT #


The entry links to the email threads discussing the component proposals for collection literals and indexing access.

Posted by Joe Darcy on September 01, 2009 at 03:00 AM PDT #

@paolo: By "leadership", you mean "putting paolo's favourite proposal at the front of the list."

Sun judges that other proposals are more effective additions to JDK7, taking into account their scope and the resources available to work on them.

If you aren't contributing anything, then you don't get a vote.

Posted by Alex Buckley on September 01, 2009 at 04:13 AM PDT #

Poor Neal. First closures and now exception handling. When can we start talking about JDK 8?

I'm semi serious. It would be very nice to get both of these into JDK 8.

Posted by David Kopp on September 01, 2009 at 05:37 AM PDT #


Since the entire Java community was invited to contribute to Project Coin, every Java developer and Java-using company has also failed to do you bidding. Your ire can be (mis)directed at more targets than Sun.

Posted by Joe Darcy on September 01, 2009 at 05:59 AM PDT #

Alex your kidding yourself. People who submitted proposals didn't get a vote - infact they didn't even get an explanation why their proposals were rejected. The reality is you and a select few at Sun got to vote on the proposals and nobody else. Joe did a fine job with the mailing list and keeping things in the open, the voting part was far from democratic. Selecting a proposal based on resources available is a slippery slope - proposals should be selected on their merit and if need be resources from companies like IBM, RedHat, and Oracle should be enlisted.

Posted by joe java on September 01, 2009 at 06:01 AM PDT #


Yes, few developers today have the skills to do Java language development. One of the goals of Project Coin was to increase that pool of developers by officially inviting people to contribute and discussing the approach we've been using to evolve the language. At least on that front, Coin seems to have had at most limited success.

As one who occasionally indulges in dining at Michelin-rated restaurants when budgets permit, I know that those craving gourmet food who are unable to cook it themselves must usually pay a steep price to acquire it. Additionally, many gourmet establishments provide less choice to diners; part of what you are paying for is the chef's expertise to limit selection to a few good choices as opposed to many mediocre ones. For example, at the downstairs of Alice Water's Chez Panisse in Berkeley you get whatever courses they are serving that night; the diner makes no selection other than the wine. You might not even know the menu when you make your reservations! However, in the rights hands, this approach can lead to exceptional results; I still savor the goose two ways paired with pinot meunier I enjoyed at Chez Panisse last winter.

We at Sun also program in Java and have opinions on the language changes. After due consideration, the changes listed above are the ones we are willing to commit our resources to for JDK 7. As indicated above, I favor the exception enhancements on technical grounds; however, given limited resources, we will not be completing that effort as part of JDK 7.

Posted by Joe Darcy on September 01, 2009 at 06:29 AM PDT #

@joejava: No-one ever said the community would get to vote on Coin proposals. I am very interested to know how Sun can "enlist" the resources of other corporations - do tell. (Before the Expert Group formation stage of a JSR, that is.)

Posted by Alex Buckley on September 01, 2009 at 06:29 AM PDT #

@DavidKopp: There are many forums where you can describe and evaluate the use of closures and multi-catch in your own code. It would make an excellent presentation at JavaOne, Devoxx, JAOO, or your favourite Java User Group.

In case it's not obvious by now, "getting something into the JDK" requires more commitment and contribution than posting comments on a blog.

Posted by Alex Buckley on September 01, 2009 at 06:37 AM PDT #

There's no reason to complain. From the beginning, Project Coin was about putting \*\*small\*\* languages changes in the JDK. And asking for people to provide proposals AND prototypes was giving them some influence on what changes could sneak in. It seemed to me that the rule was pretty clear.

We sure don't want JDK 7 to be delayed for a loooong time because Sun accepted to put things which took them too long to develop and test.

Posted by Hervé Girod on September 01, 2009 at 08:05 AM PDT #

Some of the proposals really wouldn't have been \*that\* hard to prototype in one form of another; prototypes don't need to be production quality or anything in order to be informative. I managed to cobble 3 together for Coin, and I'm certainly no javac engineer.

Posted by Mark Mahieu on September 01, 2009 at 11:16 AM PDT #

Joe, I am sorry to be so dense, but the "Language support for Collections" entry in your blog doesn't appear to be a link. I went to the email archives, and I noted a spirited discussion, but I could not actually find anything resembling a draft proposal. Undoubtedly I missed it, and I would be grateful for a link. And, with your cogent remarks about the importance of a prototype for any feature worthy of consideration, I am sure there is such a prototype for "Language support for Collections" and it is just my incompetence for not being able to locate it. Sorry, where do I find it?

Posted by Cay Horstmann on September 01, 2009 at 02:56 PM PDT #

Good work.
But keep it up, because we want more :)

Posted by Geoffrey De smet on September 01, 2009 at 04:20 PM PDT #

Regarding Automatic Resource Management:
From the spec it the following is not clear to me:
1. In what order do the closes happen when executing the finallies?
2. What happens when something throws an Exception on initialization? Can it be caught in the catch block? Do the already created objects get "closed"?
3. What happens when a close() throws a finally? Do other closes() get interrupted? (I hope not)
4. What about close() methods that don't declare exceptions? Can't it call those?

Posted by am on September 01, 2009 at 04:37 PM PDT #

Please reconsider the exception handling. This is one of the biggest headaches I think in the whole try...catch philosophy.

Posted by Brian on September 02, 2009 at 01:14 AM PDT #


The sentence
"Language support for Collections covers collection literals and allows for developing indexing access for Lists and Maps, assuming the technical problems are resolved."
includes the links to the latest versions of the component proposals. There is a Kijaro prototype of indexing access; I'm not aware of an extant prototype for collection literals.

Posted by Joe Darcy on September 02, 2009 at 03:13 AM PDT #


Details comments on proposals should be sent to the coin-dev list.

Posted by Joe Darcy on September 02, 2009 at 03:16 AM PDT #

@Brian: Sure. Just suggest something to drop to make room for multi-catch. Be sure to deal with the people who are annoyed at you for removing their favourite feature.

Back in the real world, it goes like this: Either you supply the resources to make multi-catch happen, or you accept what Sun chooses to invest its resources in.

Posted by Alex Buckley on September 02, 2009 at 04:09 AM PDT #

@Alex: So basically a polite way of saying f%#k off. <>

By now I am sure Sun must be thinking "give them a hand and they grab the whole arm". Meanwhile the community appears to be thinking "make a choice already, you can't have your cake and eat it too".

If Sun has no passion for nor the resources to drive the language forward, why don't you just set it truly free? You can start by granting Apache Harmony status as Java. :)

Posted by Casper Bang on September 02, 2009 at 05:55 AM PDT #

@Casper and others,

Project Coin offered the Sun-external Java community (Sun is part of the Java community) an unprecedented invitation to \*participate\* in evolving the Java language. This invitation to participate always explicitly included participating \*in the work\* of the language changes, including writing and analyzing the proposals and developing prototypes.

People were \*not\* invited to just issue lists of demands and pout when others failed to satisfy those demands.

Posted by Joe Darcy on September 02, 2009 at 06:49 AM PDT #

I just thought I'd record here my thanks for the opportunity that Coin has provided to discuss and debate the area of language change. "Sun" is often criticised (including by me) for a lack of leadership, but in the end I think a lot of bravery and leadership has been shown through this process.

Java language design is all about really smart people taking important decisions behind closed doors. Why? Because changing Java now is very, very hard. For anyone that doesn't believe that, I'd suggest going and looking at the compiler, and trying to make any chance that doesn't break something else, or conflict with the broader aims of the language.

Of the specific selected proposals, I have no great issue. (I never had any illusions that null-handling would actually be selected even as the most requested change from users. Of course, thats one reason why I didn't work on a prototype - chicken and egg).

If there is one thing that I think Coin missed, its the opportunity to start the process of permanently rejecting some changes. I think the ability to say "feature xxx will not enter Java ever/in the next 2 releases because its a bad idea/it conflicts with Java/other reason" is a very powerful thing, and of immense value to an open community.

Posted by Stephen Colebourne on September 02, 2009 at 08:52 AM PDT #

@Caspar: Sun has long understood that the demand for new language features is much greater than the supply possible from any one corporation. We have been turning down requests for language features for 13 years. Most people are happy that Sun (and the JCP in general) has NOT thrown "cool feature of the month" into Java.

What's different now is the degree to which a handful of individuals can get attention for their demands and claim Sun is 100% at fault for not immediately dropping everything else to satisfy them.

I think most people see how outrageous that position is.

Posted by Alex Buckley on September 02, 2009 at 08:55 AM PDT #

@Stephen: You raise an interesting point about saying "never". JavaOne talks in 2005 and 2008 both listed rejected language features, though I accept they're not widely known. As a practical matter, I own hundreds of language RFEs submitted over the years to The insane ones (the majority) are closed, but the not-completely-insane ones are open because, frankly, there's no benefit in closing them. Maybe, one day, one will provide some inspiration.

That said, is hardly the first place people submit language requests these days. In fact it's probably the last place. It says the #1 Java RFE is design-by-contract, which has numerous problems and won't happen - but there it is, #1 in the database.

Posted by Alex Buckley on September 02, 2009 at 09:10 AM PDT #

@Caspar: Terribly sorry, but I've forgotten which proposal was yours... got a link?

Consider is that the complaints from those who have participated in Coin, whether with code, proposals, or comments to the list, are relatively quiet in their criticism compared to those who did and said absolutely \*nothing\*.

Posted by Mark Mahieu on September 02, 2009 at 09:40 AM PDT #

Although I'm very sad that the Elvis operator didn't make it into the language, I do understand the argument put forward by Joe. If nobody actually cared to free up some time to create a prototype of some sort, then the community is to blame too.

Hopefully this will be a good lesson for a next project coin.

Maybe Sun (Oracle then), could help a little by making it clear that some proposals don't have a prototype yet, or only prototypes of insufficient quality and are thus in danger of being scrapped. This might make it more clear that explicit participation is required and will make it less of a surprise when the final list is announced.

I would like to add that I'm VERY happy that ARM did make it into the language. This will be a very useful change and something which I have been waiting for for quite some time. Both C++ and C# have had something like this for ages and it actually proves to be very useful in practice.

Posted by henk on September 03, 2009 at 04:38 AM PDT #

You keep saying that Sun wanted the help, however, the information for Project Coin is horrible. Have you been to it's project page?! It still only shows details about submitting a proposal-- something that ended 6 months ago. Where on that page is instructions on how to create a prototype? Where is the getting started guide?

Where is the consolidated list of the proposals? Where are the pros/cons listed for the proposals?

You said "Project Coin explicitly encouraged prototypes", however the word prototype only showed up ONCE on the Project Coin homepage, and it was followed by "(optional)".

Even if it were explicitly encouraged, can you really expect people to spend a lot of time developing a prototype for a proposal when they had no idea of how well the proposal was going to be received? I know I don't like to do a lot of work with no results.

If you really wanted prototypes, you could have set up working groups for each of the proposals that you received and encouraged the working group to build a prototype. Why should all the work go to one person who has never dived into the language development before?

Even if you can't get Project Coin back on track for JDK7, I still hope you create a consolidated list of proposals so that they can be worked on for inclusion in JDK8 or beyond. This can be a place where people can vote on any proposal rather than just the handful of ones you like.

This list can be the starting place to encourage people to create working groups and develop prototypes. Also, people new to language development need information on how to get started.

All that being said, really the only two improvements I wanted was a Elvis ?. operator and a === operator that did a null-safe overload for .equals().

Posted by Bob Thule on September 03, 2009 at 05:01 AM PDT #

@Bob: Sun never said it wanted "help". Sun can perfectly well select and develop language features without outside involvement. Coin sought to give the community direct input into what Sun sponsors through the JCP. The Coin list was bursting at the seams with lively discussion on proposals, which Joe tracked via weekly mail and blog summaries.

If someone \*really\* wants a feature in the Java language, they will design and prototype it for people to try out; or they will try out other people's prototypes and give detailed feedback.

If someone doesn't \*really\* want a feature, they will do other things, such as saying "+1" on mailing lists and writing "how can we get it in?" in blog comments.

It's true that getting started with a prototype in the OpenJDK codebase is non-trivial. But people are doing it. To get started, just \*start\*. Don't complain that Sun hasn't given you a "working group"; don't expect Sun to teach you programming language design; just \*start hacking\*. If nothing else, blog about your experiences downloading the code.

Your comments reflect a mindset that all someone has to do is send Sun a proposal, or vote on one. That mindset is outdated.

Posted by Alex Buckley on September 03, 2009 at 06:37 AM PDT #

@Bob: Let me be 100% precise about the disconnect between your mindset and Sun's. You said:

"All that being said, really the only two improvements I wanted was a Elvis ?. operator and a === operator that did a null-safe overload for .equals()."

You wanted those two features. Other people don't. (I'll name two: me, and Charles Nutter.) Why are you right? What makes those two features more important than two other features?

Posted by Alex Buckley on September 03, 2009 at 06:44 AM PDT #

@Bob Thule,

Most of the action of Project Coin occurs on the mailing list and concise Project Coin updates from myself and others have been trackable from

Yes, I do expect people who \*choose to participate\* in the process of adding new language features to be willing to to spend time writing proposals and developing prototypes for features that are not ultimately selected. Adding features to the language and platform is very expensive and should be done cautiously. Exploratory work that shows a feature is not appropriate is quite valuable.

I've treated the Project Coin participants are adults who are able to self-organize efforts to collaborate on the mailing list, which was encouraged and happened more than once without "working groups." Passivity is not a helpful trait if one wants to work on Java language evolution.

Posted by Joseph Darcy on September 03, 2009 at 08:35 AM PDT #

I'm pretty happy with Project Coin. In particular, I'm glad that the language proposals being considered were made public in such a way that people external to Sun could comment on them while they were still in the consideration stage. I also understand the argument that, given the limited resources Sun devotes to Java, not everything can be implemented, and that it would be helpful if people were to contribute prototypes.

However, it's also my understanding that Sun believes it derives financial benefit from the fact that people choose to develop software in Java. Since people have the freedom to choose languages other than Java, Sun should consider whether it needs to devote more resources towards making changes that will clearly make people happier with the language (such as the Exception handling proposal). I know that as someone who chooses what languages to use for development, I watch to see how well Sun, and the managers of other languages, maintain their respective products, and I use those observations as part of my decision-making process. When a language maintainer says that it's my fault that a useful feature won't be implemented, my response is that I don't care whose fault it is. I just know that the feature is missing from language X, and if other languages look more attractive at that point, I'll choose something other than X.

Summary: While it may be my fault that a feature is missing, if this happens too often, eventually it will be Sun that suffers. I hope Sun/Oracle increases funding for Java development so that more useful features can be implemented.

Posted by katz on September 03, 2009 at 09:01 AM PDT #


"Although I'm very sad that the Elvis operator didn't make it into the language, I do understand the argument put forward by Joe. If nobody actually cared to free up some time to create a prototype of some sort, then the community is to blame too."

Yes, but as it happens, Elvis is one proposal that did have a thorough enough spec that someone else who is not a javac expert (me) could put together a prototype without having to make any additional decisions about how it should work. I did that because I liked the fundamental intent of the proposal, but had nagging, fuzzy concerns about how well it would really fit with Java (and existing code-bases) in real life.

By the time I posted a link to a runnable prototype to the list, my own understanding was much, much clearer, and very different; after delving into the real detail I'd come to the conclusion that it's not a good enough fit (for Java) in the form proposed.

The code itself was always destined for the bin, but that was fine because having a prototype had allowed me to understand the proposal that much more clearly.

Point is, prototypes are not just about convincing people that a proposal is a good idea, they're also useful for understanding whether (and in which ways) a proposal is \*not\* a good fit in a given form. The Devil is in the detail though, as they say.

Still, the number of people who downloaded that prototype was tiny in comparison with the number of people posting opinions about the proposal on the mailing list and elsewhere.

Posted by Mark Mahieu on September 03, 2009 at 10:18 AM PDT #

@katz: You're right that other languages do and will continue to offer compelling features not found in the Java language. No amount of resourcing on Sun's part can overcome this.

Java is an implicit 'gold standard' against which other commercial languages are judged. No-one decries Python for not having Scala's abstract type members. No-one complains that Scala doesn't have the same meta-programming features as Groovy. Each other popular language tends to be compared only against Java, winning five points in the process. When Java is being compared with every other language simultaneously, losing five points each time, it's not surprising that people think it's a dead horse. But they're wrong: each language has its niche, and run very well on the JVM alongside each other and atop the Java core libraries.

For this reason, I believe most projects in future will be Java + X. Java's role as a lingua franca should not be underestimated.

Posted by Alex Buckley on September 03, 2009 at 11:08 AM PDT #

I don't dispute Alex Buckley's comment above, but I don't think it really addresses the issue here. Alex indicates that no amount of resourcing on Sun's part can allow for Java to be all things to all people. However, I'm not asking for anything so grand. I just want Sun to contribute the relatively small amount of additional resourcing to get the Exception handling proposal into Java 7. This, I think, is an attainable goal.

While it would be nice for the community to step up and contribute the code for the Exception handling proposal, the Project Coin experiment seems to indicate that this isn't all that likely. Sun's response to this failure seems to be to blame the community and give up on the feature, citing lack of resources. I would implore Sun to find the resources -- maybe get an advance from Oracle. Assuming we repeat the 3-year gap between Java 6 and Java 7, we won't see Java 8 until 2013, and I'd rather not wait that long for the Exception handling proposal to get implemented. I don't think I'm alone in that.

Posted by katz on September 03, 2009 at 11:46 AM PDT #

@katz: You can't understand why Sun doesn't add multi-catch exception handling. Another person doesn't understand why Sun doesn't add bound properties. Another person doesn't understand why Sun doesn't add reified generics. Another person...

Do you really not see the bigger picture? Sun has features it expects to be able to add given its resources. Multi-catch is not one of them. If you want multi-catch, you can add it. If you don't add it, you're not at fault. You're just another person with a request and nothing to back it up. Advice to "get more resources" is 100% worthless.

This comment thread is exposing a deep and child-like misunderstanding in some parts of the Java community of how companies work.

It is also exposing a deep and distasteful belief that the open sourcing of Sun's Java implementation was a ticket to demand unlimited free development with precisely zero contribution in return.

Posted by Alex Buckley on September 03, 2009 at 12:42 PM PDT #

“it's not surprising that people think it's a dead horse”

That perception is a very bad thing indeed. In fact, that is something that needs to change quick – I’m hoping Oracle will heavily invest in Java and the platform so that perception changes. The “Java is dying” mentality doesn’t really help me a lot when we are trying to convince companies to use it.

Posted by sboulay on September 03, 2009 at 01:25 PM PDT #

Alex, let me be more blunt. The effort to recruit the community to work on Java 7 has, for the most part, been a failure. There's no reason to suspect this will change. For features to be added to Java, Sun (soon Oracle) is going to have to spend money to add those features. Sun can complain about this until the cows come home, but it won't change anything.

Now, of course, it's also true that there's a chorus of voices clamoring for a host of changes, and certainly not all of those changes can be implemented. I suspect that the Exception handling change is one that would be \*overwhelmingly\* popular, and one that is, frankly, ridiculous not to spend a little extra money to add, but I have no proof of this. It's therefore easy to dismiss the request to add the Exception handling improvement as noise, one of many hopeless requests.

While you're being dismissive and calling the users who you depend on for revenue "child-like", however, I think you might want to step back and consider that, perhaps, the reason why there are so many blogs complaining about the rate of progress of Java is that the rate of progress is, in fact, too slow. At the end of the day, users want to use the best technologies available to solve their problems. Today that technology may be Java. Tomorrow, it may be C#. If Sun doesn't want that change to take place, Sun is going to need to invest to make sure it doesn't happen.

Does this mean that your users are demanding, and that we always want more? Yes it does. But all I know is that Microsoft is spending a lot of money to develop .NET to be better than Java, and they're doing it without complaining that their users aren't doing the work for them. In an imaginary wonderland, Sun can combat this by getting its community to do its work for it. In the real world, it can't.

Posted by katz on September 03, 2009 at 02:54 PM PDT #

"Alex, let me be more blunt. The effort to recruit the community to work on Java 7 has, for the most part, been a failure."

Let's look at the numbers in Project Coin, to see if that blunt assertion bears out. Out of the proposals that were picked, 5 come from developers outside Sun - that's a ratio of 2.5 to 1.

For the larger language changes, which require more effort by design, there is one change coming from Sun (module support in the language) and one language change coming from developers outside Sun (annotations on types). That's a ratio of 1 to 1.

The lower ratio in this case is likely due to the amount of work necessary to implement, spec, etc. a large change, vs. a small one - it usually takes years rather then months to do all the necessary work on a medium or a large language change.

In either case, I don't think that the ratio of work happening outside Sun on the Java language can be in any form labeled as a recruiting failure - given that there is no (and never was, afaict from Sun's experience prior to OpenJDK, and my experience with other projects in the same domain) huge untapped pool of Java developers just waiting to be recruited to hack on the JDK, the developer community around the JDK will continue to expand at the pace at which competent, determined, self-motivated contributors continue to join it.

Project Coin has made it much easier then in the past for such contributors to take part in the development of small language changes. Some developers have taken that opportunity, and tried their hand at a proposal, and some have tried their hand at writing prototypes, learning a lot more about the impact and dark corners of the proposed changes then they could have just through passive participation.

The end result is that instead of 5 proposals, as initially scoped, Joe picked 7. He didn't pick 8, so naturally people who want to see their favorite feature in the set of proposals to be implemented by Project Coin will take an issue with the choices made, as Alex explained. That's to be expected. But as Joe suggests, there is a simple way for people who don't agree with the selected set of proposals - take the javac code, experiment with it, learn about the dark corners of the proposal you like, try using it in anger on a larger code base, and report back your findings somewhere publicly.

Those are the conversations worth having as they increase what the community knows about the language and its potential evolution paths.

The 'Java will die unless Sun does $X' argument, on the other hand, has provably been wrong in the past decade each time it was invoked - there is no reason to think it'd be different in the future. In fact, the adoption of Java in the real world world has continued to grow over the past years, judging by publicly available data, despite that every six months, some language or other makes its way through the blogosphere as the 'Java killer', from Perl, to Python, to Ruby, to Erlang, to C#.

C# is pretty interesting in that regard, as it gets a regular spot about once a year in the Java blogosphere - it seems to take about six months to build up excitement for a new language as the Java killer, and then a few months for the excitement to go back again as it turns out that once more, Java has 'narrowly escaped a tragic fate' - so C# and Microsoft fill the scary gaps until the next 'Java killer language' gets to have a go.

Coming back to the initial point, the impact of the community outside Sun on the evolution of the Java programming language has, from what I can tell by watching the development of the language for the past decade or so, never been higher, in large part thanks to the work Joe, Alex and others at Sun have done to open up venues for collaboration on the future of the language and the platform underpinning it.

Posted by Dalibor Topic on September 03, 2009 at 10:34 PM PDT #

Interesting points, Dalibor. Perhaps it's too early to label the effort to recruit the community to contribute to Java a failure. However, I'm not nearly so hopeful as you. As far as I can tell, most of the external contribution to Project Coin was from a select group of Sun alumni, and it's not clear that the magnitude of that type of contribution is going to increase.

I don't mean to imply that Java is on the verge of annihilation because the Exception handling proposal didn't get in. And I don't want to imply that Sun should implement every single feature that people want, since I agree that there's value in keeping the language simple.

Prior to 2 years ago, I was relatively impressed with the amount of Java development Sun was doing. For the past ~2 years, however, I think Sun's investment in Java has been below where it should be. The longer this continues, the more likely it is that I'll move my company's development to another technology. Now, I'm just one company, but I suspect that there are other senior managers out there who think like I do. Just because Java hasn't fallen out of favor yet doesn't mean it won't do so in the future.

Posted by guest on September 04, 2009 at 03:31 AM PDT #

@Alex Buckley
You are right about the mindset disconnect-- because your mindset is that you and a very small group know whats best for everyone and my mindset is that the only way to know what is best for everyone is to ask them.

@Joseph Darcy
You and your small group may have wanted to encourage people, but by and large, you did not succeed. That is evident by the large number of proposals that you received when you asked for it on the Project Coin homepage, but then when you never updated that page, community involvement floundered. You can blame the community for not stepping up and taking over that page, but I don't see how they could have when you held all the power.

Using mailing lists alone for communicating to the public is woefully inadequate. The projects from Eclipse, MySql, and Apache would never have been successful if all they relied on was a mailing list.

Posted by Bob Thule on September 04, 2009 at 09:28 AM PDT #

@Bob Thule,

Your criticisms would be more interesting if they were more firmly grounded in the facts of what happened.

The coin-dev peak email activity was naturally during the call the proposals period; afterward, traffic declined, but far from stopped. Besides my blog, Alex Miller's JDK 7 links, dzone, and numerous other websites have reported on Project Coin's progress over the months.

Posted by Joseph Darcy on September 04, 2009 at 09:48 AM PDT #

@Bob Thule: People have been sending language suggestions to Sun for 13 years. Sun and the many language experts at Google and other JCP members are well aware of what people have been asking for. Essentially all the Coin proposals were already in the database.

95% of suggestions are not acted upon. This is because either a suggestion is technically deficient, or it's OK but there is no pressing need to "throw it in". You think Sun should run some kind of global vote to determine what's cool enough to get in. Most people are glad that Sun has taken the exact opposite approach, and kept things out unless there is overwhelming support for them.

Before anyone starts naming features that in their view have overwhelming support, they should consider whether major JCP members agree with them. If you're not sure who those members are, you can find their emails at

Posted by Alex Buckley on September 04, 2009 at 10:03 AM PDT #

@katz: You say "Microsoft is spending a lot of money to develop .NET to be better than Java, and they're doing it without complaining that their users aren't doing the work for them. In an imaginary wonderland, Sun can combat this by getting its community to do its work for it. In the real world, it can't."

There is no question that Microsoft gives more resources to the C# programming language than Sun does to the Java programming language. To help Sun give more resources, buy a Java SE For Business subscription.

However, you mentioned .NET, as in the platform. The Java platform is stronger now than ever thanks to investment from Sun and others in the JVM and in non-Java language implementations. Java is not going to play feature catch-up to other languages, but as I've said above, it's a great lingua franca.

As an aside, the clarity of your comments is striking, and I thank you for them. Clearly we have tapped into a rich seam of thoughts and emotions about the Java language.

Posted by Alex Buckley on September 04, 2009 at 10:53 AM PDT #

@Joseph Darcy

Random blog postings and dzone articles scattered around the web do not really help counter the argument that the communication was inadequate.

I know participation didn't stop, I didn't say it did. And I am not saying you weren't productive. But participation did fall off when it wasn't clear that participation was still being requested. If participation was still wanted, an updated Project Coin homepage should have reflected that.

@Alex Buckley

Sure, I know a lot of the philosophy of Java was to save developers from themselves, and I agree with that. But we aren't talking about operator overloading here, we are talking about fixes for syntax and grammar that are needlessly tedious and verbose.

When Project Coin was started, I had no expectations that every proposal would be accepted. I still don't. I am mostly happy with the language improvements that you made. I am just a bit surprised that some of the smaller but very useful things were not included. But my major criticism is that you say you want community involvement but you haven't acted like it. I doubt you did this purposefully, so I feel bad that you are getting so much criticism. I think the reason there is so much criticism is simply because hopes of language improvements were too high because for the first time there was a dedicated project for them. But really, these language improvements are a lot less important than getting a modular java.

Thanks for your hard work. I am looking forward to using the new features that are going to be added.

Posted by Bob Thule on September 04, 2009 at 04:05 PM PDT #

@Bob Thule,

I find the charge of inadequate communication very odd. Many people had no difficulty signing up for coin-dev list and for many months typing "Project Coin" into your favorite search engine would list all those scattered links conveniently all on one page.

Posted by Joe Darcy on September 05, 2009 at 04:10 AM PDT #

@katz: More features does not automatically makes a language better. And concerning C#, I really dislike the approach of putting everything in it. A big cake with all possible flavors ends having no flavor at all. Pardon me, but it reminds me of the scores of APIs Microsoft have developed over time but never really supported in the long run. And I think not because of any conscious or "evil" decision, but just because at the end any developer must concentrate on what he thinks is the most important. At the end when you have 10 ways to do the same thing in one language, the designer of the language will naturally really support only one.

Posted by Hervé Girod on September 05, 2009 at 11:10 AM PDT #

@Herve: That argument works the other way around too though. Just because a language does not encapsulate and embrace concepts at its heart, does not necessarily make it simpler or more readable - and it most certainly makes it less toolable, with intent buried deep within patterns and conventions.

I don't actually think there's another language than Java, where so much practical use depends on external frameworks, libraries and toolkits with 100 ways to do the same. So I can't really buy that argument.

Posted by Casper Bang on September 05, 2009 at 01:05 PM PDT #

Well, apart from Automatic Resource Management (which I don't really care about) and JSR 292 support (which I don't really understand), I'm quite happy with the changes added. Indexing and literals for collections is one thing in particular that has been sorely lacking in Java.

Posted by Celtic Minstrel on September 10, 2009 at 05:10 AM PDT #

Please could you explain the value the proposal for better integral literals, and and why it was prioritized at the expense of seemingly more valuable proposals ?

We also have been waiting for ages now for better date and time support in Java. This is a very high priority for developers. This is so sad that we have to wait again until next release in hope that we might get the date and time problem fixed one day... Perharps

Posted by Nicolas Dasriaux on September 16, 2009 at 12:18 AM PDT #

@Nicolas Dasriaux,

> Please could you explain the value the proposal
> for better integral literals, and and why it
> was prioritized at the expense of seemingly
> more valuable proposals ?

No explanation of the Project Coin decision making more detailed that what has already been provided will be provided.

Diamond, binary literals, and underscores in literals are already in the OpenJDK code base. If you would prefer to see multi-catch, the decision problem becomes what set of same-sized or larger language features should be dropped to allow in multi-catch.

> We also have been waiting for ages now for
> better date and time support in Java. This is a
> very high priority for developers. This is so
> sad that we have to wait again until next
> release in hope that we might get the date and
> time problem fixed one day... Perharps

JSR 310 was accepted in the JCP in January 2007 [1] to provide a better date and time API, informed by experiences with Joda-Time and other libraries. In the JCP, the specification lead is responsible for making progress on the JSR. The spec. leads for JSR 310 are Stephen Colebourne and Michael Nascimento Santos, neither of whom work for Sun. In early 2008, the JSR 310 implementation of that time was submitted for consideration to the OpenJDK Community Innovators' Challenge with the claim that much of the implementation was complete. [2] The JSR 310 date and time library project was subsequently awarded $25,000 by the Innovators' Challenge in September 2008. [3] In December 2008, Stephen announced JSR 310 was at risk for JDK 7 because of lack of time to work on it and he asked for community help. [4] Currently JSR 310 is marked with an "inactive" status in the JCP.

Questions about progress of JSR 310 should be directed to the responsible parties, the spec. leads.


Posted by Joe Darcy on September 17, 2009 at 06:30 AM PDT #

For anyone using Scala and Groovy most of those aren't issues anymore.

I agree with sun. Improve the jvm, keep java rock solid and let innovation come to the jvm environment. It's feature richness and performance will be the beacon.

Posted by guest on November 16, 2009 at 11:17 AM PST #

I know i'm gonna get ugly stares, but i think 'improved' exception handling doesn't add anything... it's just an aesthetic (but beauty is in the eye of the beholder). I avoid repeating code by using the object hierarchy properly, and i think it looks somewhat the same. I don't mind the changes, since they're all adding features, but i don't want performance degradation due to aesthetic changes. Peace. (Sorry for the formatting).

try {
throw new AnyException("Kaboom!");
} catch (Exception ex) {
if (ex instanceof SQLException || ex instanceof RuntimeException) {
System.out.println("No need for 'improved'(?) exception handling.");
} else if(ex instanceof IOException || ex instanceof MyException) {
System.out.println("Do something.");
} else {
System.out.println("Do something else.");
} finally {

Posted by Luis Daniel Mesa Velásquez on November 23, 2009 at 12:12 AM PST #

I'm sad.
I would like to have properties and delegates, also.
But the programming life isn't perfect, is it?

Posted by Jimmy Sturr on November 26, 2009 at 05:31 AM PST #

Post a Comment:
Comments are closed for this entry.



« December 2016

No bookmarks in folder