Alex Collins is a enterprise Java developer and currently works in the UK. He has worked in the insurance, publishing, telecoms and supply chain. In his spare time he codes in Python, Clojure and Scala (but not at the same time) and enjoys a multitude of sports. His catchphrase is K.I.S.S! Alex has posted 20 posts at DZone. You can read more from them at their website. View Full User Profile

New schedule for JDK 7 - Lambdas, Coin & Jigsaw in JDK 8?

  • submit to reddit

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?

Published at DZone with permission of its author, Alex Collins.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


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

For a central pice of software such as Java, quality is the most important feature. Not so much to add more and more half ready features. I think plan B is better to ensure quality. I also understand very well that the takeover of Sun teams by Oracle takes time as well as to integrate new engineers.
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

I think that they are right to split the version roadmap. In fact, I think they should clearly separate Java from the VM and define separate roadmaps for both. I have no interest in Java language evolution since we only use it as a legacy language and have no desire to attribute old code with new language constructs. I am however very much interested in VM improvements. Performance improvements are welcome anytime and there are plenty of VM bugs that need fixing. I am afraid people are distracting the developers who are supposed to work on that with discussions about closure syntax etc. A clearer separation where Java evolution may trigger public requests for VM evolution might also make it easier for implementers of other languages (we use Scala as our primary language but also languages like Clojure, JRuby etc come to mind) to influence VM development.

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

Please get real on this moot sentiment of just being able to change to Scala, just like that. Sure 'you' maybe able to, but you will find the majority of real teams this is completely impractical. That 'you' can move to Scala detracts Zero to the fact that these delays are not really happy news for the Java or Development world

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

I think ThoughtWorks needs to spend a bit more time thinking, working and as Dave Chappelle would say "getting real"

Armin Ehrenreich replied on Thu, 2010/09/09 - 11:14am in response to: Dean Schulze

Something to think about for ThoughtWorks:
(if you want to see Scala, you have to remove Java from the search, otherwise it is identical with the base line)
or maybe:
(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

Java is still one of the most popular languages, but a stagnant growth can be the beginning of its decline.

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

What real influence do ThoughtWorks have on anything ?

Dean Schulze replied on Thu, 2010/09/09 - 10:11pm in response to: Liam Knox

ThoughtWorks influence is due to their being a company composed of some of the smartest people in the business.  When Martin Fowler and his colleagues say something many thoughtful people pay attention.

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

Don't buy that. Perhaps if SpringSource actually pricked up and mentioned Java was dead I may pay more than 1 minute of contemplation, but then again that could equally be viewed as corporate suicide at this point in time

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

On this same topic I made a video response to the Re-thinking JDK7, do check it out (geek humor): Behind the scenes of Re-thinking JDK7

Armin Ehrenreich replied on Fri, 2010/09/10 - 4:32am in response to: Dean Schulze

If the people at ThoughtWorks would be really smart, they could realize reality (welcome back on earth):
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

Stagnant growth (if that would be true) is also a sign, that all people that like it, already use it where it makes sense. There is no growth forever. All things reach an upper limit, but this is not anything bad, it is just the normal case. (By the way the number of jobs for C++ programmers stays constant i.e. C++ is already used, everywhere it makes sense)

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

C++ in declined? What are you smoking?, In Japan and other countries in Europe I know, C++ after Java is the most popular language for Enterprise/Financial/ High Tech/ Embedded/ Everything you can imagine not only Games. Also C++ is an ISO Standard and the next revision the C++0x will introduce Closures, Lambdas, Type Inference and much more. You want a C++ web framework ala Wicket try Wt is awesome or cgicc etc and you can see C++ is great also for Web development, C++ Rocks. But also Java Rocks, Java is so simple and compact language to use. If someone thinks Java is verbose or need extra syntactic sugar to get the job done so they already took the dynamic language cool-aid. Real Java hackers knows to use Java in a proper way. Im not saying that Dynamic languages are bad, no the contrary, I personaly love Python is awesome but each tool for the right job. If Java is dead so the JVM is dead too. The JVM is made with Java code and C++ code, Not Clojure, Not Scala, Not groovy.

Dean Schulze replied on Fri, 2010/09/10 - 1:31pm in response to: Jacek Furmankiewicz


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

the next revision the C++0x will introduce Closures, Lambdas, Type Inference and much more

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

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.

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

Hahah Duke Nukem forever they said it will be ready for 2012. About C++0x already GCC/G++ and Microsoft compiler implements lots of the features, I already using auto for the type inference and also Im using lambdas. They said C++0x will be ready for 2012 maybe this time will be not so late the compilers vendors to implement the spec as was the c++98 that took more longer because C++ was not mature enough in that time but right now C++ is mature and with Boost and everything rocks. Anyway you want my bet heheh is for C++0x!, 2012.

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?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.