Mark Reinhold, Chief Architect of the Java Platform Group at Oracle, accepted in his September 8th blog that the current timeline for the release of Java 7 is a tad unrealistic, and that a full increment release shouldn't be expected until the middle of 2012. "Our present best estimate is that we could complete, test, and stabilize the planned work in time for a release around the middle of 2012."

At the very least, 2012 will bring with it everything we currently expect to see in Java 7, including Lambda, Jigsaw and Coin. Only, it looks like that version of Java 7 will be called Java 8. By doing that, Oracle could test and release everything they've got working so far as Java 7, and add the extra bits into another full increment release closely thereafter. "Our current estimate for this 'Plan B' is that we could ship a reduced JDK 7 in mid-2011 and JDK 8 in the second half of 2012."

Of course, the problem with the delay is less about the technology, and more about the optics. The Java community is suffering through a great deal of uncertainty with the stewardship of the technology now resting in the hands of Oracle. The reality is that the Java Platform Group at Oracle is working hard to get Java 7 tested and released. The optics is that Java is stagnating. "I think what really makes people unhappy is not the modest Java 7 feature set but the five year gap since Java 6." Says Cay Horstmann in his blog on the topic.

What the Java community would like to see is Oracle really throwing their weight behind the Java platform. What we need to hear is someone at Oracle coming out and saying: "Look, we're the strongest software company in the world, and we're one hundred percent behind Java. We're not going to let release dates for our flagship development platform slip, and that's why we're going to dedicate more resources than ever to make sure Java 7 gets released, ahead of schedule, and with all of the features the community expects to find." 

Unfortunately, that's not what we're getting. A five year gap between full increment releases is just too much. Someone at Oracle really needs to take the reigns, and demonstrate to the Java community that they're dedicated to the evolution and progression of the Java platform.

IMHO, Plan B looks like the best idea for everyone :
- early adopters would be happy playing sooner with a new release (JDK 7), within the next months.
- other people would wait the following first "Service Pack" release (JDK 8) for adopting a new JDK, after JDK 6.

Dominique

http://www.jroller.com/dmdevito

Posted By: Neeraj Vora On Sep 10, 2010 12:36 PM

The civilized world is still heavily using Java circa 2010. Cave world, not sure how they program their computers, maybe some new scripting dialects or ancient languages?

Cameron,

Thanks for the great post. I too hope that Oracle will duely step up to the plate. While actions are louder than words, just a little more intermittent words from Sun/Oracle certainly is not unhelpful :-). At least they did make an announcemtn on their intent and status for Java SE though...

Cheers,

Reza

Not sure why people are even waiting for java 7 when there is scala and clojure for the jvm now. 

Eric

people are waiting because no body wants to learn a new language even if it runs on Java VM

http://www.thejavacode.com/websphere-application-server-7-p10048.html#p10048

new posts

Eric

people are waiting because no body wants to learn a new language even if it runs on Java VM

http://www.thejavacode.com/websphere-application-server-7-p10048.html#p10048

new posts

You mean lazy people don't want to learn a new language even if it runs on the Java VM.  Those of us who care about productivity have learned, or are learning, Clojure.  

"Those of us who care about productivity have learned, or are learning, Clojure."

Clojure is a niche market language. Speaking of productivity with Clojure by average Joe software developer, and Joes account for 90%+ of market workforce, makes no sense. Don't believe me? Present Clojure code example of moderate complexity to Joe, and ask him what he thinks.

Re-training 90% of the workforce when there is no evidence that it is viable investment, is a bad business move. Clojure is not making paradigm shift as Java did with GC.

"Those of us who care about productivity have learned, or are learning, Clojure."

Clojure is a niche market language. Speaking of productivity with Clojure by average Joe software developer, and Joes account for 90%+ of market workforce, makes no sense. Don't believe me? Present Clojure code example of moderate complexity to Joe, and ask him what he thinks.

