[concurrency-interest] Why not J2SE 5?
Steven J. Owens
Mon, 6 Dec 2004 14:11:46 -0500
On Mon, Dec 06, 2004 at 12:11:12PM -0500, Dave Dice wrote:
> | I'm starting to wonder why there's so much resistance out
> | there to changing from 1.x to J2SE5 (1.5). [...] I honestly
> | don't know of a good technical reason not to switch over [...]
I can't help but wonder if my post has something to do with this
topic coming up :-).
> 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.
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.
As it is, it's not that I'm resisting upgrading, it's just that
it hasn't percolated through our strategic to-do list yet. We do have
one of our team using tomcat 5.x in his development environment, and
I'd like to get us using JDK 1.5 soon, even though we'll almost
certainly stay inside the JDK 1.4 feature envelope for the foreseeable
future (except, perhaps for the use of concurrency).
There's also the issue of minimizing the variables in each
major change, and since development is an ongoing process...
> 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.
I agree, except for the part about "rigorous qualifications" :-).
I know of a large financial institution that standardized on JDK 1.6
when that was mainstream. They were still using it in 2000. I
believe they're a little bit beyond 1.6 now, but I wouldn't bet money
Large organizations tend to sink a lot of time into risk
brokering strategies. Note, I don't say necessarily risk _avoidance_
strategies :-). As an example, say they need to solve a problem.
Somebody will see that problem as an opportunity (to expand their
kingdom) and will tackle it. But they'll set up a committee, have a
lot of meetings, and get a lot of buy-in from other people at their
level in the organization. This spreads the risk around.
At some point they may decide that it's a technical risk (pretty
much at any point where it becomes apparent that the project isn't a
no-brainer). Then they decide they need to go get an outside
consulting organization, say Sun's consulting arm. This is a great
risk-brokering strategy - not because the consulting team is any less
risky than their own staff, but because the process of bringing the
consulting team in involves a lot of meetings, an approved vendor
list, a lot of higher-level buy-in. In the end, a lot more people are
implicated in the decision - people who might otherwise be the ones
pointing the finger if anything goes wrong.
Worst case scenario, it also gives them a convenient external
target to deflect blame onto, "Hey, I hired Sun consulting guys to do
the java stuff, what more could I do?" (add to which the implied:
After all, you guys approved them as a vendor...)
Now, if this sort of dance goes on at the managerial level, how
readily do you think they'll take major steps at the technical level?
> 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.
Case in point, the financial organization I spoke of above. Most
likely they upgraded when they moved to using EJB servers, which I
think they did in mid-late 2000.
Steven J. Owens
"I'm going to make broad, sweeping generalizations and strong,
declarative statements, because otherwise I'll be here all night and
this document will be four times longer and much less fun to read.
Take it all with a grain of salt." - http://darksleep.com/notablog