Re-thinking JDK 7

It’s been clear for some time that the most recent JDK 7 development schedule is, to put it mildly, unrealistic.

We created that schedule over nine months ago, prior to the acquisition of Sun by Oracle. 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, whither JDK 7?

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.

Looking at what’s in the forest today, however, much of that work is in fact already done, or very nearly so. The main outstanding items are the Lambda and Jigsaw Projects, along with a few of the Coin proposals. We’ve made a lot of progress on these features, and they now have more Oracle engineers working on them than before, but significant work remains to be done.

Another possibility, therefore, is to take everything we have now, test and stabilize it, and ship that as JDK 7. We could then finish Lambda, Jigsaw, the rest of Coin, and maybe a few additional key features in a JDK 8 release which would ship fairly soon thereafter.

This approach would give developers production-quality access to the nearly-finished features sooner rather than later, and with much less risk. It would also allow more time to really shake out Lambda and Jigsaw, which is critical given that these higher-risk efforts are making deep changes to the very foundations of the platform.

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.

To summarize:

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

(As always, our intent is that JDK 7 will ship concurrently with a Java SE 7 JSR, and likewise for JDK 8 and Java SE 8, and also that there will be JSRs for Lambda and Coin.)

Here at Oracle we’re leaning heavily toward the lower-risk Plan B. The platform has been idle for (more than!) long enough—it’s time to get Java moving again. If there are good reasons to prefer Plan A, however, then I’d like to hear them.

Comments:

One (non-technical) issue with Plan B may be that there could be a low adoption in the enterprise. I can imagine companies not upgrading when they know that a new release is already planned for the next year. But, then again, is this really an issue? I guess not...

Other than this, Plan B sounds very good.

Can you provide a list of features that would be part of JDK 7 if Plan B is executed?

Posted by Jan-Kees van Andel on September 08, 2010 at 02:46 AM PDT #

What's the current status of the various Coin's proposals? Which ones are likely to be in JDK 7 and which ones for JDK 8?

Posted by Guillaume Laforge on September 08, 2010 at 02:53 AM PDT #

release early, release often.

Posted by michael bien on September 08, 2010 at 02:57 AM PDT #

The slip is bad news, but I suppose it's also good news that the JCP process will be observed. With the current schedule, the only realistic possibility to have JDK7 shipping in late 2010 required both excluding the unfinished pieces and completely ignoring the JCP (perhaps just issuing some fake, rubber-stamp JSRs). There are other pending issues with the JCP in the post-Oracle era, and I suppose Oracle will make some announcements at the JavaOne in a couple weeks, but this already looks like good news.

Posted by Osvaldo Pinali Doederlein on September 08, 2010 at 02:59 AM PDT #

Yes, please do Plan B, I'd much rather see some features released next year than none at all. 2012 is so far away...

Posted by Adam L. Davis on September 08, 2010 at 02:59 AM PDT #

As it sounds like there is a great deal of work that has to be done, why not open up parts of it to the community? The platform has been delayed a great deal already, and this sounds like another year just to get a JDK 7. If things are that close, get lots of volunteers to test and try the thing to death and release sooner. That will breath some new life into the platform and then get help with JDK 8 so that it can release toward the end of 2011.

Posted by Robert Casto on September 08, 2010 at 03:02 AM PDT #

@JanKees: One thing we have observed about upgrade adoption is that the perceived "weight" of the release has a big effect on adoption rate. JDK 5 took a long time to adopt, because it was perceived as a "big" release; JDK 6 adoption was faster because it was perceived as a "small" release. (In fact, a nontrivial chunk of customers jumped from 1.4 to 6 because they waited so long to adopt 5.)

So yes, some people may stall on adoption of 7 if they think an 8 is around the corner. On the other hand, more frequent releases give customers more flexibility and delivers value more frequently and steadily.

Posted by Brian Goetz on September 08, 2010 at 03:05 AM PDT #

Hi Mark,

To me, "JDK 7 minus Lambda, Jigsaw and part of Coin" doesn't sound much like "Getting Java moving again" :-(

This schedule is very disappointing.

Posted by Cedric on September 08, 2010 at 03:06 AM PDT #

What exactly is "JDK 7 minus Lambda, Jigsaw and part of Coin" ?

Posted by Daniel Serodio on September 08, 2010 at 03:18 AM PDT #

What Mark's blog misses is what's _in_ OpenJDK7, rather than what's not there. Ismael Juma kindly provided a quick overview (http://mail.openjdk.java.net/pipermail/jdk7-dev/2010-September/001529.html):

- invokedynamic and method handles for other language support
- nio.2 (asynchronous I/O and much better file/directory support)
- parallel classloading
- from Project Coin:
- 6860965: Support for binary literals (e.g. 2 can be written 0b10)
- 6860965: Support for underscored literals (e.g. 123456 can be written 123_456)
- 6827009: Support for strings in switch statements (e.g. case "a")
- 6840638: Improved inferencing with generics, e.g. Map<String,Integer> map = new HashMap<>();
- jsr166y from http://gee.cs.oswego.edu/dl/concurrency-interest/:
- 6865571: Add a lightweight task framework known as ForkJoin
- 6445158: Phaser - an improved CyclicBarrier
- 6865579: Add TransferQueue/LinkedTransferQueue

Adam, the code is already available for testing. The Mercurial trees are there and there have been plenty of build snapshots from Oracle. But most people won't try something until there is a release. I'd much rather we had frequent releases, the feedback from which then flows into future releases, than working on something for years and then releasing it, when the multitude of features will also result in a multitude of bugs.

So strongly in favour of Plan B here, and I hope we'll see OpenJDK break into jdk7 and jdk8 trees soon for stabilisation.

Posted by Andrew John Hughes on September 08, 2010 at 03:20 AM PDT #

JDK 7 - (Lambda + Jigsaw + part of Coin) = Most of Coin + NIO.2 (JSR 203) +
InvokeDynamic (JSR 292) + "JSR 166y" (fork/join, etc.) + most everything else
on the current feature list (http://openjdk.java.net/projects/jdk7/features/) +
possibly a few additional features TBD.

Posted by Mark Reinhold on September 08, 2010 at 03:26 AM PDT #

Cedric said:
What exactly is "JDK 7 minus Lambda, Jigsaw and part of Coin" ?

JDK 6!

This is sad sad news. Hello Scala, nice to meet you!

Posted by Ian Schumacher on September 08, 2010 at 03:30 AM PDT #

Why would JDK7 of Plan B still take until mid 2011? It seems most work on those parts is done?

Posted by Niels on September 08, 2010 at 03:34 AM PDT #

I'm not convinced that plan B that delivers a JDK7 that is compelling enough for enterprises (or even individual developers) to move to. For me it would be missing too many significant goodies, it also probably means that some other JSRs (such as Date and Time) would probably not have enough time to get into Java 7.

Idle thoughts:

\* I wonder if no release until mid 2012 would mean a boost in the developer base for other JVM languages?

\* I also wonder about the impact of the Google lawsuit, is there going to be any 'difficulties' in getting a JDK7 JSR through the process?

Cheers,
Martijn

"Disclaimer, I'm in the process of writing "The Well-Grounded Java 7 Developer" so I have bias :).

Posted by Martijn Verburg on September 08, 2010 at 03:39 AM PDT #

say it with me, out loud - SCALA!!

Posted by Walter Chang on September 08, 2010 at 03:40 AM PDT #

Either plan is disappointing.

If Oracle wants to do something to boost java, they could buy the Excelsior JET AOT compiler and give it out for free. I bet a lot more people would consider java for desktop development then.

Posted by soren on September 08, 2010 at 03:40 AM PDT #

Will JSR-310 Date and Time API make it into JDK7 with plan B?

Posted by Håkon on September 08, 2010 at 03:44 AM PDT #

So this is what Larry meant by investing a whole lot of money in Java?!

Posted by Walter Chang on September 08, 2010 at 03:52 AM PDT #

JDK 6 is pretty damn good at the moment, so there is no pain here .. although Plan B does sound like a good option to me.

Posted by Raffi M. on September 08, 2010 at 04:04 AM PDT #

What a whiny bunch we all are :)

Plan B sounds realistic and would add significant value sooner rather than later.

I know much work has gone into back porting many of the backend features (hotspot, gc, etc) into JVM 6. To my eye, this is risker than just releasing and not having the overhead of doing a double integration tests.

