Musings on JDK development

  • Java
    August 28, 2009

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.

Join the discussion

Comments ( 67 )
  • Silveira Neto Saturday, August 29, 2009

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

  • blog.leenarts.net Saturday, August 29, 2009
    [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...
  • Porco Tino Saturday, August 29, 2009

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


  • paulo Saturday, August 29, 2009

    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?

  • sboulay Saturday, August 29, 2009

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

  • katz Saturday, August 29, 2009

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

  • Sakuraba Monday, August 31, 2009

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

  • guest Monday, August 31, 2009

    unfortunately pretty meager :(

    quite much like the rest of jdk 7

  • Martin S. Monday, August 31, 2009

    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.

  • Joe Darcy Monday, August 31, 2009


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


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

  • Joe Darcy Monday, August 31, 2009

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

  • Stephan Oudmaijer Monday, August 31, 2009

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

  • Casper Bang Tuesday, September 1, 2009

    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.

  • Cay Horstmann Tuesday, September 1, 2009

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



  • paulo Tuesday, September 1, 2009

    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.

  • SQL Developer Tuesday, September 1, 2009

    Do we get multi-line string literals?

  • Joe Darcy Tuesday, September 1, 2009


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

  • Alex Buckley Tuesday, September 1, 2009

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

  • David Kopp Tuesday, September 1, 2009

    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.

  • Joe Darcy Tuesday, September 1, 2009


    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.

  • joe java Tuesday, September 1, 2009

    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.

  • Joe Darcy Tuesday, September 1, 2009


    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.

  • Alex Buckley Tuesday, September 1, 2009

    @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.)

  • Alex Buckley Tuesday, September 1, 2009

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

  • Hervé Girod Tuesday, September 1, 2009

    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.

  • Mark Mahieu Tuesday, September 1, 2009

    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.

  • Cay Horstmann Tuesday, September 1, 2009

    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?

  • Geoffrey De smet Tuesday, September 1, 2009

    Good work.

    But keep it up, because we want more :)

  • am Tuesday, September 1, 2009

    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?

  • Brian Wednesday, September 2, 2009

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

  • Joe Darcy Wednesday, September 2, 2009


    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.

  • Joe Darcy Wednesday, September 2, 2009


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

  • Alex Buckley Wednesday, September 2, 2009

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

  • Casper Bang Wednesday, September 2, 2009

    @Alex: So basically a polite way of saying f%#k off. <http://www.codinghorror.com/blog/archives/001247.html>

    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. :)

  • Joe Darcy Wednesday, September 2, 2009

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

  • Stephen Colebourne Wednesday, September 2, 2009

    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.

  • Alex Buckley Wednesday, September 2, 2009

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

  • Alex Buckley Wednesday, September 2, 2009

    @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 bugs.sun.com. 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, bugs.sun.com 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.

  • Mark Mahieu Wednesday, September 2, 2009

    @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\*.

  • henk Thursday, September 3, 2009

    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.

  • Bob Thule Thursday, September 3, 2009


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

  • Alex Buckley Thursday, September 3, 2009

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

  • Alex Buckley Thursday, September 3, 2009

    @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?

  • Joseph Darcy Thursday, September 3, 2009

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

  • katz Thursday, September 3, 2009

    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.

  • Mark Mahieu Thursday, September 3, 2009


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

  • Alex Buckley Thursday, September 3, 2009

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

  • katz Thursday, September 3, 2009

    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.

  • Alex Buckley Thursday, September 3, 2009

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

  • sboulay Thursday, September 3, 2009

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

  • katz Thursday, September 3, 2009

    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.

  • Dalibor Topic Friday, September 4, 2009

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

  • guest Friday, September 4, 2009

    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.

  • Bob Thule Friday, September 4, 2009

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

  • Joseph Darcy Friday, September 4, 2009

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

  • Alex Buckley Friday, September 4, 2009

    @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 bugs.sun.com 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 http://jcp.org/en/participation/committee

  • Alex Buckley Friday, September 4, 2009

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

  • Bob Thule Friday, September 4, 2009

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

  • Joe Darcy Saturday, September 5, 2009

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

  • Herv&eacute; Girod Saturday, September 5, 2009

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

  • Casper Bang Saturday, September 5, 2009

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

  • Celtic Minstrel Thursday, September 10, 2009

    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.

  • Nicolas Dasriaux Wednesday, September 16, 2009

    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

  • Joe Darcy Thursday, September 17, 2009

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

    [1] http://jcp.org/en/jsr/detail?id=310

    [2] http://mail.openjdk.java.net/pipermail/challenge-discuss/2008-March/000062.html

    [3] http://openjdk.java.net/challenge/

    [4] https://jsr-310.dev.java.net/servlets/ReadMsg?list=dev&msgNo=1389

  • guest Monday, November 16, 2009

    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.

  • Luis Daniel Mesa Vel&aacute;squez Monday, November 23, 2009

    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 {



  • Jimmy Sturr Thursday, November 26, 2009

    I'm sad.

    I would like to have properties and delegates, also.

    But the programming life isn't perfect, is it?

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.