Re-training 90% of the workforce when there is no evidence that it is viable investment, is a bad business move. Clojure is not making paradigm shift as Java did with GC.

I'm a big fan of LISP and LISP-inspired languages, but the reality is 75% of the developers out there can't "get use to" S-expression syntax. You either like S-expression or you don't. Those who don't will never be productive in the language, that's just human nature. I personally wish more people would learn from LISP and Prolog, but the reality is 80% of the developers won't. C/C++/Java/C# syntax is much more comfortable to humans, which is "probably" why it's so popular. I happen to think Clojure is wicked cool, but I seriously doubt people will change enough that S-expression will magically be the dominant language.

my bias 2 cents.

Peter Lin is exactly right, but I would put the percentage of Java developers that will NEVER, EVER be comfortable with S-expressions at about 95%.

I guess if I could wave a magic wand, I would give Clojure a Dylan-like syntax (not as verbose), with some of the gradual typing capabilities of Dylan too.

Scala would probably have better uptake, but there still seems to be big issues with getting the level of IDE support that developers enjoy in Java-land.

Peter Lin is exactly right, but I would put the percentage of Java developers that will NEVER, EVER be comfortable with S-expressions at about 95%.

I guess if I could wave a magic wand, I would give Clojure a Dylan-like syntax (not as verbose), with some of the gradual typing capabilities of Dylan too.

Scala would probably have better uptake, but there still seems to be big issues with getting the level of IDE support that developers enjoy in Java-land.

I'm gonna guess 95% is closer to reality. The optimist in me hopes it's lower, but first hand experience is closer to 95%. Even people that aren't bother by S-Expression don't necessarily "fall in love" with LISP like language. Atleast within the production rule engine and business rule engine world, there's a ton of people who hate LISP syntax. As a result, they tend to "invent" their own language without taking time to understand why LISP syntax was chosen.

Outside of production rule engine world, tons of developers hard time with "all those parens" and feel LISP is aweful. The hard core LISP-ers tend to still use Emacs :)

Someone asked if Clojure would be successful, and I basically replied "No, because Closure is a Lisp". Boy, did that stir the pot.

I mean, clearly Clojure is "successful". It's well received, well supported. But it's certainly not popular, and barely on the fringe of mainstream.

But the facts speak for themselves. Lisps are unpopular in the large. There are skilled people using Lisp, and Lisp is arguably the most "powerful" of the languages out there, since it, literally, does "everything". Pick a paradigm and Lisp does it well.

I'm a big Lisp fan, but I don't use it.

Lisp, in its several forms, has had every opportunity to prevail -- and it doesn't. It's fast, it's slow, it's supported, it's free, it's expensive, it's multi-platform, it's big, it's small. There is a Lisp for every occasion. And it doesn't dominate in any particular area, and many of its bullet list features have been usurped by others.

It's pinnacle, today, is basically JavaScript. JavaScript is effectively a Scheme (which is a Lisp). Obviously, at a glance, it doesn't appear that way. But the Scheme and JavaScript runtime and semantics are nearly identical at the core.

