New schedule for JDK 7 - Lambdas, Coin & Jigsaw in JDK 8?
Mark Reinhold principal engineer at Sun/Oracle, breathes some common sense into the JDK 7 release schedule with a suggestion of a 2011 release, but with a catch.
In his latest blog post, Mark details that the current schedule for JDK7 is somewhat ambitious, and that "The post-acquisition integration process took longer than any of us anticipated, unfortunately, but we’re now ready and able to focus on this release with a larger (and still growing) staff which will continue to work in the open alongside other contributors". So JDK7's still going ahead, phew! In this climate though, what with Oracle vs Google, project after project of Sun's being shutdown one might think Java's not safe. Forgive my paranoia!
Back to the point: Mark states that the current state of JDK 7 is in good shape, with most of the features - bar Lambdas, projects Coin and Jigsaw - either finished or "nearly done". This means then that we could expect JDK7 sooner rather than later; should we wait we'd have JDK 7 with project Coin & Jigsaw as well as Lambdas in mid-2012, which is a way away and would make JDK 6 yonks old (a quick estimate says 6 years!).
So according to the blog post,
we could have two schedules, the latter of which Oracle is "heavily
leaning towards". To quote Mark again:
| Plan A: | JDK 7 (as currently defined) | Mid 2012 |
| Plan B: | JDK 7 (minus Lambda, Jigsaw, and part of Coin) | Mid 2011 |
| JDK 8 (Lambda, Jigsaw, the rest of Coin, ++) | Late 2012 |
So we'd have JDK 7 with some nice features earlier than expected, but the big ones in 2012. What do you think? Worth the wait or shutting the barn door after the horse has bolted?
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)





