Oracle Confirms Plan B for the JDK

Posted by Alex Blewitt on Sep 21, 2010

Sections

Development

Topics

JCP Standards ,

JCP ,

Java ,

Languages ,

Programming

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.

1. Back to top

   I can't believe....

   by Clinton Begin

   You're spinning this as a good thing. No offense, I appreciate that some people might look at the Oracle acquisition of Sun as a good thing.
   
   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.

   Reply

2. Back to top

   Re: I can't believe....

   by Filip Fracz

   I totally agree with you. Java as a language has become very stale. Bold steps need to be taken to revive it.

   Reply

3. Back to top

   Good for JVM Languages!

   by Fernando Racca

   Most if not all the useful features are in JDK 7, which means that you can already start making all the existing languages of the JVM even more powerful. It also means that a smaller release will have better adoption.
   
   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 :)

   Reply

4. Back to top

   Re: I can't believe....

   by Mike Funk

   Well stated, Clinton!

   Reply

5. Back to top

   Re: I can't believe....

   by Rhys Parsons

   It seems to me that the biggest problem Oracle has (as Sun had) is that so many people and organisations have a stake-hold in Java.
   
   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.

   Reply

6. Back to top

   Stick a fork in it!!

   by Lou Marco

   The Java language is entering its old age. No need to prettify it. Java is used by just about non-technical, data-intensive organization. As someone who works for such an organization, we don't need closures and other features that 'complicate' the language.
   
   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".

   Reply

7. Back to top

   Re: Stick a fork in it!!

   by Faisal Waris

   Java works but I bet that if the mainstream gets a good taste of some of the advanced features (such as lambads) it will change its mind very quickly. The problem is that most don't know what they are missing. And it takes a good few months of actual usage to really appreciate a new language feature such as lambdas.
   
   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.

   Reply

8. Back to top

   Nothing is good for everything

   by Davi Tavares

   I don`t like Oracle in the way I do like Java. Actually, I wanted that IBM had bought SUN instead of Oracle. However, it is going ok as it is. I don`t what nobody messing up my Java. I believe Java itself must be evolve very slow and than the frameworks, process and tools help Java to make things better and better. So in this way, I`m looking forward for bleeding edge tools/classes like jBoss 6, WEB 2.0 frameworks, servlets 3 and better management based on JMX and so on.
   
   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

   Reply

9. Back to top

   Re: I can't believe....

   by Vincent Laisney

   Java must remain Java, a simple and easy to learn, yet powerful language. It has proven its value and strength. It was a tough decision to refuse change which can "disfigure" Java.
   
   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.

   Reply

10. Back to top

    Re: I can't believe....

    by Andrea Del Bene

    couldn't agree more with you. All Java should offer (must offer in my opinion) is a clean and true object oriented abstraction with the simplest syntax.
    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"

    Reply

11. Back to top

    Re: Stick a fork in it!!

    by Sam Corder

    I don't believe the Java can be like COBOL in longevity idea. First you have to look at where most COBOL was written and where it continues to run. It was written on walled garden machines that continue to be a profit to the land owner (IBM). IBM has no interest in making old COBOL not run anymore because it will kill off a large revenue stream. Contrast this with Java which doesn't truly have a single maintainer. Can a 1995 Java app run on a 2010 VM? Yes it can. But can a 1995 VM run on 2010 hardware? Maybe. And that is the real problem. If there are no more new JVMs to run on the newest and greatest hardware Java will never have the lifespan of COBOL. In my opinion COBOL was a once off and the factors and conditions to repeat it are gone forever.

    Reply

12. Back to top

    Re: I can't believe....

    by Faisal Waris

    The whole point of advance language features is to make *your* code simpler and more understandable. Making the Java language somewhat bigger to achieve this is a good trade-off in my opinion.
    
    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.

    Reply

13. Back to top

    Re: Stick a fork in it!!

    by Dave Nicolette

    Not sure if this is really valid, but I think the main factor that made COBOL a success was that it more-or-less protected the average programmer from making memory-management errors. Throughout the mainframe era languages were available that were more "interesting" than COBOL, but for widespread and long-term success in the business application domain a language had to be practical for the bottom 95% of programmers. Java seems to have the same characteristic, and I expect it to enjoy longevity similar to that of COBOL for that reason. Other "managed code" technologies may enjoy long market life, too.
    
    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?

    Reply