[concurrency-interest] Why not J2SE 5?

Ron Bense eqmel@comcast.net
Tue, 14 Dec 2004 18:33:50 -0600


<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Steven J. Owens wrote:
<blockquote cite="mid20041214075548.GB3435@darksleep.com" type="cite">
  <pre wrap=""> </pre>
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
     Yup, the old "if it ain't broke, don't fix it" argument.  In my
case it's a little easier in some ways - I'm the top technical guy at
our small software company (8 people, 4 of them technical).  So the
decision is pretty much in my lap.  On the other hand, we have a tiny
staff and we only have so much time to go around.  If I could wave my
magic wand and have us running on JDK 1.5 and tomcat 5.x and *know*,
know with the same certainty we have from running our app in
production use on JDK 1.4 and tomcat 4.3x for eighteen months, that
it'll all work smoothly, we would.
  </pre>
</blockquote>
I'll add to the old "if it ain't broke, don't fix it" argument. There
may be something broken, and there may be a work around, so it's not a
major push although it's a performance hit. <br>
<br>
However, when your main product, say an appserver, doesn't migrate
until much much later, and you use a lot of parts of that appservers
proprietary services (old system) and it takes you almost a year to
migrate your current code base to the new version of the appserver...
you'll be happy just running 1.4.x now, as just happened at my
workplace - we migrated to 1.4.x just a couple of months ago, and it
was rather painful. <br>
<br>
It's not a perfect scenario, but the current solution works and drives
significant business, so there's lots of risk involved in upgrades, and
they're done very slowly. Part of that risk involves the work of
outside consultants who tied things together that maybe shouldn't have
been tied. Other risks are driven by that pre-mentioned proprietary
services (we all know how well those migrate within a single vendors
upgrades....) <br>
<br>
Anyways, when you're wondering about the "resistance" of migration,
rest assured that people like me would love to develop on the new JVM,
but reality puts a major brake on our desires. This leaves those of us
in my situation to tinker with it off-hours, which is a slow-go at best.<br>
<br>
Ron<br>
<br>
</body>
</html>