Graham Hamilton's Blog

J2SE 5.0 Update 3: the Third Tiger Cub

J2SE 5.0 Update 3 went out today, so I wanted to share a few notes on what is happening with the Tiger update releases.

The Update Release Process

The update releases are intended to each deliver a small number of important bugfixes between our major releases. We have now delivered three updates for Tiger: Update 1 had 124 fixes, Update 2 had 117 fixes and Update 3 has 79 fixes. For descriptions of the fixes see the 5.0 Update Release Notes.

The update releases are intended to be very small and non-disruptive. So there are no API changes and the release teams are very conservative in which bug fixes they accept. We are very conscious that one customer's bug fix can easily turn into an unintended problem for another customer. As part of a release like Tiger or Mustang we have an extensive beta program with long bake periods. This allows us to make a larger volume of changes and also to make riskier changes which require significant public exposure and testing. The update releases are intended to provide fast relief for a small number of key issues. They do still get a lot of heavy-duty QA attention (including a full QA test cycle), but they don't get the long bake periods and enormous QA analysis associated with a major release.

There won't be a 5.1

In case you have been wondering, there isn't going to be a 5.1 release.

We will be going straight from Tiger to Mustang, with only small update releases in between. There won't be anything comparable to 1.4.1 or 1.4.2. Mark Reinhold provided a description of the New Release Model in his Tigers and Mustangs and Dolphins, Oh My! blog. The main goal is to increase the predictability of releases and to allow us to deliver new functionality in a shorter window than the fairly long gap between 1.4 and 5.0.

We know some people like to wait for the ".1" release before moving to a major new software release. So we did consider renaming "5.0 Update 3" as "5.1" just for that reason. But that seemed like it might cause more confusion than it would solve. But if it makes you feel better, you can think of 5.0 Update 3 as the ".1" release of the Tiger family.

So please don't wait for 5.1 to appear: it won't. Go straight to 5.0 Update 3!

Java.com and auto-update

We will not be releasing 5.0 Update 3 on java.com or via auto-update. Here's why.

Our goal is that the update releases be boring. Seriously! They are intended to deliver fixes that will be important to some customers, but they aren't normally a "must-have" item for typical Java end users. So we don't necessarily want to push them all out to our mass consumer audience.

Java.com and the java auto-update mechanism are primarily targeted at making it easy for home consumers to get the JRE. As part of that, we're trying to make sure that the latest version available via java.com is the same as the latest version available via auto-update. But this won't necessarily always be the same as the latest release that is available on java.sun.com.

We will occasionally use auto-update to propagate a new version out to the consumer audience, but we want to do that sparingly. In March we enabled auto-update from 1.4.X to 5.0 Update 2 and as a result millions of consumers chose to do an auto-update to Tiger. We're glad they did that, but we don't want to bother them with another auto-update again too quickly.

Or to say it slightly differently: developers and expert users who choose to do direct downloads from java.sun.com will sometimes have access to more recent update releases than the main consumer downloads available via java.com. Think of that as an extra benefit for using java.sun.com!

Comments

• I understand not wanting to make users download an update they won't see the effects of, but could you explain a little more why you don't want first-time downloaders to have the latest version? I don't understand that.

  Posted by: keithkml on April 28, 2005 at 03:12 PM

• Also, do you plan to provide an easy java-com-style page for developers to point their users at, when the developer's program depends on Update 3? Or are those users going to have to click through java.sun.com and the license agreement and the invisible yellow-on-gray "Continue" button?

  Posted by: keithkml on April 28, 2005 at 03:14 PM

• 
  Keith,

  The main thing here is that we don't want to update our
  consumer customers too frequently and we also want to keep
  the java.com version in synch with the version provided
  via auto-update. In the past we sometimes had those be
  different and we found that it confused people.

  Right now, we're not planning to change the download
  experience on java.sun.com itself.

          
          
          
          
          
          
          
          
  - Graham

  
  

  Posted by: kgh on April 28, 2005 at 05:42 PM

