Oracle Confirms Plan B for the JDK
As announced previously, Mark Reinhold noted that there had been much support for Plan B in the comments on his post.
As a result, Plan B was announced at JavaOne, and later followed up with a press release, which confirms that lambdas, modularity and the Swing application framework will not be part of JDK7; nor are any promises made about availability in JDK8. The updated feature list for JDK7 is roughly the same as it was before; though in addition, the support for Java collection literals has been dropped from Project Coin, deferred as it is to a future JSR.
What made it in was work already in play; JDBC 4.1 has been confirmed for JDK7 (given that it was already complete, it was a no brainer) and an additional NIO.2 filesystem support for JAR/ZIP files. Other improvements not originally planned include support for Transport Layer Security 1.2, as well as using the Vista IPv6 stack on Windows platforms.
Having put the acquisition firmly behind, Oracle seems to be making the tough decisions to move the Java platform forward, rather than spreading resources out too thin over technologies like JavaFX Script. Whether this is too little, too late remains to be seen; but Oracle has had the courage to make pragmatic decisions in a way that Sun could, or would, not. However, there is still no word about the ongoing issues with the JCP and the lack of a freely available TCK for Java, and it looks like the issue won't be resolved in this JavaOne. What that means for the Java standard remains to be seen.
I can't believe....
by
Clinton Begin
But essentially what we have here is one of the richest companies in the world, with literally billions of dollars at their disposal, and yet they can't achieve what other projects have -- projects that get paid little or nothing at all...
Mono (C#), JRuby, Groovy, JavaScript (Rhino) and Scala all have support for type inference, lambdas, closures, literal syntax for collections (or even anonymous types), as well as things that aren't even on the list (like multiline strings).
None of these require JVM changes. They can all be implemented in the compiler alone (most mentioned above are JVM languages). None of them are a threat to anything that Java is today -- and definitely not so much as the half-baked generics, annotations and autoboxing implementations. They couldn't possibly screw these new features up any more than those of JDK 5. :-)
This is really weak and disappointing. We shouldn't look at this as if Oracle is now making the tough decisions Sun couldn't. Oracle has the money... they don't have to make tough decisions. They can make killer decisions that decimate competition and don't leave us wanting for another language. But instead, they're going to slowly and painfully ensure the death of Java through bureaucracy and laziness.
Re: I can't believe....
by
Filip Fracz
Good for JVM Languages!
by
Fernando Racca
This is great news for Scala, JRuby, clojure, Groovy and many others!
In the meantime, Scala already offers everything that JDK 8 promises and more :)
Re: I can't believe....
by
Rhys Parsons
Essentially, they can't do anything 'right'.
However, by supporting languages such as Scala, Groovy, etc, Oracle are essentially backing community uptake of these languages.
Java (the language) doesn't necessarily need lambdas if you have them in Scala or Groovy.
These problems aren't just a matter of resourcing. They're also a matter of strategy.
Stick a fork in it!!
by
Lou Marco
Business is interested in state-of-the-practice, not state-of-the-art.
C'mon. There is still uncounted millions of COBOL code out there in Bank/Insurance/Brokerage/Retail land and this code is not going away soon. Same for Java. The Java out there 'works' and I dare say there is no groundswell among the business movers-and-shakers for anything resembling advanced software features.
Just make it work. The simpler the better.
Put differently, seems the prayer for the Corporation is "Please let today be like Yesterday - because we survived Yesterday".
Re: Stick a fork in it!!
by
Faisal Waris
BTW lamdas started life over 20 years ago so they are not new in that sense!.
I think that cloud computing (whether public or private) will start to expose limitations of the Java language/J2EE environment. I came across an interesting Gartner presentation that outlines how the programming model shift happening due to cloud computing is fostering greater adoption of languages such as Scala, Erlang, F#, etc.
Nothing is good for everything
by
Davi Tavares
C/C++ is around us for years without evolving but no one is asking for this....
;-)
Oracle, K.I.S.S. my Java ok!
Davi
Re: I can't believe....
by
Vincent Laisney
If somebody needs more he has now the choice: he can use other java-like languages like Groovy or Scala. The choice of languages is large. A language that wants to integrate too many features and constructions risks to become a PL/1 or an Ada or even an OCaml.
Scala has now the problem of being nearly too complicated. See the recent discussion.
Re: I can't believe....
by
Andrea Del Bene
Even Brian Kernighan and Dennis Ritchie believed in the importance of keeping syntax simple and consistent, as you can read in the preface of their 'bible' "The C Programming Language"
Re: Stick a fork in it!!
by
Sam Corder
Re: I can't believe....
by
Faisal Waris
C# has added many features (type inference, lambdas, LINQ, dynamic typing) since its inception and that has not burdened the language much. Type inference alone can reduce much needless typing. LINQ (which leverages lambdas) can cut scores of lines of nested for loops into a few simple lines.
Java did a great service in bringing OO to the masses but why stop there. Lets move forward by adding functional and other features to the language. Programmers can adopt these at their own pace and we all will be better off in the end.
Re: Stick a fork in it!!
by
Dave Nicolette
Java has another characteristic in common with COBOL, too: As COBOL moved into middle age, programmers who were interested in moving their careers forward began to turn to emerging technologies; schools began to drop COBOL courses from their curricula; new entrants into the workforce declined jobs that involved COBOL maintenance work; the ANSI COBOL spec very very very gradually crept toward the 1999 version, with a misguided effort to include the vendor-specific extensions that were already in the market, and too late to make a difference anyway; and COBOL settled into legacy status. When legacy technologies go, they do so "not with a bang, but with a whimper."
Do I hear a whimpering sound again, or is it just tinnitis?
Educational Content
Writing Usable APIs in Practice
Giovanni Asproni May 19, 2013
Concurrency in Clojure
Stuart Halloway May 17, 2013





Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think