Should you install the new version of Java?

Sun Microsystems released a new version of Java for Windows, Linux and Solaris a few days ago. Should you rush out to install it? Probably not.

First a bit of level-setting. Version numbers are an ongoing annoyance with Java, and this latest go-round is no different. The new release is identified with six names:

• 1.6.0_10 (from the Java runtime)
• Update 10 of Java Standard Edition 6
• Java (TM) 6 Update 10 (in the Add or Remove Programs thingy in the Control Panel)
• Java SE 6u10
• 6.0.100.33 (by the Secunia scanner)
• 1.6.0_10-b33 (a property of the java.exe file)

New software typically has both new features and bug fixes, but this release of Java only has new features. Sun's release notes say "this feature release does not contain any new fixes for security vulnerabilities to its previous release, Java SE 6 Update 7. Users who have Java SE 6 Update 7 have the latest security fixes and do not need to upgrade to this release to be current on security fixes."

From what I've read, this appears to be a pretty big release. There are many new features including some affecting the core of the product. New features inevitably mean new bugs, thus the safer approach is wait. Anyone currently running the previous version of Java (1.6.0_7) is therefore best off doing nothing. To see which version, if any, you have installed simply visit Javatester.org.

If, however, you have an older version of Java installed, then you should update it to 1.6.0_7 (a.k.a. Java 6 Update 7). You can download the older version of Java at java.sun.com/products/archive/j2se/6u7/index.html. Click on the "Download JRE" link.*

If and when the time comes that you need one of the new Java features, that's the time to upgrade. Chances are, that by that time, the new features may have had a bug or two fixed.

One exception, is anyone using Google's Chrome browser, which requires the latest version (1.6.0_10) of Java.

Mac users don't have a decision, there is no new release of Java for OS X. For whatever reason, Sun--the company that developed Java--does not supply it for Macs. But Apple does, and Apple is always behind the curve in terms of new releases.

To take a step back, do you need Java at all? If for nothing else, Java is required for the Secunia Online Software Inspector, which I wrote about two days ago.

*Here is an alternate link directly to the EXE file for Windows users. This should download file jre-6u7-windows-i586-p.exe, which is about 15MB. Surprisingly, CNET's own Download.com is a bit behind on Java releases.

See a summary of all my Defensive Computing postings.

[thammr]

Until SUN fix the extremely SERIOUS bug with JFileChooser and Java 1.6, I won't be using 1.6 ever!!!!

[Ilgaz]

I hope one day, CNET writes similar stuff about MS Windows non security updates like "DotNet 3.5 shipped, should you update" or "Silverlight 2 shipped, should you care?"

If it includes no security or critical bug fixes, it must contain speed optimisations which is definitely needed for Java.

The reason Sun doesn't code Java for OS X is clear: they don't have access to Aqua/Cocoa internals and Apple hates Java for some mystical reason. Also Apple fans should save typing about "But Webobjects is Java". Webobjects was ALWAYS Java and it is a server component.

[Gundamdriver]

"...The reason Sun doesn't code Java for OS X is clear: they don't have access to Aqua/Cocoa internals and Apple hates Java for some mystical reason..."

And people using Tiger is still "hoping" for Java 6 from Apple. Apple simply ignore the need of its customers. Don't tell the customers to upgrade to Leopard, as this doesn't happen in Windows/ Linux.

[Ilgaz]

Gundamdriver, even if you have upgraded to Leopard you won't have Java 6 if you got PowerPC. You possibly know it already, saying for others.
Funny thing, it seems Windows is currently the best platform for end user Java both in performance and ease of install/use.

[gggg sssss]

iigaz
Windows is teh best platform. Period. Thanks for indicating that.

[john55440]

I still have Java Version: 1.1.4 from Microsoft Corp. Is there anything wrong/bad/inferior with that version, compared to Sun's version(s).

[sanjayb]

Just about everything.

[Ilgaz]

You better install Sun Java even if you don't have anything in Java or don't even know what Java is.
If anything hits that Microsoft Java, you will be in trouble.
It should be single click install from http://www.java.com and it is not big either. The idea is taking over the outdated Java of yours since you won't be able to uninstall it easily.

[MSSlayer]

Given that version 5 and 6 have new features that the older JVM won't be able to run, yes.

MS's JVM has always sucked hard.

[paulej]

I've never been a Java fan. I've just never felt compelled to write software with all of the hype that one can write it once and run it everywhre, nor do I subscribe to the notion that I need a garbage collector to save me from programming mistakes. I have a certain appreciation for the ideal of writing once and running anywhere, but that just does not happen. As much as Java tries, it cannot succeed at realizing that dream.

Further, why should developers care to write code in a virtual machine that runs any application more slowly? Is writing native code suddenly so difficult? And people cannot keep up with memory they allocate? (Yeah, I've heard arguments that Java is not that much slower. And I had one software make suggest that a 20% performance hit was not a big deal. But, I sure can see the difference in most native vs non-native applications.)

And, as highlighted by other posters, Java has problems. I made the mistake of installing the latest Java code, but was forced to go back to an older release do to incompatibility with the *one* application on my machine. So, Java has a 100% incompatibility rate on my machine. ;-) (OK, that's not fair... but it is true.)

Why do we not just spend out energy writing efficient native applications on Windows, Mac, and Linux? Why is the world so obcessed with writing code in Java? Performance loss, failed promised of write-once/run anywhere, and garbage collection that runs at the wrong time does not sound like the ideal platform to me.

[abendanan]

To paulej:
Don?t forget that the WEB exist. You can have a lot of clients that run within different platforms and writing your applications with this language can let then run it without any other support.
Regarding to the garbage collector, it has been improved a lot. If you need to control when it will be launched, I can assume that you are programming *real time* software. In this case, you should use some well known design patterns that for example allocate ALL your needed objects at initialization time and do NOT deallocate them during the exploitation. The GC will not be used.

[MSSlayer]

The difference between runtime speed between the JVM and native code is nearly non-existent these days.

The term speed is also abused alot, as you are doing it. Most applications 20% is 10-20 ms, very few apps would be damaged with that much of a slowdown.

[Frustrated_Unix_User]

Hmm. I would say that the biggest bug in Java is the fact that it does not really support
Unix pipes.

Furthermore, it is almost axiomatic that whenever I encounter Java software that I want to
run, it is always requires that I have to upgrade my version of Java.

Finally, if Java is so good, then why does the heavy computational lifting have to be done
with mixed language programming employing C or C++ code?

For those in the know, what is the "next big thing"? Java isn't the final answer, or we wouldn't
need mixed language programming, now would we?

[aguizar]

Frustrated Unix user, you seem to be stuck in the JDK 1.0-1.1 days, before just-in-time compilers were introduced. Nowadays native code is limited to interfacing with OS libraries and/or hardware not available from the standard APIs.

The overhead associated with calling native code may actually cause it to perform worse than the equivalent Java code. The subversion client adapter alternatives are a concrete example. The following quote was taken from http://subclipse.tigris.org/. Note that subversion is written in C.

"Subclipse requires a Subversion client "adapter" to communicate with your repository. Subclipse includes a 100% pure Java client adapter named SVNKit. [...] Subclipse also includes the Subversion JavaHL library which communicates with your repository using the standard Subversion libraries and API.

[...] SVNKit offers a few additional features to Subclipse users that JavaHL does not offer, and it probably performs slightly faster than JavaHL".