Java In Production

6 Update 4 Released

6u4 is now available for download.  See the README for details of the bug fixes. 6u4 contains Olson 2007h.

Posted at 02:31PM Jan 12, 2008 by Stephen Fitch in General  | 

Security Updates for Java SE Released

Sun has released for download security updates for JDK and JRE 6 Update 3, JDK and JRE 5.0 Update 13, and SDK and JRE 1.4.2_16. This will be followed by the release of SDK and JRE 1.3.1_21 on the second week of October 2007.

Posted at 03:04PM Oct 03, 2007 by Stephen Fitch in Revisions  |  Comments[3]

6u2 Released

6u2 is now available for download. The release includes the new look and feel for the JDK installer, this is the first of a number of changes to improve the applet deployment experience, you can see what is being planned in the following Java One presentation. See the README for details of the bug fixes. 6u2 contains Olson 2007f.

Posted at 10:48AM Jul 06, 2007 by Roger Calnan in Updates  |  Comments[2]

1.4.2_15 Released

1.4.2_15 is available for download with a selection of critical fixes and the Olson 2007f timezone data update, see the ReleaseNotes for details.

Posted at 10:17AM Jun 28, 2007 by Roger Calnan in Updates  | 

Java SE Lifecycle - From GA to EOSL, and beyond...

We have received a number of "What is the EOL of x.y.z?" messages recently from customers who are trying to understand how long they can stay on a particular Java SE release. Simple question, should be straightforward to answer. However while the information is available it is not that easy to put together, so here is an attempt to explain the current Java SE model. This is also relevant as we are considering changing how we determine the dates, but first what is the story today?

The Current State 

To start with what do EOL/EOSL mean?  Here is a diagram to help explain what this means for Java SE:

To get going we need to explain another term GA (General Availability) which is the date on which the release is "generally available" for download (it is likely to have been available previously in a more limited way via a beta/early access programme). From that point onwards the release is available to the End User to use on their desktop and developers to develop and ship with their latest application. If problems are found then they are fixed and the release updated. At the EOL point developers are asked to stop bundling that version in new products and migrate to a later release, fixes are still made available. Once EOSL is reached no more fixes are made available for the release.

For example (* with approximate dates for future events):

Release Family	GA	EOL	EOSL
1.1	1997	2000	2002
1.2	1998	2002	2004
1.3	2000	2004	2006
1.4	2002	2006	2008*
1.5	2004	2008*	2010*
1.6	2006	2010*	2012*
1.7	2009*	2012*	2014*

 
For Java "in" Solaris it gets a little more complicated but let's leave that for a later post.

Another aspect that is important is that a Release such as 1.5 (aka: 5.0) isn't just one release it is composed of multiple releases that span from GA to EOSL (hence the use of the term Release Family in the table above). Since 1.5 Java SE we have only released Updates after the GA of a new release family so I'll concentrate on EOL/EOSL in relation to Updates.

The first thing to notice is of course that the EOSL happens when the Update is released! This basically comes from the fact that it is not currently possible to get a fix on the latest Update, the fix is released in a following Update (we will come back to this later). So looking at a set of Updates over time one sees:

This basically means that there aren't separate EOL/EOSL dates for Updates the current Update EOL's when the next comes out, the dates that matter are for the Release Family.   This is covered in more detail here:

http://java.sun.com/products/archive/eol.policy.html

The "Ideal"?

With any software product there is always a tension between not changing anything (it just keeps on working) and fixing the issues that arise for some but rarely all users.  Also there is the decision around should the change be against the current release or a new release (can perhaps be thought of as the window of support)? There is no right answer and it is always a trade off between trying to have customers keep up (small window) and continuing to support older releases (larger window). Clearly if the later release is perfectly compatible with the older release then migration is smoother but even here there is an element of risk which means that the admins of mission-critical servers on principle want the smallest change necessary, especially if they have to apply it out of their normal update cycle. At the moment our window of support is very small which has a tendency to push customers to the latest release. While this isn't necessarily bad in some cases, as a "one size fits all" solution it has some downsides.

Expanding the Window

As was covered in an earlier post we are considering allowing Updates to be updated with critical fixes so that it is not necessary to wait until the next Update for the fix (in effect expanding the window). In the context of EOL/EOSL that would mean:

where as you can see there are less updates being produced (the level of change remains the same and so the number of fixes in each update increases). Note that there isn't a scale on the above diagram on purpose as it is expected that the frequency of the Updates during the life cycle of a Release Family will change (get longer) as might the width of the window (GA - EOSL) but I won't cover that here.

