Take the 2-minute tour ×

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?

share|improve this question
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
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
add comment

2 Answers

up vote 10 down vote accepted

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.

share|improve this answer
add comment

With Viruses like the Ransom Virus out there it's probably best to use the newest patched versions of Java whenever possible... and if it requires that your users update to the newest versions to use your product, all the better because then you are also helping to protect them.

share|improve this answer
Not all instances of Java are ones that are susceptible to browser launched vectors. Many times when there is a "production enviroment" for java, this is something like JBoss running Java EE to which the virus has no vector. –  MichaelT Jan 17 '13 at 23:27
true... but the question didn't specify what environment they were developing for... so my answer still has a good point about the users of the finished product, or if they're developing for the web it's very important to be updated. I really don't think my answer 'wasn't useful' considering these questions and answers aren't supposed to be too 'localized'... –  krazykat1980 Jan 17 '13 at 23:43
Recently the news report said there was a security problem with Java 7 and users should temporary remove it. –  linquize Jan 18 '13 at 6:51
That was probably when the ransom virus popped up, which I believe they have a patch for... the ransom virus is bad enough that supposedly Apple remotely turned off Java on all Macs... but I'm pretty sure I read that Oracle had released a patch for it. And older Java versions have security holes too, in fact it was recommended to turn off Java no matter what version it was (If you are talking about the Ransom virus from a few days ago) –  krazykat1980 Jan 18 '13 at 7:01
@linquize: a) OP is almost surely not talking about running Java inside a browser b) In any case, that's not relevant here, but it was quickly patched. Windows has vulnerabilities too but is quickly patched. –  smci May 14 at 18:23
add comment

Your Answer


