Java In Production

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]

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  |  Comments[0]