To those chanting Scala, you should be \*highly\* in favor of plan B. Scala, after all is built on the JVM, and the sooner the incredible backend efforts (\*cough\* invokedynamic \*cough\*), get into a mainstream release, the sooner your language of the day will run better.

Perhaps to appease people, you should do a "6.5", or at least informally refer to it like that?

Thanks for all the hard work guys!

Posted by Adam Malter on September 08, 2010 at 04:12 AM PDT #

I agree with Brian...
Those schedules are very disappointing...

Posted by Yang Ful on September 08, 2010 at 04:20 AM PDT #

(\*cough\* invokedynamic \*cough\*) I thought invoke dynamic would only benefit dynamic languages like groovy and jruby?

Posted by sboulay on September 08, 2010 at 04:30 AM PDT #

I can't deny I'm very disappointed project JigSaw is delayed again. And that the lack of support for this project this last year amazes me really. Because it would have made Java much lighter and faster. And allow it - finally - to shed its reputation of a heavyweight system and compete head on with the others.

But what's really saddening me is that this means JavaFX won't stand much of a chance either. To run the simplest JavaFX application we'll still need the full download and complex installation. :-(

But then again, we're all software engineers. We know how these things usually go... Can't blame Mark for this.

Posted by Jan Goyvaerts on September 08, 2010 at 04:35 AM PDT #

Plan B! It already contains enough good stuff and I suspect the adoption rate will be high because the changes are not too radical.

Posted by Joe Bowbeer on September 08, 2010 at 04:40 AM PDT #

The improved file / directory support in NIO.2 alone justifies Plan B imvho. Anyone who has tried to do anything beyond basic file I/O in Java would probably agree.

Posted by Peter on September 08, 2010 at 04:43 AM PDT #

Plan B is obviously the better plan. I thought JDK7 was actually slated for later this year though? Oh well, with any luck the reduced JDK7 can ship early in 2011.

Posted by thom on September 08, 2010 at 04:45 AM PDT #

Hi all! This is a \*proposal\* by Oracle for feedback, and we do appreciate all the comments so far. Regarding the schedule slip, it's true that most features in the "stripped down" JDK7 in Plan B are implemented but there is a huge backlog of testing and bugfixing to be done before it is useful. Hence the delay. This is not a matter of Oracle holding back. It is a matter of us having reviewed the current state of the code and being realistic. Believe me, if we could we would love to release everything tomorrow!

Cheers,

Henrik Ståhl
Sr. Director, Product Management
Java Platform Group

Posted by Henrik Ståhl on September 08, 2010 at 04:48 AM PDT #

Too bad that Oracle bought Sun.

If Google had bought Sun instead they would just release Java 7 in its current state simply by bumping a beta tag onto it. :p

Posted by Joern Huxhorn on September 08, 2010 at 04:52 AM PDT #

I vote for plan B: little and often is easier to absorb, quicker to generate feedback, etc, etc.

Cf "Big Bang" which tends to invite disaster.

Rgds

Damon

Posted by Damon Hart-Davis on September 08, 2010 at 04:53 AM PDT #

As Guillaume Laforge wrote: "release early, release often"

(And do not use software patents against competitors)

Posted by Andreas Kuckartz on September 08, 2010 at 05:12 AM PDT #

Plan B.
I prefer to ship often and quickly than late. And Java 6 was shipped almost 5 years ago

Posted by Rafael Nunes on September 08, 2010 at 05:13 AM PDT #

Plan B sounds to me like an excuse to claim Java as alive and well when really it's not. Neither A nor B is particular compelling and I think alternatives to Java will get yet another boost; meaning, having to endure even more Scala evangelism. But if it has to be one, B it is.

Posted by Casper on September 08, 2010 at 05:14 AM PDT #

I think plan B would be great especially if Automatic Resource Management from Coin can be put on JDK 7. Even if it couldn't be in JDK7 I vote Plan B with the following moto in mind: release early, release often.

Could you clarify us what parts of Coin will be on Plan B?

Posted by Emerson on September 08, 2010 at 05:19 AM PDT #

We can all agree that it's disappointing that the schedule slipped! Even though I would love to get my hands on lambdas, I would much rather prefer a new release of Java to keep the kettle from freezing...
So even though big players wont adapt, a lot of other Java devs and influencers will get their hands on it - so I'm in favor of release "early", release "often" ;)

Plan B get a vote :)

/Jeppe

Posted by Jeppe Cramon on September 08, 2010 at 05:19 AM PDT #

please plan B!

Posted by Georges Gomes on September 08, 2010 at 05:26 AM PDT #

C: Why don't release the new features each one at once, as small updates? The earlier the better! Maybe doing this way you can even release something by the end of 2010, don't you?

Of course everyone want B option. Can't you see how much good audience Java is losing to other languages? Seems there's no more passion, even green pastures here! :(

Posted by Julio Viegas on September 08, 2010 at 05:29 AM PDT #

Since Project Coin was all about new features for JDK 7 (and it adjusted its scope based on the JDK 7 release date), I think it's appropriate to make Project Coin into a more or less ongoing project as you work towards JDK 8 (and beyond).

Also, for JDK 8, you should start a Scala Virtual Machine project to study the kinds of tuning that can be performed on the JVM to optimize Scala programs best. Looking at the direction of Project Lambda, I think Scala is going to be a much better-designed language for a very long time to come, and you should look at how to encourage its use.

Posted by Ken Bloom on September 08, 2010 at 05:38 AM PDT #

Plan B seems to be the lesser of two evils.

Posted by Alexey Romanov on September 08, 2010 at 05:38 AM PDT #

Plan B. I agree with Andreas, in this case "faster is better". So, anyway Oracle needs to show the investiment in Java. 2012 is so far away!

Posted by Eder Magalhaes on September 08, 2010 at 05:39 AM PDT #

Big ups to Oracle for engaging the community for feedback on this.

My 2 cents, I've never seen a company or product line opt for a "let's wait and ship EVERYTHING!" approach and either do it successfully (Duke Nukem Forever is an abnormally poor example) or do it without a mammoth amount of bugs that end up making the release hugely painful for everybody, and then a whole bunch of rush decisions need to be made in order to salvage the release.

Big proponent of Plan B... always Plan B.

Posted by Riyad Kalla on September 08, 2010 at 05:43 AM PDT #

Hi,

For information about Project Coin & plans A & B, please take a look at the following blog post by Joe Darcy: http://blogs.sun.com/darcy/entry/project_coin_jdk_7_plan

Dalibor Topic
Java F/OSS Ambassador
Java Platform Group

Posted by Dalibor Topic on September 08, 2010 at 05:48 AM PDT #

Ship. But all means, ship.

Posted by Philippe Marschall on September 08, 2010 at 05:49 AM PDT #

How many years do you think will java can be alive if there is a much much better language alternative "scala" !

Oracle should freeze java in 6 and shift all java lang. efforts to scala in my honest opinion to make java platform state of art again.

Posted by Serdar Irmak on September 08, 2010 at 05:52 AM PDT #

Do you seriously think you have realistic timescales if you're talking about a fully featured (Lambda, Jigsaw) JDK taking nearly the same amount of time either way, regardless of whether you do an interim release or not? I'd guess that if you do plan B, JDK 8 won't actually surface until mid 2013. Despite the obvious investment people have right now, good luck with still being relevant if that's the case.

Posted by Alastair Maw on September 08, 2010 at 05:57 AM PDT #

For me, "JDK 7 minus Lambda, Jigsaw" is JDK 6 plus several little features. And this news is really sad.

I vote for plan A.

P.S. why it is needed so long time to implement two features? It look like just 2-3 programmers only are busy in JDK development...

Posted by Leonid Bushuev on September 08, 2010 at 05:57 AM PDT #

Either plan is good. JDK 6 is very good for all current/future devs.
Of course, I'd like to see a JDK 7.. but for no objective reasons.
If JDK 7 there is in 2012, I would like to see massive Swing improvement and new components added to it.

Posted by guest on September 08, 2010 at 05:57 AM PDT #

YES. Plan B ... 2012 is far too long.

Seriously.... this is a HUGE gap of time from JDK 6 until JDK 7.

Plus everyone knows the world will end in 2012 so what's the point.

From the mind of M Night Shyamalan.

Posted by Kevin Burton on September 08, 2010 at 06:14 AM PDT #

I wonder what the price will be (per CPU)?

Posted by Customer on September 08, 2010 at 06:15 AM PDT #

Plan A is absolutely unacceptable! I'm waiting from 2008, I cannot wait any longer! I understand that without Lambda, Jigsaw, and part of Coin, we have to call it Java 6 & 1/2, but IMHO it is better than wait other two years...
I agree with Ken Bloom: plan B is just the lesser of two evils.
Please we trust in Java, don't make us disappointed anymore.

Posted by Claudio De Sio Cesari on September 08, 2010 at 06:22 AM PDT #

How many enginneers are working on those JDK features? three? two? one?
Hey, as Andreas said, Java 6 was shipped almost 5 years ago!!! Wake up Oracle!

Posted by Yang Ful on September 08, 2010 at 06:34 AM PDT #

I take it that plan B involves changing the syntax of Java two releases in a row? I think the adoption curve for 5 was affected by the fact that it was the biggest syntax change since Java was first released, not a measure of its "bigness".

Is there a "plan C" where you remove all syntax changes but keep back-end niceties like the new GC as well as library additions like nio.2, and release in 6 months? Then put ALL of coin and lambda into JDK8 in early '12?

Personally, Jigsaw and Lambda were the whole point of JDK7 for me, so plan B doesn't buy me anything except an additional 6 month delay. But I understand the desire to seem productive.

Posted by Sam on September 08, 2010 at 06:41 AM PDT #

I second the motion: release early, release often. Best way to get feedback about issues/errors and stay on top of things.

Posted by Greg Turnquist on September 08, 2010 at 06:41 AM PDT #

Another vote for plan B -- there is enough in there to make this variant of JDK7 something to look forward to, and I'd like to have them as soon as possible (even though project lambda in particular is something I really want as well -- but, perhaps with some additional delays, we'll even get tail call optimization in JDK 8 :-)

