> and rediscovery of what bugs will be showing up. Where I work, it
> wasn't until last year that public builds of 1.5 were free of
> catastrophic bugs with no workarounds. A 1.6 update will have to wait
> until business is slow.
> >> Even though it is no longer officially supported, JDK/JRE 1.5.0_21 was
> >> just released.
[quoted text clipped - 3 lines]
>
> What code changes?
Primarily, JDBC delegates are not compatible. 1.6 defines new JDBC
methods with return types that don't exist in Java 1.5. Proxies still
work but they're not always appropriate.
> > and rediscovery of what bugs will be showing up. Where I work, it
> > wasn't until last year that public builds of 1.5 were free of
[quoted text clipped - 4 lines]
> be
> slow.
When I say that JVMs have "catastrophic bugs", I really mean
catastrophic. We needed custom builds of 1.5 to avoid a file descriptor
bug that routed data streams completely randomly if Solaris NFS was in
use. Files, JDBC connections, HTTP connections - all mixing together.
And then there have been numerous GC bugs where a collector stops the
JVM for 2 minutes... 5 minutes... 10000 minutes. Even today, Java 1.5
needs lots of -XX options to fix CMS self-tuning bugs.
There is no technical debt when no Java 1.6 features are needed yet.
The update will happen when it's safe for business.

Signature
I will not see your reply if you use Google.
Mike Amling - 14 Sep 2009 03:44 GMT
> When I say that JVMs have "catastrophic bugs", I really mean
> catastrophic. We needed custom builds of 1.5 to avoid a file descriptor
[quoted text clipped - 3 lines]
> JVM for 2 minutes... 5 minutes... 10000 minutes. Even today, Java 1.5
> needs lots of -XX options to fix CMS self-tuning bugs.
Yep. While we don't measure these things ourselves, our releases have
to be able to run on 1.4 because of customer sentiment that 1.4.2 was
the last "stable" release. We only ship code that uses post-1.4 Java
features if it's done via reflection.
--Mike Amling