Want Java to Improve: Fix it Yourself.
Sun recently created Project Coin, a proposal submission system to create changes to Java. Java has been a controlled but open source language for a while now.
However Project Coin’s proposal system differs from efforts for community outreach by other language projects. For example, Python’s PEP system has different prerequisites for acceptance:
“Reference Implementation — The reference implementation must be completed before any PEP is given status “Final”, but it need not be completed before the PEP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code.”
In contrast, Joseph Darcey, a Sun Employee managing Project Coin set this standard of prerequisites for acceptance:
“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.”
This quote appears in the announcement of the final five accepted feature additions to Java 7. People were angry that some changes were not made to make try catch blocks less messy. Joseph Darcy elaborates further on his opinion here.
I think his argument sets the bar too high. His argument trivializes legitimate suggestions. I understand that Sun is not obligated in any way to enact change, but it would be nice if they didn’t create disincentives to improve the language. They aren’t posting a list of changes they would like to see prototypes for. They are just saying that your suggestion must have a prototype before they will even tell you if the work you put into the prototype was worthwhile.
It isn’t just that Project Coin is for compiler developers only; Sun is surprised their community is not providing reference implementations. I feel that they should at least expect that Java users would complain. They need to not just incentivize prototypes, but encourage discussion that leads to prototypes. Whether or not a suggestion is actually better is not obvious, but the Python PEP program works better because its transparency is, well, more clear.
For example, they announced the final five proposals. Other proposals didn’t make the cut. They should have linked to the discussion of why other proposals were not accepted. Instead they pretended the community was transparent and simultaniously set the bar too high.
There is further drama about closures. The thing is, there are actually some good arguments against closures in Java. (Although some people disagree that the argument is fair) Many of these arguments rely on the premise that Java is not a prototyping language; it is a “real world language” and needs to be maintainable. There are differences in complexity between the three closures proposals for Java when considering their syntax and functionality. Each has its pluses and minuses
Ignore this if you’re not familiar with them, but my personal opinion on the BGGA proposal is that it doesn’t feel Java-esque. Java’s current meaning of return is different. It would be better if in BGGA nonlocal returns used a syntax that used the word throws (to pass a return up the call stack), and local returns still required return as a keyword. This may not be how Scala does it, but Scala isn’t Java.
Scala, does what it wants. It uses the Java JVM to add closures. This hasn’t ended the universe, but this can easily be explained by Scala’s different use cases. I am worried that Scala will be to Java what C# is to modern Visual Basic. What I mean is, Java will avoid innovation out of populist fear of adoption difficulty. The thing is, Java should have this fear, but Scala shouldn’t need to take on the reigns of New Java. Java should fork into a Caffeine Free Java which never changes, and Java Max, whose syntax changes rapidly. Every once in a while a language could use a feature creep revision.
In my exploration, I couldn’t find what ever happened to the “Concise Instance Creation Expression” proposal. It seemed to barely change the language. It was a bare-minimum update in Java syntax that was similar in spirit to the addition of for-each loops to Java 5. Does anyone know why it wasn’t accepted?