Posted by Jan de Vos on September 08, 2010 at 06:42 AM PDT #

One more reason to go for Groovy, Ruby, Python, Scala, .NET or whatever. It's fuckin' unbelievable that the guys at M$ camp published the .NET platform after Java 1.3 or 1.4 and the .NET platform is already miles away in terms of developer features (silverlight, CLR, language features, IDEs, etc).

Don't get me wrong, I'm sure that Sun/Oracle has alot of smart and hard working guys, but I cannot help but astonish at the slow pace of the Java-as-a-language evolution. As for the JVM, i think it rocks!

Posted by guest on September 08, 2010 at 06:47 AM PDT #

What I miss most in JDK 6 is the strings in switch statements.

Then I would like to see faster startup of Java applications which I guess would be addressed with parallel class loading.

For the rest I can say: It is more important to have a stable and well thought and well tested jvm and jdk. Python and Scala suffered from incompatibilities across updates and the like. I don't want that happening to Java as well.

C++ did not evolve for plenty of years and guess what: A majority of developers is using C++.

Debian people are known for "releasing when it's ready" and guess what: Plenty of people rely on Debian and are satisfied with it's stability.

I want a stable programming language I can rely on. This is far more important than everything else!

I can perfectly understand that after such a big merger and after many of the old very involved people left, things need to be reorganized.

The most time I loose is investigating programming errors that I finally find to be bugs in the underlying software I am using. Take the time it needs to deliver the awesome stuff.

Posted by Martin Wildam on September 08, 2010 at 06:51 AM PDT #

Will plan B involve revisiting some of the decisions already made considering Project Lambda, such as the removal of function types?
I view (the now-dropped) function types as a significant step to "future-proof" Java, and in that light the current lambda proposal is just tasty, but ultimately unfulfilling syntactic sugar.

Posted by Antti on September 08, 2010 at 06:53 AM PDT #

I think Lambda and Jigsaw are the most valuable features in new JDK, and IMO there are no reasons to name JDK without these two features as 7. So, may be to pusblish new set as JDK 6.1 (or 6.5) and then publish JDK 7 when Lambda and Jigsaw are included (late 2012?).
Why not?

Posted by Leonid Bushuev on September 08, 2010 at 07:01 AM PDT #

Why not just concentrate on improving the JVM to better support languages like Scala, Clojure, JRuby, Groovy, etc? Seems like there's plenty of language innovation happening outside the Java language. But all these new languages could benefit from JVM improvements like dynamic invokation, method handles, efficiency, and so on...

Posted by Sam Davis on September 08, 2010 at 07:05 AM PDT #

It's a shame...
Where are the smart guys/engineers?
Maybe it is time to change the whole team...

Posted by Martin Ruld on September 08, 2010 at 07:21 AM PDT #

Both schedules are disappointing. Of course everyone knows this and no-one is surprised by that statement.

Plan B is clearly the only practical path, too many people are waiting on the benefits of new JVM features and even some of the API features (NIO.2 on my part) to wait for mid-2012.

A part of the consideration for inclusion of new API features has to be whether the new feature has been appropriately integrated into existing APIs - NIO.2 certainly has some work here and Date-Time would have a great deal to do.

I won't say 'thank you Oracle' because I think this decision should have been made a while back (rethinking the scale of 7 features and fast-tracking 8).

Instead, how about 'more information please - what's in and what's out'. I expect many people would like a comprehensive list of what would be in JDK7 for Plan B and a discussion on what the impact might be in pulling in any specific exclusions from that list.

Posted by Talden on September 08, 2010 at 07:21 AM PDT #

Plan C:
Decouple Java release cycle from the Virtual Machine. The JDK/JVM is bigger than just Java, and there are VM features not slated for JDK7 that will benefit JVM langs. (see tail call optimization).

Posted by Paul Michael Bauer on September 08, 2010 at 07:38 AM PDT #

Go easy on him -- Mr. Reinhold needs all the ammo he can get if he's going to be able to do something useful with Java while inside Oracle (which makes its decisions based on V.P. headcount, not quality or innovation).

I also agree with plan B -- uptake of Java 7 will be low enough that the bug counts won't distract from getting the hard stuff right.

Posted by JimDesu on September 08, 2010 at 07:42 AM PDT #

Plan B. Even if Java-the-language won't change much with the release of JDK 7, Java-the-platform will be improved in many, important ways. This is especially true for non-Java languages which will benefit of features like method handles and invokedynamic, so I don't really understand all those "down with Java, W Scala" reactions. Java and Scala live on the same platform! And so do Groovy and Clojure and - shameless plug - ABCL and...

Posted by Alessio Stalla on September 08, 2010 at 07:48 AM PDT #

Go for B.

Plan C seems good also: "Decouple Java release cycle from the Virtual Machine".

Posted by Paulo Silveira on September 08, 2010 at 08:24 AM PDT #

I am glad to hear that more resources are going into Java and from following coin, lambda, and MLVM groups I can see significant progress. I suspect that getting anything through the JCP will be difficult, therefore I suggest Plan B - primarily to test the JCP waters.

Posted by Howard Lovatt on September 08, 2010 at 08:48 AM PDT #

Plan C is a non-starter. Sneaking in a popular feature with broad pre-merger buy-in is one thing, but Oracle doesn't care about the JVM ecosystem that's not Java. Java is the platform that they use to sell the openness of their stack, and anything else there's incidental.

Otherwise, I'd be all for "C" myself....

Posted by JimDesu on September 08, 2010 at 09:10 AM PDT #

All this time to offer a JDK7 in mid-2011 consisting of just JDK6 plus a handful of additional features... What exactly have the developers been working on all this time?

You say "JDK7 will ship concurrently with a Java SE 7 JSR", but obviously nobody has seen a Java SE 7 JSR. I doubt one even exists in draft form! Is it any wonder we don't have a JDK7 yet? "Those who fail to plan plan to fail".

Posted by M on September 08, 2010 at 09:29 AM PDT #

I think that releasing early and more often is definitely the way to go. Why can't the dates be brought forward for plan B, or more intermediate releases (plan C?) introduced? This way some features can be delivered sooner.

Posted by Dibyendu Majumdar on September 08, 2010 at 09:48 AM PDT #

not good. Time to look at alternatives.

Posted by sboulay on September 08, 2010 at 09:58 AM PDT #

Plan B.
Given how slow some vendors are getting their app servers to support new JRE releases, and how slow some enterprises are getting their development moved over to a new release, I think more frequent (I can't believe I'm saying 1 release every 5 years is "frequent"!) releases work better.

As someone said earlier, a lot of people only go to every 2nd release. Getting more releases out there, will speed that process up and get the platform moving forward. The sooner Java 7 is approved and released, the sooner we can stop pretending that Java 5 compatibility is worthwhile.

Posted by Tim Vernum on September 08, 2010 at 10:00 AM PDT #

Any news about the state of the JWebPane?

