14

Some people run the bleeding edge of technologies - updating the day that something is updated. In production, this isn't as appropriate.

Researching about if the current (Java 7) version is ready for production produces a significant amount of old material that might not be correct anymore (at the time of this writing Java 7 has been out for a year and a half which seems plenty long).

What considerations do I need to make to determine if it is appropriate to upgrade the production environment to a later version of Java?

JohnDoDo
  • 2,309
  • 2
  • 18
  • 32
  • Even if it were, any third-party library/plug-in that are used (if any) in said application would need to be OK with Java 7, too (risky business). – arin Jan 17 '13 at 17:23
  • 2
    Yes. The only issue I have run into is that I couldn't install Java 7 on Red Hat Enterprise Linux 4, but then, that OS is obsolete. I've been using it in production everywhere else for about 6 months now without a hitch. – GlenPeterson Jan 17 '13 at 19:22
  • @arin: not with Java, not really. It tends to be ridiculously downwards-compatible. – Michael Borgwardt Jan 17 '13 at 22:05
  • @MichaelBorgwardt in theory I agree with you, but in test environment I have seen third-party libraries cause erratic behavior/crashes in our test code even after updating to a small version upgrade. – arin Jan 17 '13 at 22:12
  • @arin: sure, it can happen. But in my experience it's so rare that there's less reason to be scared of updating Java than of changing almost anything else (especially one's own code). – Michael Borgwardt Jan 17 '13 at 22:16

1 Answers1

11

The first question to ask is "Is the version of Java supported on the machine?" While updating the JRE is one thing, it may be that the underlying OS is not supported running the new version of Java (supported certifications and support contracts and the like that many enterprise environments like to have).

Many java production environments are actually running on top of an application server. This would be the next consideration. Wikipedia comparison of Java EE App Servers shows what version of Java EE is supported. This can be further seen in Oracle's JavaEE compatibility overview. The tested configuration for JBoss Enterprise Application Platform 6 is against Java SE 6.0 update 6u30. Java SE 6.0 update 6u30 is also the tested configuration for JBoss Application Server 7.1.0 Final. These may work in Java 7, but they are not tested configurations.

Expanding on the application server, there are live code analysis tools that are used to do debug after the fact. Omniscient Debugger (see also) and Dynatrace are two examples of this. These applications work by instrumenting (modifying) the live byte code of java running to report back to it. As these applications work by modifying the byte code, if the byte code changes in a way they are not capable of working with (such as in a new JRE), they won't work.

Next down the line is the frameworks. One example of this is JAXB that comes with java and Spring which uses it. Changing to Java 7 updated JAXB which generated code that was incompatible with some frameworks (which requires them to be updated and their dependencies would need to be updated...).

Build tools are next on the list. One would need to make sure that the build environment is using the proper version of Java. Writing code for Java 7 but not updating the version that Maven or Ant uses would then cause problems. There are times when the build tools themselves are strongly tied to one version with particular plugins.

Testing tools. Things such as PMD, findbugs, and checkstyle may not recognize new structures in a new version of Java - these may get very confused with string switch statements or compound catches. Tools that get into instrumentation such as code coverage may not work in the new JVM. In the context of Java 7, Cobertura and Emma have not been updated to the new JRE (again, these applications modify the byte code to see which code is run and which isn't) (see open source code coverage libraries for jdk7). This could require a change to the build scripts to switch from one to another.

Then there is the IDE. One would need to update the IDE to a version that is aware of the new structures in the language. Eclipse's announcement of support for Java 7 shows these issues.

Last and certainly not least is the developer. It is up to the developer to write the new code and be aware of how code can be restructured. Going from Java 1.4 to 1.5, templates and annotations were introduced and it took time for the developers to get into the mindset of the new structures available. Likewise the collections rework back in 1.2 and getting developers away from using HashTable and Vector. Updating the version should be accompanied with some amount of training in the new language structures.

Community
  • 1