Posted by editor
on August 29, 2012 at 1:11 PM PDT
In the most recently completed Java.net poll, a majority of the voters indicated a preference for having major Java releases on a predictable schedule (either a fixed number of months, or a narrow range of months). A total of 683 votes were cast in the poll...
In the most recently completed Java.net poll , a majority of the voters indicated a preference for having major Java releases on a predictable schedule (either a fixed number of months, or a narrow range of months). A total of 683 votes were cast in the poll, and one comment was posted. The exact question and results were as follows:
Should Java have a timed release schedule (for example, a new major release every 18 months)?
- 48% (331 votes) - Yes, that works best for the community
- 12% (79 votes) - Timed releases, but with some flexibility (like 18-24 months), would be ideal
- 2% (11 votes) - Maybe
- 18% (126 votes) - No, a new release should happen only when significant enhancements are ready
- 3% (18 votes) - I don't know
- 17% (118 votes) - Other
So, 60% of the voters consider knowing that the next major release of Java will come out approximately N months after the previous major release to be most helpful for the community. A much smaller share (18%) would rather know that significant new features will be in the next major release, even if the date when the release will come out isn't readily predictable.
commented: "Timed releases means incomplete or buggy realeases because of time."
A problem for Java, compared with, for example, Eclipse, is that the next major release can no longer simply be a bunch of cool new added features that are built on top of what's already there. Enhancements like Project Lambda and Project Jigsaw require overhauling a large existing code base that works.
For projects like Eclipse (which has annual major releases), this is not case: there, the enhancements are largely new or updated add-on modules, along with enhancements to the core application. You don't have to destroy what worked in the last version, and rewrite it so that it works under a new architectural schematic or paradigm.
But this is exactly what has to be done in the case of Lambda and JigSaw. With Lambda, I was surprised at last year's JavaOne to see the quite innovative approach that was being taken to minimize the time and effort to bring closures to Java. Still, there aren't many pieces of core Java that can just be left untouched -- or, at least, nearly every function in every core library has to be examined and tested to see if it's threadsafe. And if changes are needed, then the entire function has to be retested to make sure it still works as it did before under single-threaded operation, as well as when it's utilized by code that's within a closure running on a many-processor machine. That's a lot of work!
With JigSaw, the task sounds just as bad, or worse, since all kinds of internal dependencies have been interwoven into Java during two decades of active development by perhaps tens of thousands of different developers, with various skill sets and development practices, with few people having any reason to anticipate that some day there might be a need to unwind all of this into coherent, self-contained modules...
In his recent post Project Jigsaw: Late for the train: The Q&A" , Mark Reinhold put it this way:
the JDK code base is deeply interconnected at both the API and the implementation levels, having been built over many years primarily in the style of a monolithic software system .
Click Mark's link for more interesting details on the monolithic nature of the JDK...
So, when you consider both Project Lambda and Project Jigsaw together, it really is like the originally planned Java 8 was basically going to blow up almost the entirety of existing core Java, and replace it with something very new and different -- while at the same time expecting Java 8 to maintain close to perfect backward compatibility! Daunting tasks...
I think it's very difficult for a development team to maintain scheduled releases when the primary enhancements fundamentally change the existing underlying architecture.
New poll: predict the future of JVM languages
Our new poll provides you with an opportunity to prognosticate! It asks: 10 years from now, which JVM language will be used most for new software development projects? . Voting will be open until Friday, September 7.
Here are the stories we've recently featured in our Java news section:
Our latest Java.net Spotlight is Jfokus 2013 Call for Papers :
Jfokus will consist of three full days 4-6 Feb 2013. The first day will be a university day with half-day presentations (3.5 hours) and 5-6 February will be regular conference days. Here you can propose a presentation for Jfokus 2013. We will get back to you as soon as we have decided which presentations will be accepted. Last day for submitting proposals is October 1...
Prior to that, we featured Heather Van Cura's JSR 355 Final Release, and moves JCP to version 2.9 :
a href="http://jcp.org/en/jsr/detail?id=355" title="JSR 355">JSR 355, JCP EC Merge, passed the JCP EC Final Approval Ballot on 13 August 2012, with 14 Yes votes, 1 abstain (1 member did not vote) on the SE/EE EC, and 12 yes votes (2 members were not eligible to vote) on the ME EC. JSR 355 posted a Final Release this week, moving the JCP program version to JCP 2.9. The transition to a merged EC will happen after the 2012 EC Elections, as defined in the Appendix B of the JCP (pasted below)...
Our latest Java.net article is Default Constructors by Mala Gupta, author of the Manning Publications book OCA Java SE 7 Programmer I Certification Guide .
Subscriptions and Archives: You can subscribe to this blog using the java.net Editor's Blog Feed . You can also subscribe to the Java Today RSS feed and the java.net blogs feed .
-- Kevin Farnham (@kevin_farnham )