Posted by Behrang Saeedzadeh on September 08, 2010 at 10:15 AM PDT #

Some things were dropped from JDK 7 for "lack of time", such as the Swing Application Framework? Would those be considered for Java SE 8 or 9?

Posted by Cay Horstmann on September 08, 2010 at 11:52 AM PDT #

Plan B!

Posted by Anthony Gallagher on September 08, 2010 at 12:00 PM PDT #

Plan B, better to release early. Easy way to get most of the critical testing done by early adopters.

Also miss a JSR for Java SE 7.

Posted by Pether Sörling on September 08, 2010 at 12:27 PM PDT #

Plan B for me. Good luck with the JCP.

Posted by Hayden Jones on September 08, 2010 at 12:59 PM PDT #

Jigsaw is supposed to ease this kind of dilemma. Makes for a painful choice.

Should Mark or anyone else believe either plan's 2012 dates? In plan B, we will get nio2, superpackages (still there, right?) and invokedynamic in 2011. Plan B sounds right.

Posted by David Walend on September 08, 2010 at 01:17 PM PDT #

Hi. Mark. I vote for plan B for the reasons already commented by other people.

On the other hand, I think it would be great if you informed us more often about the plans of JDK. I specially missed some information when the "feature freeze" phase of JDK 7 was not completed in the end of June or when Jigsaw project's activity stopped suddenly for some months (in the beginning of June). I hope these were exceptional situations due to the acquisition of Sun by Oracle and from now on the information to the Java community will improve.

Regards,

Xavi

Posted by Xavi Miró on September 08, 2010 at 01:56 PM PDT #

As someone who is using a JDK 7 pre-release to operate an IPv4+IPv6 XMPP chat server on a 2008R2 machine, finishing 7 would be nice, especially as more IPv6 systems come online. Its not well known that JDK doesn't work well with IPv6 on Windows Vista or 7; its fine for XP/2003, which is in depreciation.

Posted by Michael Adams on September 08, 2010 at 02:21 PM PDT #

plan B , please.

Posted by manward on September 08, 2010 at 02:23 PM PDT #

I'm a bit late to the party, but I'll toss out my 2¢.

Most of what I wanted out of JDK7 is already in there. Specifically, invokedynamic, method handles, nio.2, and the bits of coin that are completed. But I'm not the only consumer, and my statements should be taken from the perspective of a dynamic language implementer.

Method handles are perhaps the most important change coming in JDK7 for the work I do. They are sure to become a key part of \*all\* JVM languages that want to be able to represent functions or function pointers without the associated overhead of generating single-method classes (as basically \*all\* the current JVM languages are forced to do in one place or another). But the long delay in making them available has meant language implementations like JRuby have had to keep plodding through the mud, building ever-cuter code generation strategies to avoid blowing up permgen (or just to avoid eating too much memory). The sooner we can get them into a product release the better.

I wholly understand the problems of scheduling. As recently as this past spring, several folks I worked with at Sun still had no idea what they'd end up doing at Oracle. That obviously makes planning or meeting a schedule impossible. Whether Oracle ultimately ends up being a good thing or a bad thing for Java, the buyout has set us back at least a year, and probably two...and at a time when people had really started to come back around to the JVM.

So would I be willing to give up Jigsaw, Lambda, and Coin? Jigsaw and Coin, perhaps, though they'd certainly be missed. As for Lambda...if it can't be done "right" in a short term, with a real function type and integration with method handles and invokedynamic, it should be delayed until it can be done right. It pains me to say so, but we do have other languages on the JVM that can do closures now, including my own JRuby and Mirah (which, incidentally, provides closures and more without \*any\* runtime library or JVM support), and for us JVM "systems programmers", anonymous inner classes are still "pretty good" (check out the JRuby codebase...we use hundreds of them).

I've always thought of JDK7 as the "language support plus NIO.2 release", and it may be that getting invokedynamic and method handles \*really solid\* is the best way to ensure that JDK8 can build features like Lambda properly. Hopefully everyone hasn't moved to node.js by then.

Oh, and for folks crowing about Scala...please explain to me how Scala solves any of the missing features that "Plan B" would omit. Yes, it has closures, but they're generally not interoperable with other languages or regular Java code (unless you limit your design considerably), which makes them useless for all but Scala developers. There's nothing to address the goals of Jigsaw. And most of the bits of Coin that Scala provides are (I believe) already ready to go. Scala is not a substitute for Java as the lingua franca of the JVM, and it never will be.

As always, these are my opinions. But I've been hacking on this JVM thing for a while now.

Posted by Charles Oliver Nutter on September 08, 2010 at 02:24 PM PDT #

I agree with some of the other comments here...what the heck has Sun/Oracle been doing for the last 5 years? Why is it taking SO long to implement so few features?

Right now, C# has features that even the future Java 7 wont have (i.e. Linq, etc).

All I can say is Oracle better get \*something\* stable out fast or the whole Java ecosystem is going to lose credibility when competing against C#, .Net 4.0, etc. which is miles ahead of Java at this point.

Posted by Michael McCutcheon on September 08, 2010 at 03:21 PM PDT #

Also please only add closures, lambda, etc. to the language when you are confident that they are stable and complete enough. I don't like to see any other half-baked features added to Java like Generics. If you add a flawed feature to Java, then you'll probably refuse to fix it in the future in an elegant way to maintain backward compatibility.

TL;DR: Only add fully baked, complete, and elegant features to Java.

Posted by Behrang Saeedzadeh on September 08, 2010 at 03:37 PM PDT #

Plan b is preferable. Even mid 2011 is too far in the future though...

Posted by George Moschovitis on September 08, 2010 at 04:07 PM PDT #

Please go for Plan B. There is no point in delaying the features that are already there until mid of 2012.

For our company Invoke Dynamic alone would be reason enough to upgrade.

Posted by Joerg Mueller on September 08, 2010 at 04:13 PM PDT #

I don't care for any Java language features. Focus on the JVM and the libraries to improve support for better JVM languages. The only thing I think that might be important is lambdas so that the standard library would evolve into something really usable by all the languages that support first class functions for a long time.

Posted by Matt on September 08, 2010 at 04:39 PM PDT #

It's simple: Release Early, Release Often. Plan B.

Posted by Tbee on September 08, 2010 at 05:01 PM PDT #

I'm just curious how we can be sure that with all the current delays a target of 2012 \*will\* be kept?

Posted by Maarc Schipperheyn on September 08, 2010 at 05:09 PM PDT #

Please Plan B.
Oracle needs to show to the world Java is still alive!

Posted by Emmanuel Puybaret on September 08, 2010 at 05:24 PM PDT #

+1 for plan B.
JDK7 has already has important changes. (NIO.2, string switch, G1, ...).
But I prefer mid 2012 for JDK 8 rather than late 2012.
Make JDK7 with less features sooner with more testing and stability improvements. You made already very good progress in testing and fixing memory leaks, very old bugs....

Posted by Martin JANDA on September 08, 2010 at 05:37 PM PDT #

Well, I guess the real reason for not shipping the more important improvements (except NIO2) is that Oracle might plan making Java 8 proprietary and therefore needs features which are also interesting for developers and not only managers to be able to sell it.

Posted by steve on September 08, 2010 at 05:40 PM PDT #

Plan B is better by far:

\* Clearly more achievable than plan A.

\* Like Guillaume said: release early, release often.

\* Gives more time to rationalise Jigsaw, Qwylt, and OSGi.

\* Restores confidence in the JCP earlier (when a Java 7 JSR is approved).

Posted by Glyn Normington on September 08, 2010 at 05:52 PM PDT #

If Oracle is unable to manage such a big bang, then you should not try to. A German saying is: "If you can't bake bread, do rolls instead!". Don't tell people they have to wait for more YEARs. This really SOUNDS like vaporware and strengthens concurrent platforms, especially that Java clone made in Redmond, because most managers don't check the technical facts but just look for the bad press. Just keep your mouth shut about release dates if you can't make them happen, to prevent others from saying: "See, they just can talk but they cannot deliver!". Certainly it is normal in this business to move release dates. But it is always nice for a competitor to see others moving their date for YEARS.

Publish feature by feature, name it 6.1, 6.2 etc., but don't tell people to wait for more years.

Also I need to say that it really LOOKS like either your developers are drinking coffee the whole day ;-) or the team is not bigger than five people (how many graduated IT engineers are actually in the JDK 7 team fulltime?). Sorry to say that, but I am a team leader on my own and comparing our productivity with the story of JDK 7 makes me just LOL. Shall we take over for you? ;-D