Dylan gave us Scheme "syntax-rule" style template macros, vs Common Lisps wild west style defmacro "lists". I would like to think that adding syntax-rule style macros to JavaScript would be almost straightforward. Because macros is pretty much the last bastion that Lisp typically holds over most other environments. (Common Lisp also has the Reader, but that's simply not going to port.) But I don't think macros are in the plan for JavaScript.

Too bad. I like macros.

The dynamic push in to the JVM with Ruby, Python, Scala, Clojure, etc. etc. etc. is a good thing. We can only hope that the Java 7/8 JVMs will enable those projects to be even better.

I'd like to point a finger at the RESTx project, which is a Python core on top of the JVM with Java extensions, and they just added JavaScript as well. A neat multi-lingual project that really helps show off the JVM as a true melting pot of ideas and technology.

But that said, I look forward to whatever Java 7/8 bring. Java and the JVM have had a profound impact on computing. It has most every major paradigm within its community today, much like Lisp does. The syntax is not as flexible by any account as Lisp, but the runtime is. Many of the things that "can't be done" in Java are being done today, previously through XML files and runtimes, now moreso through Annotations, the only really extensible syntax Java has today.

Someone asked if Clojure would be successful, and I basically replied "No, because Closure is a Lisp". Boy, did that stir the pot.

I mean, clearly Clojure is "successful". It's well received, well supported. But it's certainly not popular, and barely on the fringe of mainstream.

But the facts speak for themselves. Lisps are unpopular in the large. There are skilled people using Lisp, and Lisp is arguably the most "powerful" of the languages out there, since it, literally, does "everything". Pick a paradigm and Lisp does it well.

I'm a big Lisp fan, but I don't use it.

Lisp, in its several forms, has had every opportunity to prevail -- and it doesn't. It's fast, it's slow, it's supported, it's free, it's expensive, it's multi-platform, it's big, it's small. There is a Lisp for every occasion. And it doesn't dominate in any particular area, and many of its bullet list features have been usurped by others.

It's pinnacle, today, is basically JavaScript. JavaScript is effectively a Scheme (which is a Lisp). Obviously, at a glance, it doesn't appear that way. But the Scheme and JavaScript runtime and semantics are nearly identical at the core.

Dylan gave us Scheme "syntax-rule" style template macros, vs Common Lisps wild west style defmacro "lists". I would like to think that adding syntax-rule style macros to JavaScript would be almost straightforward. Because macros is pretty much the last bastion that Lisp typically holds over most other environments. (Common Lisp also has the Reader, but that's simply not going to port.) But I don't think macros are in the plan for JavaScript.

Too bad. I like macros.

The dynamic push in to the JVM with Ruby, Python, Scala, Clojure, etc. etc. etc. is a good thing. We can only hope that the Java 7/8 JVMs will enable those projects to be even better.

I'd like to point a finger at the RESTx project, which is a Python core on top of the JVM with Java extensions, and they just added JavaScript as well. A neat multi-lingual project that really helps show off the JVM as a true melting pot of ideas and technology.

But that said, I look forward to whatever Java 7/8 bring. Java and the JVM have had a profound impact on computing. It has most every major paradigm within its community today, much like Lisp does. The syntax is not as flexible by any account as Lisp, but the runtime is. Many of the things that "can't be done" in Java are being done today, previously through XML files and runtimes, now moreso through Annotations, the only really extensible syntax Java has today.

I couldn't agree more. Clojure is fantastic, but like all LISP implementations, it won't have mass adoption by the general programming world.

Eric

people are waiting because no body wants to learn a new language even if it runs on Java VM

http://www.thejavacode.com/websphere-application-server-7-p10048.html#p10048

new posts

That'a a pretty discouraging characterization of the current java community but unfortunately, its probably generally true.  

This is completely true

I mean the part of java bing slow in releases

unlike microsoft which makes a release almost every 2 or 3 years advancement in Java takes much longer because of the process

I'm not sure what Oracle will do but I home it keeps it moving

<a href="http://www.thejavacode.com/websphere-application-server-7-t9764.html#p10048">Websphere 7</a>

The reality is that the Java Platform Group at Oracle is working hard to get Java 7 tested and released. The optics is that Java is stagnating.

Or in other words: "Who are you going to believe, me or your lying eyes?"

I believe the most important question to be asked here is how much the giants are going to be supporting the new languages such as Lisp and Clojure?
What is the status of IBM and Oracle?
Is the open source community ready for transformation?
After all business is going to be the dominant drive for this move
EJB3 Tutorial

Why can't Sun/Oracle release on a milestone plan like JBoss has been doing recently?  Get some features out the door faster so the end-users can test and provide feedback?  5 yrs is damn long!