11

I have been working on the JVM for years and I have very rarely experienced a JVM crash ... that is until approx 6 months ago.

Since that I have experienced approximately 5 JVM crashes resulting from 2 JVM defects. The solution from Oracle was always the same ... upgrade.

Each upgrade is always to and from a point release ... i.e. and Oracle's latest suggestion (after confirming that they did fix the bug) was to upgrade from 1.6u20 to 1.6u26.

How concerned should I be upgrading minor versions of the JVM?

Is this a big event that necessitates enormous amount of regression testing or are they safe upgrades that should be embraced?

Dakotah North
  • 3,353
  • 1
  • 20
  • 31
  • 4
    In which context will the JVM in question run? Do you use it to play game applets or do you run a hospital's information system on it? The correct answer heavily depends on that information. – blubb Aug 04 '11 at 10:44

3 Answers3

5

It shouldn't be a big event to upgrade a minor version, and I've never experienced problems.

That said, the infamous Java 7 problems are somewhat scary, and even tough it was a major version upgrade, those specific problems appeared in fact in Java 6 ~u20 and were maybe fixed in u25. They surfaced only because Java 7 has some optimization flags enabled by default that Java 6 has not. Had you used those flags in Java 6, you could have experienced not only crashes, but incorrect execution of loops, that is, miscalculations, because of a minor upgrade from 6u19 to 6u20 (approximately).

The fact is, no one guarantees that an upgraded version will work at all. The JVM, its environment (computer, OS), and your application, they all interact mutually, and to be reasonably sure that the whole enormous pile of stuff plays nicely together, you indeed should do enormous amount of regression testing.

My approach to JVM upgrades is similar to any upgrades: unless I have a specific need to upgrade and unless it's a critical security upgrade, I'll wait for a while and read other peoples' experiences in the internet. If no one complains within a month or so, then it's likely safe to upgrade.

Joonas Pulakka
  • 23,534
  • 9
  • 64
  • 93
  • 1
    Is there any place specifically that you look to read other people's experiences in the internet? – Dakotah North Aug 07 '11 at 02:14
  • @Dakotah North: Not a specific place. Hanging on numerous mailing lists (such as [announce@apache.org](http://mail-archives.apache.org/mod_mbox/www-announce/), where an alert of critical problems came on the day Java 7 was released) provides plenty of this sort of information. – Joonas Pulakka Aug 08 '11 at 07:12
4

In my experience with enterprise Java applications, the benefits of embracing the minor JVM updates ouweigh the associated risks.

One benefit is that the minor updates almost always contain bug fixes. Applying these updates can actually improve the stability of your production environments. I have experienced JVM crashes where the root cause analysis reveals that the defect has already been identified and fixed in a minor JVM update.

Another benefit is that minor updates often contain performance improvements. However, as noted by @Joonas, it is risky to use unproven or experimental performance flags in any update (major or minor) without significant testing.

As with any change, it is most important that you proceed in a responsible manner. Here are some practices that I follow when planning for a JVM update:

  • Carefully review all of the release notes for every minor update between your current version and the target version.
  • Understand your users tolerance for application outages, and regression test accordingly. (@Simon)
  • Research the experience of others on the Internet (@Joonas)
  • Have a rollback plan in place (@Thorbjorn)
Pierre.Vriens
  • 233
  • 1
  • 2
  • 11
Mike
  • 41
  • 3
3

Around Oracle Java 1.6 u20 a safety check alerting for "Mixed code" was introduced, which influenced our application for some users causing it to crash. This was a minor upgrade, and had severe influences in production.

Always be prepared for a rollback.