Comments
Mario Fusco replied on Thu, 2010/09/09 - 4:13am
Personally I don't think it worth to wait. Why should I wait for something that I can already have (together with many more fantastic goodies) with scala?
Anyway in my opinion there is a far more important question to ask: why did they set a so completely unrealistic deadline? Why did they lie knowing that they were lying for so long?
I KNEW it was practically impossible to meet that deadline the very day they announced it at last Devoxx on November 2009. And if I knew that I cannot believe they didn't know it better than me.
The fact that we won't have the JDK 7 in a reasonable time is only something marginal, compared with the fact that evidently we cannot rely in any way on the company that controls its development.
Armin Ehrenreich replied on Thu, 2010/09/09 - 4:34am
By the way, I think that the numbering scheme of Java is unfortunate. If they would have called this Java 6 u10 with its big technical advancements simply Java 6.5 then it would have looked better ;-)
Silvio Bierman replied on Thu, 2010/09/09 - 5:43am
Roman Ilin replied on Thu, 2010/09/09 - 8:23am
+1 for separating Java and JVM.
The time Java was only citizen on JVM is over.
And every language on top of JVM have to treated equally to each other.
And with own release cycles.
Liam Knox replied on Thu, 2010/09/09 - 9:06am
in response to:
Mario Fusco
On the unrealistic deadlines, seems pretty par for the course in Software development and coupled with the Oracle factor adds another spin.
Dean Schulze replied on Thu, 2010/09/09 - 9:44am
The long delay - and uncertainty - in getting new features into JDK 7 is what has motivated ThoughtWorks to put the End of Life for Java as a language on the JVM into the Assess category on their Technology Radar. They like the JVM, but they are concerned about Java as a language going forward.
The managers at Oracle should be concerned when ThoughtWorks is considering end-of-life for Java.
Jacek Furmankiewicz replied on Thu, 2010/09/09 - 10:29am
in response to:
Dean Schulze
Armin Ehrenreich replied on Thu, 2010/09/09 - 11:14am
in response to:
Dean Schulze
http://www.indeed.com/jobtrends?q=Java%2C+Ruby%2C+Groovy%2C+Scala&l=
(if you want to see Scala, you have to remove Java from the search, otherwise it is identical with the base line)
or maybe:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
(Scala is the last but one in this list).
So Scala is a very good language, no question. But Java is by very far the most important language on the JVM
Henk De Boer replied on Thu, 2010/09/09 - 4:27pm
C++ was once very popular, but there didn't came any new version. Then a new version was promised, but it didn't came. Then a new date was announced for this new version and again it didn't came.
Now less and less people use C++, especially for new projects (except for games, where it's still strong).
Liam Knox replied on Thu, 2010/09/09 - 5:45pm
in response to:
Dean Schulze
Dean Schulze replied on Thu, 2010/09/09 - 10:11pm
in response to:
Liam Knox
Dean Schulze replied on Thu, 2010/09/09 - 10:21pm
in response to:
Armin Ehrenreich
What ThoughtWorks is saying (if I understand their Technology Radar correctly) is that it is time to assess if Java should be end-of-lifed. Their rational was that it had taken too long to get new features into the language, based on the amount of time it will take to get JDK 7 released. The several year span between the release of JDK 6 and JDK 7 is unacceptable in an industry as fast paced as software development.
Maybe Oracle can get Java moving at an acceptable speed, or maybe an open source implementation can respond fast enough. But Sun's stewardship of Java has resulted in slow releases of major enhancements to the Java language.
If you actually look at Thoughtworks Technology Radar you'll see that they like the JVM. It's the Java language that they are concerned about. There are more promising alternatives on the JVM (Groovy, Scala, Clojure, etc.).
Liam Knox replied on Fri, 2010/09/10 - 2:06am
in response to:
Dean Schulze
Martin Fowler has always come across over hyped in my opinion, talks a good game, wrote some very tedious books and hasnt really delivered much inovation to boot. To be honest I wouldn't think any Fortune 500 company would of ever heard of him let alone ThoughtWorks latest views on Java
IThoughtWorks will be writing a large amount Java for a dam longtime to come if they want to remain active. That just fact given language foot print.
Monis Iqbal replied on Fri, 2010/09/10 - 3:54am
Armin Ehrenreich replied on Fri, 2010/09/10 - 4:32am
in response to:
Dean Schulze
1. The number of Java jobs in the industry is growing, not shrinking (see graphs above)
2. Java (language) gets mature in its feature set. It will be increasingly harder to add useful new ones.
3. Java (language) needs to stay manageable. It is a goofy idea that something simply gets a better tool when adding features to it. The opposite is true. A tool needs a certain stable feature set to get the work done. Too many features make the tool inelegant and inconvenient to use for the majority of people. Smart people should know that!!
3. If you prefer the functional way of programming on the JVM use Scala, Groovy or Clojure. Everyone knows by now. But if you look at reality (see above) smart people should realize that up until now a small minority of people does this for various reasons and this will not change soon.
Armin Ehrenreich replied on Fri, 2010/09/10 - 4:39am
in response to:
Henk De Boer
Jacek Furmankiewicz replied on Fri, 2010/09/10 - 10:03am
in response to:
Dean Schulze
Earth to ThoughtWorks...if you knew anything about Java, you would know that the enhancements in Spring, Hibernate, Java EE, etc, etc. are just as important (or even more important) than the core language intself.
And these have been coming fast and furious in the time between Java 6 and 7.
I have to wonder if these guys ever wrote or deployed a single Java app in production....
Otengi Miloskov replied on Fri, 2010/09/10 - 11:12am
in response to:
Armin Ehrenreich
Dean Schulze replied on Fri, 2010/09/10 - 1:31pm
in response to:
Jacek Furmankiewicz
Jacek,
Why should the pace of adoption in the core language lag so far behind those frameworks?
When one person can write a new language (more correctly a new dialect of Lisp ported to the JVM) like Clojure, and get several minor versions of it out in less time than it takes Sun / Oracle to go from JDK 6 to JDK 7 that is a problem.
And the pace of development of Sun's other JVM-based language - JavaFX - well don't get me started on that one.
Henk De Boer replied on Fri, 2010/09/10 - 1:36pm
in response to:
Otengi Miloskov
But the question is, will it be C++0x, (covering 2000-2019) or C++1x (covering 2020-2039) or perhaps C++2x (covering 2040 and later).
Don't forget it may take another 10, 20, 30 or more years until this next version of the C++ spec is released. By then, will Closures, Lambdas and other stuff still be considered as advanced and special?
At the office we have a big bet running about which will be released first, Duke 'm Nukem forvever or the nest version of C++. At the moment the entire bet is on Duke 'm Nukem.
Henk De Boer replied on Fri, 2010/09/10 - 1:47pm
in response to:
Dean Schulze
I do think a large portion of the work is dedicated to the JDK library and the JVM, and not so much to the core language itself. Of course, lambdas and projection coin definitely concerns core language stuff but much of what went into the previous 100+ builds of JDK 7 are JDK things.
Also, don't forget we got a fair amount of JDK 7 things in JDK6u10. Other things like escape analysis, the G1 GC (although experimental) and compressed oops have also been back-ported. A part of the problem is in the awkward U scheme that Sun suddenly started to use. Currently, an U update can either be a major change to the Java platform or a simple little update to the timezome data.
Otengi Miloskov replied on Fri, 2010/09/10 - 9:40pm
in response to:
Henk De Boer
Henk De Boer replied on Sat, 2010/09/11 - 3:45am
in response to:
Otengi Miloskov
We'll see... They also said 2003, and then 2005 and 2006 and 2008 and 2010... So basically, I don't really get excited about any "they say it will be" stuff.
I do agree that this time around the major compilers do already support parts of the draft spec, so that's a major difference. It would be absolutely killing if we had to wait another 10+ years again after the release of the spec for it to be fully implemented.
Nevertheless, I do love the C++ language, but the two waits just have been horrendous (the first wait for getting C++98 implemented, and the second wait for C++0x to be released). By all accounts, both waits were far too long, weren't they?