[concurrency-interest] Why not J2SE 5?

Osvaldo Pinali Doederlein osvaldo@visionnaire.com.br
Mon, 06 Dec 2004 12:51:08 -0300

Hi Doug,

Doug Lea wrote:
> 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?

I have already moved to 5.0 in two production apps and it's better than
any previous runtime in every way -- performance, stability, management
-- even before using any new API or language improvement. Kudos to Sun.
Nevertheless, I can't yet depend on J2SE5 for most of my work because:

1) J2EE platform support:  I have clients using servers like WebSphere,
which ships its own JRE which is still prehistoric (J2SE 1.3), and it's
not a old version of WAS.  IBM supports 1.4 only in their very latest
WAS (6.0 -- just released AFAIK), and while I guess I could configure
WAS5 to run on IBM JDK 1.4.2, there's 0,00% chance that I would have
the sysadmins allowing any update that's not an official WAS PTF.

2) Branching: Even in newer projects or projects with "softer" infra-
structure management in the client's network (a.k.a. "I telnet to their
server and install whatever I want" -- my favourite conditions !!!),
I often avoid new APIs because most code going to one client is shared
due to forking from a single application that's customized for several
clients, or reusable components that are used in independent projects.
Using new stuff that cannot be merged back to the root code and then
to other branches would increase a lot my maintenance overheads wrt
bugfixes, etc. (we are a small ISV, and every man-hour of work that's
not explicitly planned and paid by some client, is a problem).

3) Most people are not technologists that track Java closely.  The J2SE
platform does have some history of bad "dot-zero" releases.  Not too far
in the past, J2SE 1.4.0 had a lot of problems not only in new APIs (like
the barely-usable java.nio) but also existing APIs: Swing's new focus
subsystem broke code for most people doing complex focus programming.
We could argue that some of that code worked on 1.3.x out of sheer luck
-- relying on unspecified behaviors, side effects of bugs, or using ugly
workarounds for previously-missing functionality.  But these excuses are
"academic" for developers, users and managers hit by incompatibilities.
Fortunately, Sun's Q&A processes improved by leaps and bounds since 2001
and I no longer fear regressions or even big problems in all-new APIs.
But J2SE 5.0 is too recent, it's the very first Major Release achieving
such very high standards of backwards compatibility and robustness, and
it may take another major release or two with the same quality until
most people start trusting major updates.

4) In Tiger, the presence of extensive new language syntax features
makes this update suspicious for many developers.  It's common that
developers equate the language with the system's internals, and big
changes in the language should require big changes in the compilers
and other rocket-science components, right?  This is the rule for C++
and other traditional languages, but it's different in Java, where
javac is litte more than a parser, and the interesting and dangerous
work is performed by the VM (JIT compiler, GC, etc.).  Unfortunately,
it's not good marketing to describe all the language improvements as
"cosmetic -- nothing changed under the hood" so people feel safer.
This trend is made stronger in Java due to excessive conservadorism
in the past: Java, the language, is 99% unchanged from 1.0 to 1.4.2.
Once again, it may take another release or two, with significant
language improvements, to educate many developers to the fact that
evolving the language is reasonably safe in Java... and notice that
it's not perfectly safe, see the curious bug with ternary operator
(?:) and final fields, in J2SE 5.0's javac.  This bug is minimal in
proportion to the javac changes for 5.0, and there were much worse
javac bugs in past releases *without* language changes, but still,
the general perception is that changing the language is dangerous.

Finally, all these reasons are very often masking laziness -- there's
a huge number of Java developers who haven't yet found enough time to
master the new language features, let alone new APIs.  So they say to
themselves that Tiger is still too new and it should be buggy... ;)


Osvaldo Pinali Doederlein                   Visionnaire Informática S/A
osvaldo@visionnaire.com.br                http://www.visionnaire.com.br
Arquiteto de Tecnologia                          +55 (41) 337-1000 #223