Posted by Markus Karg on September 08, 2010 at 06:22 PM PDT #

It has been stated so many times "release early and often". I assume this is from agile movement.
What to learn from agile is to go in small steps and not to throw out buggy stuff! You can throw out buggy end-user stuff that is not critical to show the user something to test. But for a core technology, many rely on, you can't apply all the agile ideas!

Regarding the invokedynamic: There is already a way of calling methods dynamically in Java 6. Look here: http://it-tactics.blogspot.com/2010/09/dynamic-method-invocation-in-java-6.html

Posted by Martin Wildam on September 08, 2010 at 06:42 PM PDT #

+1 for Plan B.

Kudos to Guillaume Lafforge and Charles Nutter for their comments.

Posted by Stefane Fermigier on September 08, 2010 at 06:47 PM PDT #

Yes, Plan B please!

Posted by Ruslan K on September 08, 2010 at 07:00 PM PDT #

+1 voor plan B.
But don't introduce any API for 166y that will be deprecated/obsolete once lamba's are available.

Posted by Geoffrey De Smet on September 08, 2010 at 07:05 PM PDT #

Hello Mark, I personally would prefer Plan B instead of A. As often quoted, "Release early, release often".

JDK 7 of Plan B could also define the first cut of language implementation compatibility between Java and other the alternative JVM languages.

Looking to meeting you at JavaOne 2010 soon.

Posted by Peter Pilgrim on September 08, 2010 at 07:08 PM PDT #

I fully support with plan B

There's enough stuff of value in that release to make it work releasing.

Posted by Yannick Menager on September 08, 2010 at 07:23 PM PDT #

Would jsr166y be able to evolve correctly if it landed in the JDK before Lambdas are ready?

Posted by Robert Gibson on September 08, 2010 at 07:29 PM PDT #

Plan B sounds good.

Posted by Chankey on September 08, 2010 at 07:30 PM PDT #

I would go for plan B (most of the peoples has gone for it :) ).It will be fun to work on 7th version.

Posted by Yogendra Sharma on September 08, 2010 at 07:36 PM PDT #

So JDK7 will be like a Vista-release and then a some time later we finally get JDK8 as Windows7-like-release ?

All i know is, if it does not contain Lambdas, I will not upgrade to JDK7.

Why is there out of nowhere now a need to rush out a new JDK release? This is such a big and only periodically happening change within organizations that it will be delayed unless there is real value in upgrading right now.

Just look how many people did not upgrad to JDK6 and stayed with Java5, because JDK6 did not have anything new besides performance improvements and a pretty useless scripting api.

Posted by Sakuraba on September 08, 2010 at 07:39 PM PDT #

I feel there are plenty of good features in JDK 7 to do an early release, especially the NIO code and most of project Coin will be nice to have, while features like Jigsaw and Lambda's will need some more cooking.

It's disappointing that things will take so long, but I'd rather see the ball rolling again with a fresh JDK 7 lite, then to wait until 2012 to see all the features. It would also mean less energy to be spent on backporting features to JDK 6 and some renewed focus on moving the platform.

Now more importantly, is Oracle going to involve the proper channels? (JCP?)

Posted by Barry van Someren on September 08, 2010 at 08:00 PM PDT #

Plan A would mean a bloated, rushed release so that Java can catch up, after six long years of development. Therefore, as Brian Goetz pointed out, the uptake would be even slower. This would clearly be the wrong approach.

On the flipside, Plan B, delivers necessary features soon, which can be put into practice right away (Fork/Join and NIO.2 been the most significants, but also the likes of Swing application framework).

In this scenario, Java 7 would bring necessary features to the JVM ecosystem. Java as a platform would be greatly enhanced (method handles, InvokeDynamic).
After all, Project Coin and Lambda promise features that i can get better elsewhere today (Scala, groovy, clojure, jruby), whereas Jigsaw is already achieved through OSGI.

What the future holds for Java 8, is too uncertain (Lambda), but i can certainly foresee more expectation building as soon as Java 7 is out. Scala can even help in this regard. In answer to Charles Nutter question, Scala doesn't need to catch up with Java, is the other way round. If you design relies heavily on Scala features, then you are better off using Scala.

For those reasons, I vote for Plan B, release early, release often.

Posted by Fernando Racca on September 08, 2010 at 08:25 PM PDT #

I think plan B is the only practical approach. We really can't afford to wait EVEN longer (until 2012, 2013, etc?) for a new Java release. And as Charles said, you don't want to rush closures.

Posted by Kjetil Ødegaard on September 08, 2010 at 08:30 PM PDT #

@Sakuraba:
Oh there is more in JDK6 - e.g. System Tray support for Swing applications.
But: The big performance improvement was already enough for me to change.

Posted by Martin Wildam on September 08, 2010 at 08:55 PM PDT #

Plan B seems better:
- Still a correct list of new features (and bug fixes?)
- No more 2 branches: Java 6 update 10 en JDK 7
- 2012 probably means 2013 for Mac Users

Posted by Anthony Goubard on September 08, 2010 at 09:46 PM PDT #

Plan B:

Scala already gives me tha Lambda stuff, and I'm tired of waiting for NIO.2.

Even without closures, we'll still get invokedynamic, method handles and fork/join, so lots of Juicy goodness for all the non-Java languages on the VM.

I really couldn't care less about closures in Java.

Posted by Kevin Wright on September 08, 2010 at 10:03 PM PDT #

plan B!

Posted by Faisal on September 08, 2010 at 10:26 PM PDT #

But can we rely on Oracle to finally deliver ?

To the contrary of Sun, Oracle is \*very\* customer-centric. I really wonder whether so much customers care about jdk7. Or about any Java version at all. I know enough customers still running 1.4 or 5.

Personally, I very much doubt Oracle will push things faster, only to please a "bunch of wining computer nerds". As long as the customers are pleased.

Posted by Jan Goyvaerts on September 08, 2010 at 11:00 PM PDT #

I think plan B is the best option.
And for the next releases, a "Release early, release often" approach would be the best bet.

Posted by Urubatan on September 08, 2010 at 11:17 PM PDT #

I agree, release little, release often.

I doubt overall the feature set will actually be released quicker if you go with option A - you say it will, but I don't believe you ;)

I would go with option B, that will at least allow the people working on dynamic JVM languages to improve their platform at the same time as you add Lambda support in Java 8.

Posted by Matthew Cooke on September 08, 2010 at 11:25 PM PDT #

+1 for Plan B. Please

Posted by Avdhesh Yadav on September 08, 2010 at 11:31 PM PDT #

Now when there is more time to work on lambda can we expect "real" lambdas with function types? Because what is currently being developed is not a "real" lambdas.

Posted by Serhiy on September 09, 2010 at 12:22 AM PDT #

One the problems with thinking "only enterprise" is that you are saying that the features and needs of the 10s of thousands of commercial users far out weigh the needs of new features and capabilities that the 10s of millions of desktop users can benefit from.

Plan B would be best I think. We've already waited nearly a decade for a filesystem API that actually works in massive filesystems (no more File.list()), just because of the focus on "enterprise".

For Java to be everywhere, it has to be ready for everywhere. With the focus on enterprise, the time invested in the rest of the platforms has been very much a problem.

What we see on mobile devices today should of appeared for Java powered devices 5 years ago. The focus was clearly not there, and now Java is NOT the preferred platform on mobile devices, and thus a huge market place is crashing down on all the developers and users...

Posted by Gregg Wonderly on September 09, 2010 at 01:22 AM PDT #

This is very disappointing slip. We have been looking forward to JDK 7, especially Jigsaw to boost performance of Java startup issue for our RIA apps. 2012 is just too far away, I'm afraid that half Java developers will be gone by then.

Posted by Jack on September 09, 2010 at 01:47 AM PDT #

Sad news. I vote for lambdas as soon as possible, but if there's no choice go for plan B.

Posted by Karl Peterbauer on September 09, 2010 at 02:57 AM PDT #

+1 for Plan B. Please

Posted by Kyle Dyer on September 09, 2010 at 04:13 AM PDT #

Greetings,
+1 for \*plan C\*; decouple the JVM and the Java Language from each other.

The JVM is a valuable platform that should be iterated on at a different pace than the more slow-to-evolve Java language itself.

Decouple; it's for the best!

Posted by Morgan Schweers on September 09, 2010 at 04:50 AM PDT #

My personal (not company) preference would be for plan B ...

