Java SE 7 - Plan A or Plan B?

<script type="text/javascript">tweetmeme_url = 'http://blogs.oracle.com/javaone/2010/09/java_se_7_-_plan_a_or_plan_b.html';</script> <script type="text/javascript" src="http://tweetmeme.com/i/scripts/button.js"> </script>
Share <script src="http://static.ak.fbcdn.net/connect.php/js/FB.Share" type="text/javascript"></script>
by Janice J. Heiss

There has been much buzz within the Java community about the future of Java SE 7 since Mark Reinhold's blog post of September 8, when he shared with the community what Oracle was considering doing with the next Java SE release, and in effect, solicited responses. I want to clarify the options that were presented, and the various responses that I have seen in the discussions. (I'm not taking a stand here;  I'm just putting in writing where I see the discussion is as much for my benefit as anyone reading this - wink.)

As Reinhold put it, it all came down to Plans A and B:

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

Plan A has the obvious weakness that it would be nearly 2 years before it could be completed, tested, stabilized, and released and that is a "best estimate".

But much valuable work has already been done. As Reinhold wrote, "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."

The strength of Plan B, as Reinhold saw it: "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."

Reinhold made it clear that Oracle favored Plan B, but solicited reasons why Plan A might have value. He was wisely trying to make sure he wasn't missing something.
 
The reactions that I have seen have been overwhelmingly but not exclusively in favor of Plan B. What follows is distilled and summarized from the comments and postings of many thoughtful developers.

For Plan B:

* It's better to have something in 2011 than nothing.

* More frequent releases offer customers more flexibility and deliver value more frequently and steadily.

*With frequent releases, feedback flows more quickly and easily into future releases, which is better than waiting for years for a big release with both a multitude of features and bugs.

* Opting for a "let's wait and ship EVERYTHING!" approach never works for companies.
 
* The adoption rate will be high  because the changes are not too radical.

* The improved file/directory support in NIO.2 alone justifies Plan B.

* Releases that are little and often are easier to absorb and quicker to generate feedback. A lot of people only go to every 2nd release. More releases speed that process up and move the platform forward.

* It's low impact, gets the basic release out to developers sooner, and would probably take the pressure off development of Lambda, Jigsaw & Coin. As I'm sure most software developers would agree, it's better to have more small releases, than one release with a hard to reach goal. We have high expectations for Java releases, so it's best to keep quality in mind rather than rush something out. In fact, with such a high profile release, a rushed delivery could really damage Java's reputation.


Against Plan B:

* Adoption in the enterprise could be low. Companies might not upgrade when they know a new release is planned for the following year; or because content is not compelling.

* Plan B amounts to just several little features.

* Plan A is preferable because it will lessen fragmentation. Plan B just means we'll have at least one more not very exciting version of Java to support.

* The Java language has matured enough so that constant new releases just create an ever more confusing alphabet soup of specs that hinder, rather than further adoption.

*  Plan A offers a single solid release rather than getting the features in bits and pieces. It would be easier for organizations to plan ahead and adopt in one go.

These are some of the arguments put forth. The news should come soon. This makes for a very interesting JavaOne with significant community engagement. So, what do you think? Join the conversation.
 
Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

javeone logoJavaOne Conference 2013 Content

San Francisco, USA: Sept 28 - Oct 2, 2014

Links

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