Tags: OpenJDK
Anybody interested in the JDK 7 planning should go to Danny Coward's recent blog posting:
Channeling Java SE 7. It's a good overview of the planning, of the planning process, some of the high level themes and directions that we intend to take with the next major release of the JDK.
Doing the planning for a Java release is a very complicated process. As Danny says, it involves input from customer meetings, from the JCP, from the list of open bugs, and other sources. As we move to becoming an open source project, one question we've been tossing around is what mechanism can we follow for bringing in public input to the planning. Of course there is the JCP and mechanisms like votes in the bug parade, but each has their own foibles.
One difficulty are the conflicting constituencies that have strongly held opinions of the natural purpose for Java. The Java release planning has to balance all those conflicting constituencies. And of course any time you have conflicting constituencies each with strongly held opinions, there are bound to be arguments.
Another difficulty is collecting a representative sample of the whole Java developer universe. If, for example, we tracked all blogs, all discussion threads on the various forums, wouldn't that be a skewed sample? Not everybody blogs or goes onto the forums. For example if we only looked at statements by the enterprise customers Sun meets with regularly, doesn't that also skew the information we gather? If we only talked to open source project leaders, wouldn't that also skew the information we gather?
One thing I want to elaborate upon which Danny kind of brushed over. He used the phrase "non-JSR features". The JCP is the steward of the Java specification. But anybody who has been paying close attention sees features and changes put into the Java platform that are not covered by the JCP or any JSR. How can that be? There is some kind of criteria of the size/complexity of a change which gives a threshold beyond which a JSR is required. I myself don't understand exactly where that threshold is or if it's clearly defined. JDK developers are regularly fixing bugs or RFE's where the fix involves adding some java.* or javax.* class, or make a change in one or more existing java.* or javax.* class. Clearly a small change would not be worthy of a JSR, and those are probably covered en masse by the platform JSR for a specific release (which Danny says has not yet been filed for JDK 7).
As an electric vehicle fan(atic) I found his allegory (while discussing Java language changes) of different types of cars very, uh, interesting. His blog shows a ferrari versus some kind of juiced up pickup truck, and he says he'd prefer the ferrari.
But ... Let me ask you, when you have a choice between one gasoline vehicle and another gasoline vehicle, do you have any real choice? There are hundreds of car models available from a couple dozen car makers, but do we consumers have any real choice? They all burn gasoline (or diesel) and if we care about the environment, or care about world oil-politics and the effect of our oil purchases on e.g. conflict in the Middle East, can we make any real impact? No. The car companies have predetermined that we can only buy gasoline (or diesel) burning vehicles, and that predetermination by the car companies forces us into buying oil which then feeds the problems of environmental degradation and the distortion of world-oil-politics that leads to events like the wars in the Middle East. The predetermination by the big car companies removes from us any meaningful ability to impact the result, because it's very difficult to arrange to have a car/truck/etc which does not burn gasoline or diesel or natural gas.
Which just gets back to what I discussed above about the form of input we are using in planning JDK 7.
The car companies are missing the big issues of environment and world-oil-politics in their planning around development of new car technologies. I wonder if we at Sun, on the Java SE team, are missing similar big issues. But I can say having observed over several years the planning process we've followed up until now, we go to great lengths to bring in a wide range of opinions and ideas.
UPDATE: Both Mark Reinhold and Danny Coward have mentioned in the comments that there aren't any features that are not covered by JSR's. It's that some features get rolled into an umbrella JSR while other features are their own JSR. For example
JSR 270 covers Java SE 6 and provides an overview of the contents and theme of the release.
Source:
weblogs.java.net