Posted by Larry Cable on September 09, 2010 at 05:16 AM PDT #

Very sad news indeed.

I would trade it all for lambdas... (especially Jigsaw)

Posted by Steve Ash on September 09, 2010 at 06:27 AM PDT #

Hopefully once more resources have solidified, Java will progress more quickly. Already it has fallen woefully behind in terms of capabilities with respect to C# and other languages. I say that as a Java dev.

I would think it is in Oracle's best interest to accelerate the capabilities of Java, not for some geeky pleasure but as a means to an end - getting the language used for future applications, meeting the needs of developers/architects who would otherwise build the next generation of applications with something else.

Plan B seems reasonable, but hopefully development pace will pick up.

Posted by Jeremy Hanna on September 09, 2010 at 06:51 AM PDT #

Hi Mark,

Please take as much time as necessary to deliver a well thought-out, polished solution. In my opinion, the worst thing that Sun ever did was deliver a half-baked solution for Generics in Java5. I don't want to see any more half-baked solutions. Take more time if necessary, but do it right.

I would love for Oracle to introduce a new community process whereby new features would be marked as "experimental" in JDK7 (such as Project Jigsaw) with explicit warnings that backwards compatibility \*will\* be broken. Then continue evolving the design until it \*naturally\* evolves to a steady state (very little modifications over a long period of time). We'd then mark the API as stable. I don't believe that it's technically possible to deliver a perfect design the first time. You'd be surprised how many developers will use experimental APIs in production code and let you learn on their dime. So long as you're up-front about expectations (i.e. this API is unstable) the more conservative customers will simply avoid them (which is fine because most of them are still using JDK5).

To answer your question: I'm learning towards option B (deliver less, sooner) so long as you only deliver full-baked solutions. If you cannot break backwards compatibility then please limit your release to new APIs you are 100% certain of. When in doubt, leave it out.

Thank you for the opportunity to express my opinion.

Posted by Gili on September 09, 2010 at 07:22 AM PDT #

Option B is better if Option A is risky. I can't imagine what will be happen if Java 7 is not stable enough.

Stability is the highest priority in the enterprise area, where having lesser features would have no harm. We can definitely continue using Java6 perform the development, can't it?

If someone who want to use some new features, it is better to let them download a feature pack, and run on top of Java6.

Posted by Alfred KU on September 09, 2010 at 01:59 PM PDT #

Check out: Behind the scenes of Re-thinking JDK 7
http://monisiqbal.blogspot.com/2010/09/behind-scenes-of-re-thinking-jdk-7.html

Posted by Monis iqbal on September 09, 2010 at 03:51 PM PDT #

Well... Java as a platform will probably survive but no thanks to the fantastic primary language but largely due to the fact that there are other, better, more evolved languages that today do what's expected from them. Java as a language is dying fast!

Posted by Matthias Hryniszak on September 09, 2010 at 05:59 PM PDT #

Plan B, indeed. Plan A may slip even more ...
And don't release Java 8 until 2013 (if Java does not get those features right, it will break). And add all those goodies that were rejected due to having no time in Java 7 (like SAF!). And think about how to properly overhaul the standard APIs in Java 8 (they are long in the tooth!).

Posted by javierbds on September 09, 2010 at 06:22 PM PDT #

B without doubt. Java is, and always will be, biggest on the server side so the delay of Jigsaw is not a big deal for a lot of people.

Posted by YoGee on September 09, 2010 at 07:08 PM PDT #

Vote for Plan B.
Minus Lambda, JDK7 will be a small release which will encourage enterprise to adopt it faster and set the momentum to the community again.

Posted by Asif on September 09, 2010 at 08:09 PM PDT #

My opinion: plan A.

Why?

Because it will lessen fragmentation. If Oracle goes with the plan B, we'll have at least one more version of Java to support. It's like 1.5 vs. 1.6 - they are very similar, except when they are not (like D&D in Swing, changes in JDBC, etc.)

And frankly, 1.7 in plan B isn't that exciting.

Posted by Alex Besogonov on September 09, 2010 at 10:22 PM PDT #

Kyle, Oracle's JVM and class libraries already are decoupled. New HotSpot versions are continually been integrated into OpenJDK6, which began on HotSpot 11 and is now on HotSpot 17. Not to mention that you can use JVMs from other vendors.

Posted by Andrew John Hughes on September 09, 2010 at 10:29 PM PDT #

The reasonable thing to make here is to go for plan B. We have been waiting so long for JDK 7. On top of that a "big fat" release with a lot of changes would slow down the adoption.

Posted by Naimdjon on September 09, 2010 at 10:42 PM PDT #

believe me, features like lambda, Jigsaw, LINQ (if possible) would move more developers to Java Platform

Posted by Okuboyejo Damilola on September 09, 2010 at 11:08 PM PDT #

IMHO, Plan B looks like the best idea for everyone :
- early adopters would be happy playing 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.

Posted by Dominique De Vito on September 09, 2010 at 11:20 PM PDT #

First of all, it’s really awesome that we can provide our feedback here and be heard. Love it. Thank you Oracle for that!

Now my vote is definitely for the Plan B.

Here is what I would like to add to the arguments in favor of the Plan B:
- less stress for the JDK developers. They’re probably too stressed already. Just think how would you feel in such situation.
- less rush for JDK8 => less mistakes => more stable and robust solution
- batching features into X-year releases to me sounds like writing X-thousand lines methods

and to stress some of the points mentioned earlier:
- gives people opportunity to play with the new technology like fork-join, NIO.2 and entertain themselves with that stuff while the new beast is coming
- need to give the JCP process one more try to make sure it’s up-to-speed for JDK 8
- good point about easier adoption because of less radical changes. Also, if devs will pick the new technology up, this will help enterprises to eventually follow that direction as well
- like several folks pointed out earlier, less time wasted on backporting
- Plan A is just deferring the problem and making it even bigger and less manageable
- no half-baked solutions please (since Java has a strong record of respecting backward compatibility which makes things hard to fix)

What are we still discussing?! Let’s stop crying about the sad news, Scala, bla-bla and finally release JDK 7 to the market! And a good starting point would be, as Martin Ruld pointed out, to settle down on a list of features for JDK7 and estimate an impact of removing each one in case it's not fully finished.

Posted by Andrii Neverov on September 09, 2010 at 11:50 PM PDT #

The problem with releasing JDK 7 as is is that things might be changed, refined or even dropped as Mark points out. This includes the minor language changes from project coin. This means that you can't actually use them in production because an upgrade to JDK 8 might break them. You ask why? Well there's an implementation with no specification. If a JSR is created the language changes may be ratified or dropped altogether! Oracle would officially have a non compliant version of Java unless they made the changes that came out of the JSR which may or may not break your programs. The risk here as Oracle is not pointing out is that even if coin, jigsaw and project lambda were finished it would be absolute hell for them if a JSR was created and didn’t see platform changes as they did.

Posted by sboulay on September 10, 2010 at 01:41 AM PDT #

Not sure why plan B is supposed to be better. All the places I know want as stable a platform as possible. Once they chose a particular release, they stick with that for years, until there are compelling changes that force a switch.

Seeing that JDK6 works OK for the time being, leaving that stable and then releasing a JDK7 in 2012 with significant upgrades, which then is stable for a few years is IMO the better solution.

Just think if libc and the C language were redefined every few years.
The early years of Java were different, when there were significant and obvious deficiencies in the language to be fixed.

I think the language has matured enough that these constant new releases just create an ever more confusing alphabet soup of specs that hinder, rather than further adoption.

So my vote is for fewer, more significant and more well thought out releases, at an ever slowing release cycle. Hence a clear vote for plan A.

Posted by rcfa on September 10, 2010 at 05:00 AM PDT #

I think plan B is a better option. Too much time waiting for some new features, and the bigger release the bigger risks for new delays on those features.

I think Java should evolve slow, with care, with no transient features no longer needed after a short time, but evolve after all.

Posted by Francisco Gómez Carrasco on September 10, 2010 at 06:18 AM PDT #

PLan B. There's a million JVM languages waiting for ivokeDynamic and other JVM goodness that are already done and tested.

Posted by Miranda on September 10, 2010 at 03:10 PM PDT #

Plan D: Ship all the syntax stuff on top of the Java 6 VM in the compiler right now, decouple the VM and language schedules and catch up sometime in 2012.

Posted by Sam Pullara on September 10, 2010 at 04:09 PM PDT #

What about the Garbage First collector?

