[concurrency-interest] Why not J2SE 5?

Dave Dice Dave.Dice@Sun.COM
Mon, 06 Dec 2004 12:11:12 -0500


| 
| 
| I'm starting to wonder why there's so much resistance out 
| there to changing from 1.x to J2SE5 (1.5). Having seen how 
| obsessed the Sun J2SE5 release managers and engineers were 
| with back-compatibility, and the huge numbers of regression 
| tests run, and the very large number of bug-fixes and 
| performance improvements in J2SE5, I honestly don't know of a 
| good technical reason not to switch over to it, even (or
| especially?) if people don't need new functionality. I 
| suppose some of it might be just be fear of any x.0 release 
| (to be addressed soon, I think, with the first "underscore" 
| release, "1.5_01" or somesuch name). And maybe it takes time 
| to install/deploy new JVMs across all machines etc. But is 
| there some more fundamental reason that I'm overlooking?
| 
| -Doug
| 


I think folks on this list have iterated over the major reasons that 1.5
adoption might be a bit slower than we'd prefer.  In particular, Michael
Ogg hit the nail directly on the head with his comments about QA costs.
Say you're in a corporate IT shop.  If the old JVM isn't giving you
problems it's extremely difficult to justify changing JVM versions.
There's risk and considerable QA + deployment expense, so you have to be
able to identify some advantage to using the new JVM.  It's very common
to see enterprise customers lock down on a specific configuration (JVM
version, hardware, OS), put that configuration through rigorous
qualification, and then standardize on the configuration for large
fractions of a decade.  Often, the only thing that'll precipitate a
change is if one of the components slips outside a vendors support
window.  Typically, a corporate-wide hardware upgrade will cause a
shift.  At that point he apps, OS, JVM and hardware will be re-tested
and upgraded in unison.   The upgrade cycles are quite long.  

Like it or not, there are still quite a few 1.2.2s and 1.3.0s out there.


Regards,
Dave