Sun releases a major Java runtime and SDK update - Java SE 6 Update 10

Tony Austin
Wednesday, 29 October 2008 10:03

Opinion and Analysis

After extensive beta testing, Sun Microsystems has released update 10 of its Java Platform Standard Edition 6, with many significant enhancements. Will this lead to a resurgence of Java applications on the desktop and the Web?

On 21 October 2008, Sun Microsystems released update 10 of its Java Platform Standard Edition 6, usually abbreviated to Java SE 6u10 or (using the internal version number for this update) release 1.6.0_10 build 33.

It might look like another minor Java update, but its much more than that.

Wikipedia has a handy Java version history, if you'd like to see what went before.

I attended the Australian leg of the first-ever Java world tour in Sydney, in 1996, about a year after Java was first announced. Since then, I've been following Sun and Java closely enough to understand pretty well what's being going on, as a dilettante rather than a full-time Java practitioner. I've dabbled with Java coding on IBM WebSphere and Lotus Domino server, for example.

That 1996 tour was sponsored by Sun, IBM, and Netscape (remember them?). As you'd expect, they were predicting that Java would "take over the world" as an application platform, but that's not quite what happened!

One big problem was the shenanigans by Microsoft who feared the effect that OS-agnostic Java might have on its Windows franchise and refused to play ball in terms of Java Virtual Machine support under Windows.

This led Sun to accuse them of trying to split the Java community and thus kill off Java. You'll get the gist of what happened from this 1998 article: "Microsoft's holy war on Java." My gosh, that does now seem such a long time ago.

Apart from the skirmishes with Microsoft, a few other issues bubbled to the surface and led to a decrease in the popularity of Java for developing and implementing desktop applications.

Firstly, there was a performance problem with initial earlier JREs (Java runtime environments). Earlier JVMs (Java virtual machines) tended to be slow because they used interpreted rather than compiled bytecodes. Java applications tended to be sluggish compared with those natively compiled (for example, from C or C++ languages).

PLEASE READ ON...