The language features are somewhat interesting and maybe fun to use but unlike the Scala fans I don't consider language additions really that important. (I already lived through C++ I don't need another one)

However, the platform improvements are important. The one I'm most looking forward to is a stable G1 GC.

DEFINITELY release Plan B. We've waited enough, its time for an update.

Posted by am on September 10, 2010 at 09:02 PM PDT #

As most other people around I agree with plan B.

Lambda should better be gotten right rather than being rushed and for me as casual observer there still seems to be couple of fundamental disagreements (with non-local returns and SAMs still being the most prominent ones).

It is a shame though that a first, minimal, JDK-specific implementation of jigsaw won't make it. I hope that it could be integrated into mainline quickly after Java 8 has branched off so that additional development can benefit from it.

By the way: some people seem to wonder what the developers have been doing after Java 6. I think you should remember that there has been JavaFX during that time, together with lots of effort being poured into tooling and Netbeans development. And then there were lots of Java client improvements with 6.10, which could easily have been called 6.5. And then there was a significant amount of backports on the VM side over several releases after that which I was really surprised about (like compressed OOPs and new garbage collectors). And then there was, of course, the whole Oracle takeover.

It might have been a lot better to put all the development effort that went into JavaFX and backports and Netbeans and Glassfish into the Java core platform and especially into Java 7 but I really don't think that the developers were either bored or incapable.

Regarding the JCP: I think oracle's move against google has made quite a point as to why the Apache protest within the JCP is quite reasonable. Let's see how oracle proceeds with the JCP. Sadly I don't have high hopes for a reasonable solution, which certainly isn't Mark's fault.

Posted by Christian Steinert on September 10, 2010 at 09:23 PM PDT #

Well, I put this one to my dev team, and they've unanimously voted for Plan B.

We already have firm plans for using NIO.2 and the new concurrency bits, and we'd adopt JDK7 on that basis alone. As far as Lambda is concerned, well, even the guys who like the idea admit that it's going to have to be a "suck it and see" job before they can make promises which are relevant to our actual product development work.

On that basis, we'd be adopting JDK7 shortly after it gets released, then experimenting with JDK8 for a long time before either adopting it or jumping straight to any JDK9 that might have been released while we were experimenting.

Posted by John Smith on September 11, 2010 at 04:25 AM PDT #

Do Plan A please. Without lambda/jigsaw, a new Java platform isn't very interesting, the value proposition is quite low. Another release now just creates one more platform that needs to be supported, targeted, maintained in the future causing me more headache as a developer and support person..

Posted by nos on September 11, 2010 at 06:41 AM PDT #

Plan B: stable G1 GC

Posted by Flávio Henrique on September 11, 2010 at 10:39 AM PDT #

There are no straight forward answers to these plans a and b, they must open a poll and vote for it and move forward from there.

Posted by Muhammedh on September 11, 2010 at 12:13 PM PDT #

Having been following the Project Lambda discussions for a while, I think that Plan B will lead to a much better Project Lambda (though maybe not a better Fork/Join framework) which will let the Java language compete more effectively with Scala. But we need people whose vision goes beyond the Java language and the Fork/Join framework to get involved. JRuby, Groovy, and Scala developers: how can Project Lambda invent a Lambda feature that is compatible with all of your languages, and is a sensible base for all of your languages to share lambdas seamlessly? How can Project Lambda provide default implementations of interface methods that are compatible with all of your languages and make your languages' features easier to implement?

Posted by Ken Bloom on September 11, 2010 at 01:22 PM PDT #

I would go even further with plan B and release JDK 7 as soon a possible with anything that is stable and works as of now.

Then introduce JDK 8 next year for a top-up of remaining JDK 7
features that need refining and further testing and then JDK 9 the following year. The Netbeans project looks to be a good model of little and often for release planning. The all or nothing approach is detrimental for development as all new features arrive at once and need learning before use.

As most JRE's installed can update automatically it should not be
to much of an issue to migrate to later versions.

Posted by Alex Belch on September 11, 2010 at 06:25 PM PDT #

The Peoples now can't wait, just like mobile OS market that competitive. If you delayed, people will switch rather than wait.

Posted by Lawrence on September 11, 2010 at 11:33 PM PDT #

Java has not been evolved as much as it should have. What has Oracle done after taking over Sun to help grow Java ? I'm thinking about going back to C++. We have to wait for 2 years to see the light for Jigsaw. I have a feeling that Oracle only cares about Java running on servers not anywhere else. As a Java desktop developer, I just don't see any future for Java on desktop.

Posted by Jack Trusell on September 12, 2010 at 12:25 PM PDT #

@Lawrence: I agree that Java on the desktop needs some love, but return to C++? What has C++ done for you on the desktop lately?

Posted by Cay Horstmann on September 12, 2010 at 01:37 PM PDT #

@Lawrence If you are developing for the Desktop, please leave Java. I have no interest in any of the desktop changes they have made in the last decade. Air and Silverlight can also leave the building. Develop on the OS if you want to work on the desktop.

Posted by Sam Pullara on September 12, 2010 at 02:20 PM PDT #

It looks not good from PR view to miss a major release one year or more. Competitors don't sleep, is it?. I think restricted Release 7 could bear an attribute like "preliminary" and from any senses it will work better than silence. The team is expected to get backstream of new bugs and other issues and so get better prepared to what is called Release 8.
I'm working with v.6. Thanks for good release and good luck with new one!

Posted by Nikolai on September 12, 2010 at 02:27 PM PDT #

Plan B please!!

Posted by Shervin Asgari on September 12, 2010 at 05:53 PM PDT #

JSR-310, Date and Time, 2012 - 1996 = 16 !

Wait 16 years :) almost 1/5 of a century!

Posted by Patient Person on September 12, 2010 at 06:14 PM PDT #

In short: best case scenario, Java, in two years, will be where it was supposed to be last summer.

Posted by Alex on September 13, 2010 at 02:58 AM PDT #

I'm a big fan of JigSaw, so it's sad it won't make it early. Otherwise some new features are better than none, so I prefer Plan B, even if it might delay JigSaw further since maintenance work has to be done for JDK7

Posted by Mene on September 13, 2010 at 07:15 AM PDT #

It would be good to get a clear list of changes in the JDK7 delivery of Plan B and a list of what is expected to wait until JDK8.

Totally aside from the difficulty of making an informed decision on Plan A or Plan B without those details, it may be unwise to assume that all currently committed code in the JDK7 candidate are candidates for the JDK7 target of Plan B.

Are all committed items properly integrated into the full ecology of the JavaSE APIs? Can the work to integrate them be done in the JDK7 time-frame or should some of those features be withdrawn? What is the time-risk (quality is not a tradable commodity here) of trying to complete them and are there any suitably low time-risk elements not yet committed that could be included in the JDK7 target instead of waiting for JDK8?

Posted by Talden on September 13, 2010 at 07:37 AM PDT #

I hate to use the C words (Cobol, C), but I wonder how many of the people posting here are "geeks" and how many are corporate decision makers.

From any contract work I ever did, the consistent message is that people want stable platforms, not constantly morphing development targets that either mean sticking to an ever more outdated base system for which it's ever more difficult to get support, or to constantly have to rework all systems at great expense to remain current.

People pay the most for the least changes.

A new baby platform, in a race to market, like Java once used to be, has to rapidly evolve to overcome the flaws caused by the time to market rush. Java had now a long time to mature, people do all sorts of useful work with it, and as such it's mature enough to remain stable for extended periods of time, giving corporations stable development targets.

At this point in the game, a new development target platform is only worth it if there are fundamental shifts, not a little touch-up here and there.

From what I understand, the items that make it worthwhile enough to define a new platform standard are the ones that won't make it until JDK8 under plan B.

As such, JDK7 under plan B only "serves" to fragment the market place, cause corporate developers headaches with platform choices, etc.

Java is a programming language & development platform, not a fashion statement. It's not like it needs a feature bump every few months to remain "hot" and "fashionable". It's a tool. Hammers haven't had real feature updates in decades (if you count plastic handles), and people still use them.

If Java dies because it doesn't create a new buzzword platform every year or few months, then it deserves to die, because that means it's just a fad that needs the release hype to keep it alive. If Java has true utility, it can easily go for a few years without significant upgrades, and then come with well thought-out and well tested, worth the wait changes that justify targeting a new platform and reworking old code.

Posted by rcfa on September 13, 2010 at 08:29 AM PDT #

2 years calendar time converted to Internet time = how many decades?

This is starting to remind me of the later days of C++ where changes were made at a glacial pace.