There is also the question of how long should a Release Family be supported?  From the table above you can see that we have historically supported a Release Family for around 6 years (although there are options for longer support). However that is measured from the time that we ship a Release Family and in most cases for large applications, not when it is adopted. In fact the was a conversation a few days ago around a software company that has a product that just stopped shipping with 1.4.2, however they will need to support those products for their customers for another 10 years, that works out to be around 15 years from the date that 1.4 first shipped....  The good news is of course that software doesn't tend to age, however as things are changed around it (new OS's, new hardware, faster networks) issue can and do come up. Can we get to a point where a release is supported for that long? We are considering what might be possible, let us know what are the time frames you have to deal with. 

Posted at 09:40AM Jun 25, 2007 by Stephen Fitch in Production  | 

Scoping out a new JRE distribution model

    In amongst the announcements at Java One this week you may have seen that we are seeking input on a new programme that we starting aimed at businesses, ISVs and others who deploy Java applications.  This marks a notable step forward and one which we hope will address the feedback that we have received about cutting down the cost and complexity of managing Java within the Enterprise.

While we are still very much focused on improving the productivity of developers and the experience of the end user, we will be looking to enable more of the management and deployment options for those of you that are involved in:

• the deployment of Java across 100's, 1000's and in some cases 10,000's of PCs; and

• the challenging task of keeping a mission critical servers up and running whether it be trading stocks, tracking parcels or an in-house finance application to reconcile the end of quarter results.

Our current model can be seen in the above diagram, on the left in an example where we have released Update 3 or U3 (also referred to as the General Availability or GA date) and we are working on the development of U4. While we work on integrating and testing the fixes in U4, U3 is current (is the default download off java.sun.com – referred to as the Standard Access period above) and then when U4 is released we EOL (End of Life) U3 and you are encouraged to move up. On the right one can see what it would look like some time later when we are working on U6 and U5 would then be the current active release. If you would still be on U3 at that point, you would be lacking a number of critical fixes that had been released in U4 and U5.

While the model is straightforward it can be problematic as changes only become available when the next Update is released; critical fixes are mixed with non-critical fixes; and, you must move to the latest Updates to access the changes. What we are considering is a change to our release model that will improve the situation although as might be expected, this will not solve all the issues. The way we have gone about this is what we have been referring to internally as "Critical Fix Separation", which basically means that we will allow escalation fixes (fixes that solve a customer/developer production issue) to be released in parallel to the current Update in development.

We will be releasing the escalation fixes via what we are calling Revisions which will be small, (very) tightly mananged, but still cumulative, JRE releases.  The fixes will also go into the Update under development and so at the point an Update is released it will contain the fixes that have been released via Revisions as well as the other maintenance fixes.

This is shown in the above diagram where you can see that Revisions are released against U5 in parallel to the development of the U6 release. Note that U6 development can now take longer (in this case a year) as key fixes do not need to wait for the release of U6. Customers who raise issues within the first year after the release of U5 will be able to receive that fix on U5.

It is at this point it is worth being clear that like our existing support programmes, access to the Revisions will be via a (for fee) subscription that will be aimed at providing extra flexibility to mid to large organizations.   All the fixes will still be available to for free via OpenJDK and in binary form via the most current Update.

Building on the basic model of Revisions we are also considering offering an Extended Access period to Updates, for subscribers, which will enable an Enterprise to stay on an Update past the standard EOL  for up to a year or more, and still receive the most critical of fixes such as Sun Alerts around Availability, Data Loss and Security.
 

This enables us to better address the needs of customers who want to stay longer on a particular update, as well as customers who want access to the fixes in the more recent updates. For example in the above diagram if you have an application on U3 you will be able to stay on U3 past what would normally be the EOL (when U4 is released) and receive critical fixes up until you finally do need to migrate to a newer update. At this point you have the option of migrating to:

• U4 – moving to U4 involves the testing of the smallest number of changes  but at this point U4 is in the middle of the Extended Access period and so you would need to migrate again much sooner.

• U5 – while moving to U5 means testing the fixes from both U4 and U5 you would join U5 just as it  starts the Extended Access period and so would not need to migrate again until the end of that period.

• U6 – if there are fixes and/or performance improvements then moving to U6 is still possible.
  

While I have only covered some of the elements of the new programme I hope it has given you some sense of the model that we are investigating. While implementing the changes in our infrastructure and bringing our Licensees and ISVs up to speed on the model will take time, we are planning to run a beta of the new service later this year with the ability to sign up for the subscription in 2008.

We will be posting more information over the coming weeks/months as we talk to more of you about the features that you would like to see.  If you would like to sign up for the beta or have questions please send us email to Production-Java at s-u-n dot c-o-m.

Posted at 10:33PM May 11, 2007 by Roger Calnan in Revisions  | 

Opening up the conversation

Welcome to Java in Production a way for the Java group to talk about and get feedback on the usage of Java SE in production settings. We hope to cover topics of interest to those of you who manage Java across both desktops and servers. While Java is used successfully in a wide range of situations, we believe there is more we can do to improve the experience and plan to discuss the ideas and questions you have raised.

Posted at 10:31PM May 11, 2007 by Roger Calnan in Production  |