• How could I get involved in this? Previously I've had to download the Java installer for Windows and Linux onto my web server, and link to those, to spare my users from having to go through the java.sun.com download page. I think it violates Sun's license but I didn't want to put my users through that download process.

  I think this is a bad decision and that Sun is ignoring needs of developers, to make Sun's job easier. By providing no direct or automated download link, how do you expect developers who depend on Update 3 changes to distribute their applications?

  You say you want to keep the java.com version in sync with the auto-update version to prevent confusion. Personally I think it's more confusing that Sun would avoid distributing updated versions of its products, and make it hard for developers to do so.

  Posted by: keithkml on April 28, 2005 at 06:17 PM

• I mean, "how could I get involved in this decision to try to change it?" Should I file an issue on the Bug Parade? Should I talk to whomever made this decision? I feel sure that most developers who deploy Java applications, want Update 3 to be on java.com.

  Posted by: keithkml on April 28, 2005 at 06:19 PM

• I don't want to shoot the messenger here, Graham (especially as you have such an awesome name), but there do appear to be some inconsistencies in what you're reporting here:

  Firstly, you've indicated Update 3 is significant by equating it to a 1.5.1 release, but if it's more significant than Updates 1 and 2, why isn't that being indicated by using the micro release number? Essentially this means that there were a bunch of bugs when 1.5.0 went out (as everyone expected - no criticism there), but all the important ones are now fixed. This seems like a pretty significant event, and yet it has been marked by an "Update 3" release, which sounds like a minor event rather than significant. Add to that the fact that there is now a number in the version name which is no longer used and the whole version thing is starting to look really confusing. I think something needs to be done about these numbers at least before Mustang goes out. The "Update x" thing just isn't working for me. I don't think people would care too much if you started using the micro number instead (as of Mustang, that is).

  Secondly, you've indicated Update 3 is significant by equating it to a 1.5.1 release, but it's not being pushed to consumers. I would have thought if any update version were to be pushed out it would have been this one, due to its significance.
  I wonder if one of the reasons this is such a big decision is because JREs can't be upgraded (so far as I know), but instead a new one is downloaded each time? I assume this is done because some people (i.e. developers) need to have more than one JRE installed. That's fair enough, but I think the "consumer" release should be able to be upgraded where it lies, requiring a much smaller download and making a consumer upgrade a much less important event, hence allowing consumers to have the latest version all the time.

  Graham.

  Posted by: grlea on April 28, 2005 at 07:09 PM

• I am waiting for the JDK 5 Update 4, because it will fix the bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6205422 in which the applet load time is slow due to Java logo animation.
  Can anyone tell me when this will be released.
  Thanks in advance.

  Posted by: carcour on April 29, 2005 at 06:15 AM

• I, too, find this a bit disturbing and frustrating. Thank goodness my app isn't out yet. 1.5.0 introduced a horrible performance problem (with images) that would have killed my app. Thankfully, it was fixed in 1.5.0_02. Now you're saying that if it had been fixed in 1.5.0_03 instead, users who are signed up to get automatic updates wouldn't have gotten that fix. Ay, ay, ay.

  Posted by: detorres on April 29, 2005 at 08:16 AM

• I think the core problem is a lack on granularity in the update process. What's in u3 looks like pretty trivial stuff so I'd agree it shouldn't be pushed as a priority update to all. But the case for not supplying it to new users nor anybody doing a manual 'check for updates' is significantly weaker IMHO. Don't even get me started on the ongoing problems with Java Web Start auto-download runtime availability. Isn't Java Update designed for small fixes like this, just downloads the delta. Even if just for sheer convenience and the wasted months of that update process wasting cpu/memory resources for nothing! it'd be nice to see it start paying its way.

  Maybe Sun needs to adopt tiered approach not unlike MS, only prompt the users for critical updates i.e. major versions or security holes. But still allow the update (read less buggy) jre to be made available to anybody manually requesting it via the easy channels Java Update, Get Java site etc..

  You can't really be expecting end-users to trot off to sun.java.com and successfully find, download and install a particlar version of the runtime. Thought you guys were supposed to be improving the runtime deployment issues ;)

  Some well written instructions on how to provide the Active Directory automatic runtime client install (on login) with elevated priveledges certainly wouldn't go amiss either. The only stuff I've found on this is scattered across several bug reports and deeply cryptic. We're not all MS-Certified you know.. (assuming it'll actually work with 5.0u3 now).

  Posted by: osbald on April 29, 2005 at 09:06 AM