Now if I could only convince the 100 or so developers I work with to adopt Scala...

Posted by Bob Shock on September 13, 2010 at 09:07 AM PDT #

I agree with Urubatan about release early, release often.

---
"Esse urubabaca eh desenvolvedor o masi buro do Brasil."

Posted by Amil Fir on September 13, 2010 at 03:27 PM PDT #

My vote is for plan B!

I have given a number of presentations with the title "Whats new in JDK 7?" over the last 18 month or more. Ship 7 as soon as possible with what we have "ready". G1 is valid improvement.

I would have wanted to include Jigsaw, but...
Release of 7 and planning/defining 8 is more important for the momentum IMO.

I even have the perfect release date with a promised party at Jfokus conference in Feb 15 in Stockholm, Sweden

Posted by Mattias Karlsson on September 13, 2010 at 07:01 PM PDT #

please do plan B as soon as posible.
java needs bIG CHANGE for help programmer.

Posted by Amin Bahiraei on September 13, 2010 at 08:46 PM PDT #

Plan B is the way to go!

Posted by me on September 13, 2010 at 08:52 PM PDT #

Plan B sounds good to me!

Posted by Eder Guajardo on September 14, 2010 at 03:11 AM PDT #

What about another alternative? Would it be possible to release some of the improvements slated for Java 7 Plan B as dev.java.net projects, and then continue working on the "full" release? The full release could incorporate the dev.java.net projects in the same manner that Java 6 does with JAXB and JAX-WS. Of course, things that require language changes couldn't be released this way, but maybe something like nio.2 could be. This plan would also allow G1GC to continue to be developed on Java 6, and ported to Java 7.

Posted by gj on September 14, 2010 at 04:58 AM PDT #

Looks like all Oracle has been doing for Java is changed JVM vendor name :-)

My vote is for Plan B! Please give us something new as soon as possible!

Posted by ym on September 14, 2010 at 09:28 AM PDT #

If there is no other choice...Release early..er

\*\*start rant\*\*
Was it last javaone that java 7 slipped a year? Now, after 18 months there has been no progress? Even with 9 months of merger....holy cow. Were the estimates that far off? How on earth, were the estimates that far off and no one mentioned it until a year in.

Another 18 months will certainly move java from from a growth area to a maintenance area in many enterprise architectures. This will give Microsoft huge opportunities that will be difficult to fend off.

Oracle, really needs a PUBLIC plan for how they are going to move this forward. They need to start engaging the community far more aggressively than they are now. The change in blogging policy has been devastating already (java articles have been slow since the merger). The lack of news on this alone (not even whispers) has made this unnecessarily dramatic. Oracle needs to learn that proprietary products can be surprising and secretive, but public products need transparency to survive.

Most corporate adoption will wait for the .1 release. If they wait for 8, as other posters have suggests, and then for it's .1 release we will be 6+ years between releases?? So, engineers that will be asked to choose the new java platform will be 5+ years removed from the last java upgrade. That's a generation in engineering. It's is not a remote possibility, at that point, that the next generation of engineers will choose something other than java. It will have been stagnant for their entire career. Without the overactive blogosphere that sun created, and with Oracle's tendency to play things close to the vest, java could die on the vine before 7 or 8 gets here.

This is really, really disappointing.

Posted by Les Stroud on September 14, 2010 at 02:28 PM PDT #

I hate to use the C words (Cobol, C), but I wonder how many of the people posting here are "geeks" and how many are corporate decision makers.

From any contract work I ever did, the consistent message is that people want stable platforms, not constantly morphing development targets that either mean sticking to an ever more outdated base system for which it's ever more difficult to get support, or to constantly have to rework all systems at great expense to remain current.

People pay the most for the least changes.

Posted by battery on September 14, 2010 at 04:19 PM PDT #

There are 4 crucial JVM changes at stake here,
3 of them regard JVM features:
a) The 'invokedynamic', absolutely neccessary for any other JVM-language (including Scala, think of type-structurals),
b) GC1, and
c) Modularity (JSR 294),

and a 1 involves API+Lang changes:
d) Lambda.

A critical concern is that all those features interoperate with existing solutions.

While the above constraint apply for (a) and (b),
none of (c) and (d) have worked-out those issues yet,
particularly the last-one, given the Jigsaw-OSGI schism.

Therefore, Lambda constructs must be made to interoperate seamlessly with the closures of other JVM languages,
and Jigsaw must eventually interoperate with OSGI.

Hence, i vote for Plan B,
and if possible, add the JSR 310 (Joda Date and Time), a production-quality essential library.

Posted by ankostis on September 14, 2010 at 08:14 PM PDT #

In my previous comment here i was tempted to include in my "wish-list" the Joda Date-Time lib,
but i changed my mind after reading Peter Kriens's last blog[1] about a small, modular version-configurable JRE,
and i now vote whole-heartedly for Plan B
\*without\* any bells or Whistles.

[1] http://www.osgi.org/blog/2010/09/jdk-7-delayed-again.html

Posted by ankostis on September 15, 2010 at 01:05 AM PDT #

Some questions about security updates to the JDKs and their corresponding JREs: Will the free updates life of JDK6 will be extended until after JDK7 ships? How long will JDK6 updates remain free after JDK7 ships?

If Plan B is adopted, how far will the free updates life of JDK7 extend past the release date of JDK8? If that's only a year, it forces application vendors to buy a support contract, or upgrade twice in two years. There's also the question of appserver support; will the appserver vendors do two sets of updates?

Posted by John Dallman on September 15, 2010 at 10:38 PM PDT #

I am absolutely floored by the silliness of much of the belly aching. Oracle does not have the best of reputations and probably deserves the one it has but faced with this, how not to have some sympathy for its executives and think that perhaps, yes, once _can_ dispense with such a community?

Posted by Olivier Lefevre on September 16, 2010 at 05:23 AM PDT #

While I appreciate much of the frustration being vented on this list, I dont think much of it is of any constructive value (sadly as usual).

Mark and the rest of the JDK team have worked diligently with the constraints and resources available to them with the sincere commitment of both adding value to the platform while maintaining the necessary compatibility and they have done so for the last 15 years.

Much of the delay in JDK 7 can be attributed to either the politics of the JCP itself, or to the decisions taken by executive staff to shift resources from the JVM and JDK to other projects, not too mention the dengerative effects of Sun's slow decline into acquisition have had on morale and staffing.

We are where we are, no amount of complaining or wishing away the reality is going change the current situation drastically.

We would all like to see Jigsaw (would I?), Coin and Lambdas et al released asap along with all the other features that are available to be released next year.

Its not going to happen, but there are enough of us who do want those features that are available to be released asap, not least the dynamic language support; hence the support for plan B, which appears to be the best option possible at this time.

For those of us that are frustrated for whatever reason there is a solution; get involved, either with the OpenJDK projects directly or with the JCP or constructive concerns directed to the executives at Oracle that are now charged with the stewardship of the Java platform in its various guises.

As for Jigsaw and Lambdas lets do it right ... I recently read a short but interesting book "JavaScript: The Good Parts" which is an interesting overview of the parts of that language that do not suck, as opposed to the many that do, because global adoption overtook the ability of the team to properly conceive of, test and refine many of its features...

This cannot occur to Java.

I look forward to JDK 7 next year, and JDK 8 with modularity and lamba when those are ready for release in JDK 8.

Good Luck Mark&Team

Posted by Larry Cable on September 16, 2010 at 05:55 AM PDT #

Like a corporate and enterprise thinker, I'll be with the minority - so plan A.

Some comments: there are plenty of other languages that are updating much often - C#, Scala, Ruby. That is fine to have new features rolled out every 6 months and consequently some old features have outdated and obsolete. Until you are working on heavy enterprise where porting your application is something much difficult, than update a couple of internet sites.

Java is old, that's true, and being that old there is nowhere to hurry already. Plan B offers everyone to update 2 times per next two years - that's twice more job in maintaining!

Plan A is my vote, in spite of that I am looking forward these new awesome features too.

Posted by Eugene P on September 16, 2010 at 08:09 PM PDT #

Post a Comment:
Comments are closed for this entry.
About

This blog has moved to http://mreinhold.org/blog. <script>var p = window.location.pathname.split('/'); var n = p[p.length - 1].replace(/_/g,'-'); if (n != "301") window.location = "http://mreinhold.org/blog/" + n;</script>

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
News

No bookmarks in folder

Blogroll

No bookmarks in folder

Feeds
RSS Atom