« Closures for Java:... | Main
Re-thinking JDK 7
2010/9/08 09:21 · Permalink · Comments [138]

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.

Trackback URL: http://blogs.sun.com/mr/entry/rethinking_jdk7

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 09: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 09:53 AM PDT #

release early, release often.

Posted by michael bien on September 08, 2010 at 09: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 09: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 09: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 10: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 10: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 10:06 AM PDT #

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

Posted by Daniel Serodio on September 08, 2010 at 10: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 10: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 10: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 10: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 10: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?


"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 10:39 AM PDT #

say it with me, out loud - SCALA!!

Posted by Walter Chang on September 08, 2010 at 10: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 10: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 10: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 10: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 11: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 11:12 AM PDT #

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

Posted by Yang Ful on September 08, 2010 at 11: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 11: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 11: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 11: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 11: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 11: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!


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

Posted by Henrik Ståhl on September 08, 2010 at 11: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 11: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.



Posted by Damon Hart-Davis on September 08, 2010 at 11: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 12:12 PM 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 12:13 PM 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 12:14 PM 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 12:19 PM 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 :)


Posted by Jeppe Cramon on September 08, 2010 at 12:19 PM PDT #

please plan B!

Posted by Georges Gomes on September 08, 2010 at 12:26 PM 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 12:29 PM 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 12:38 PM PDT #

Plan B seems to be the lesser of two evils.

Posted by Alexey Romanov on September 08, 2010 at 12:38 PM 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 12:39 PM 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 12:43 PM PDT #


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 12:48 PM PDT #

Ship. But all means, ship.

Posted by Philippe Marschall on September 08, 2010 at 12:49 PM 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 12:52 PM 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 12:57 PM 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 12:57 PM 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 on September 08, 2010 at 12:57 PM 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 01:14 PM PDT #

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

Posted by Customer on September 08, 2010 at 01:15 PM 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 01:22 PM 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 01:34 PM 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 01:41 PM 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 01:41 PM 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 01:42 PM 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 on September 08, 2010 at 01:47 PM 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 01:51 PM 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 01:53 PM 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 02:01 PM 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 02:05 PM 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 02:21 PM 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 02:21 PM 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 02:38 PM 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 02:42 PM 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 02:48 PM 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 03:24 PM 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 03:48 PM 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 04:10 PM 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 04:29 PM 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 04:48 PM PDT #

not good. Time to look at alternatives.

Posted by sboulay on September 08, 2010 at 04:58 PM 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 05:00 PM PDT #

Any news about the state of the JWebPane?

Posted by Behrang Saeedzadeh on September 08, 2010 at 05:15 PM 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 06:52 PM PDT #

Plan B!

Posted by Anthony Gallagher on September 08, 2010 at 07: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 07:27 PM PDT #

Plan B for me. Good luck with the JCP.

Posted by Hayden Jones on September 08, 2010 at 07: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 08: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.



Posted by Xavi Miró on September 08, 2010 at 08: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 09:21 PM PDT #

plan B , please.

Posted by manward on September 08, 2010 at 09: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 09: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 10: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 10: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 11: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 11: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 11:39 PM PDT #

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

Posted by Tbee on September 09, 2010 at 12:01 AM 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 09, 2010 at 12:09 AM PDT #

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

Posted by Emmanuel Puybaret on September 09, 2010 at 12:24 AM 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 09, 2010 at 12:37 AM 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 09, 2010 at 12:40 AM 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 09, 2010 at 12:52 AM 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 09, 2010 at 01:22 AM 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 09, 2010 at 01:42 AM PDT #

+1 for Plan B.

Kudos to Guillaume Lafforge and Charles Nutter for their comments.

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

Yes, Plan B please!

Posted by Ruslan K on September 09, 2010 at 02:00 AM 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 09, 2010 at 02:05 AM 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 09, 2010 at 02:08 AM 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 09, 2010 at 02:23 AM PDT #

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

Posted by Robert Gibson on September 09, 2010 at 02:29 AM PDT #

Plan B sounds good.

Posted by Chankey on September 09, 2010 at 02:30 AM 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 09, 2010 at 02:36 AM 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 09, 2010 at 02:39 AM 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 09, 2010 at 03:00 AM 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 09, 2010 at 03:25 AM 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 09, 2010 at 03:30 AM PDT #

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 09, 2010 at 03:55 AM 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 09, 2010 at 04:46 AM 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 09, 2010 at 05:03 AM PDT #

plan B!

Posted by Faisal on September 09, 2010 at 05:26 AM 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 09, 2010 at 06:00 AM 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 09, 2010 at 06:17 AM 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 09, 2010 at 06:25 AM PDT #

+1 for Plan B. Please

Posted by Avdhesh Yadav on September 09, 2010 at 06:31 AM 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 07: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 08: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 08: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 09:57 AM PDT #

+1 for Plan B. Please

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

+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 11:50 AM PDT #

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

Posted by Larry Cable on September 09, 2010 at 12:16 PM PDT #

Very sad news indeed.

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

Posted by Steve Ash on September 09, 2010 at 01:27 PM 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 01:51 PM 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 02:22 PM 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 08:59 PM PDT #

Check out: Behind the scenes of Re-thinking JDK 7

Posted by Monis iqbal on September 09, 2010 at 10: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 10, 2010 at 12:59 AM 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 10, 2010 at 01:22 AM 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 10, 2010 at 02:08 AM 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 10, 2010 at 03:09 AM PDT #

My opinion: plan A.


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 10, 2010 at 05:22 AM 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 10, 2010 at 05:29 AM 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 10, 2010 at 05:42 AM PDT #

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

Posted by Okuboyejo Damilola on September 10, 2010 at 06:08 AM 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 10, 2010 at 06:20 AM 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 10, 2010 at 06:50 AM 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 08: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 12:00 PM 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 01:18 PM PDT #

Post a Comment:


Your Comment:

HTML Syntax: NOT allowed