• I would prefer to have an option to force an update if it isn't getting pushed out.

  This is much nice than having to download a new version by hand.

  Posted by: darcy on April 29, 2005 at 11:25 AM

• I believe that Sun should be trying its hardest to make Java less confusing for developers and end users in all respects. The download process for developers is unnecessarily confusing. Java.com isn’t perfect ether.
  The version numbering is even more confusing than anything. It should be Major.Minor.Revision like almost everything else. If you ask a user what version of Java they have, would a developer know exactly what they mean if they said Java 2, Java 5, Java 2 5, Java 1.5, Java 2 5 1.5, Java 1.5.0, Java 1.5.0 Update 3, Java 2 5 1.5.0 Update 3, etc…? If you read those back to a user, those could ALL be the same if they have the latest version from java.sun.com. You should have seen my mom’s face when I tried to explain to her what the different versions of Java were and what they could be named.
  Sun should do us all a favor and pick a naming scheme and stick to it extremely strictly. There is no reason why when you type “java –version” it says “1.5”. It should say “Java 5.0 Update 3”.
  Now about the update. Why would Java developers spend all this time to come up with Update 3 and then basically only release it for developers? I assume that java.com is THE user download page, and java.sun.com is THE developer download page. It looks like what your saying to the community is:
  There is no reason to download Update 3. Your end users will never have it. The next release that your end users will ever see is Mustang, so if you want to test against the next version, download the Mustang beta.
  Its funny that you favor consistency among deployed users over consistency between developers and users. That seems like the complete opposite of what would be best. Users should be using what developers are using or developers should be using what users are using. Update 3 doesn’t fit into any of those situations as of now.
  What’s worse than a developer trying to find out of something isn’t working because of a bug in Java? A user trying to explain to a developer what version of Java they are using. Or a user trying to find out if the problem they are experiencing is a bug that’s fixed in the hidden Update 3.
  Do your users and developers a favor and make Update 3 more available, and fix the version numbering before Mustang is finished.

  Posted by: cosmotic on May 02, 2005 at 01:26 AM

• cosmotic: +1

  Posted by: marcs on May 02, 2005 at 04:05 AM

• OK, I'm back. I just tested the "auto-download the JRE" feature from the JWS documentation. With no JRE installed, the scripts running in IE download 1.5.0 (not even 1.5.0_02). And this is from java.sun.com, not java.com! But if you browse there (http://java.sun.com/j2se/1.5.0/download.html) it shows 1.5.0_03 (JDK 5.0 Update 3 to be more precise)! It really does seem like you're trying to sabotage Java. And only one reply from Graham so far. Is this the cold shoulder, or are these issues being discussed at Sun? It seems like so many good things are happening with bug fixes, new features, and community involvement, but marketing is trying to undo it all.

  Posted by: detorres on May 04, 2005 at 09:42 AM

• detorres - I actually meant the other java web start auto download, I guess your're talking about the Windows only ActiveX auto download. While I mean the JNLP Spec j2se vendor jvm element auto download. e.g. ..although my experience with both channels is much the same, perpatually one version behind and often only gets every other update.. as of 5 minutes ago I see these JVMS available.. spot the gaps? 1.3.0_02, 1.3.1_08, 1.3.1_09, 1.3.1_11, 1.3.1_13, 1.4.0, 1.4.1, 1.4.1_02,
  1.4.1_07, 1.4.2, 1.4.2_01, 1.4.2_02, 1.4.2_04, 1.4.2_06, 1.4.2_07, 1.5.0, 1.5.0_02

  
  For me as a predominantly client side Java developer runtime deployment (and acceptance) is one of the trickiest hurdles I face. I'm hopeful that mustang will finally address these issues (hint, hint elevated privs install). If Sun continue to fluff this issue client-side development will doubtless slide towards .Net as the path-of-least-resistance - every copy of Longhorn will be coming with their runtime both pre-installed and auto-updating.

  Posted by: osbald on May 06, 2005 at 03:52 AM

• OK, I'm back. I just tested the "auto-download the JRE" feature from the JWS documentation.

  存倉
  辦公室搬運
  搬屋公司
  搬屋

  Posted by: xuefeng8 on August 02, 2007 at 03:27 AM

This work is licensed under a Creative Commons License.