Re: XML parsing with Java

Lew wrote:
Java 1.4 has been completely retired for a few weeks now, and obsolescent for quite some time.

Mike Davis wrote:
Ha! That may be true, but I am now working on a project where that is the only version of the language allowed. We found this out after writing a few thousand lines with generics, enums, and a few other 1.5 features.

At my day job half the Java infrastructure is just coming in to Java 1.4, the other half to 1.5. The problem is widespread.

Arne Vajhøj wrote:
If I were to guess at the Java version usage distribution I would say:

1.2.2 - 5%
1.3.1 - 15%
1.4.2 - 25%
1.5.0 - 35%
1.6.0 - 20%

(please ignore the fact that it is really impossible to quantify
usage in a meaningful way)

I would guess that the usage is higher for 1.4 than your guess, and Java 6 is much lower. But I'm in the position of trying to guess the shape of an elephant knowing only the feel of its ears.

If I had the ears of the decision makers where I work, I'd suggest to them that the risk of continuing with Java 1.4, with its insufficient concurrent memory model and slower performance than modern versions, exceeds that of the conversion to Java 5, especially in our environment which involves multiple nodes with multiple processors running multiple JVMs with various forms of communication between them processing high peak volumes of information per unit of time under tight time constraints and rigorous availability requirements.

Some similarly high-demand production Java code I've seen runs about three times faster under Java 5 and the associated Java EE (J2EE) servers than it did with older platforms. Not just CPU-bound code, but all sorts of different stuff involving messages and files and databases and the like. Obviously Java by itself is only a piece of that improvement - the app-server vendors were busy improving their stuff, too.

The fear of upgrade that I've witnessed was based on considerations of product reliability on a new platform, cost of code conversions (rooting out misuse of the 'enum' keyword and the like), and operations costs associated with migration to and maintenance of the new enterprise platform. Decision makers seemed utterly unimpressed with claims of performance improvement; only risk mattered.

Lately I have been meditating on the balance of risks between those that arise from conversion and those that arise from the failure to convert to Java 5 or later. I posit that risk comparison will carry more meaning to decision makers than benefit comparison.

--
Lew
.

Relevant Pages

  • Re: compare with empty string uses equals method or == ??
    ... > int for a somewhat safe usage, as a compromise in absence of enums. ... Sun Certified Developer for the Java 2 Platform ...
    (comp.lang.java.programmer)
  • Re: Borland and Java obsession.
    ... > don't know what risk is associated with them. ... Our company primarily uses Java for 80% of all Development. ... Our company sees XPlatform applications as the future. ... Integration with Java is available now and is well tested on all of the ...
    (borland.public.delphi.non-technical)
  • Re: Garbled video output after upgrade
    ... BTW Mobo is Lucky Star K7VAT Vers 2.1. ... electrolyte has dried onto the motherboard. ... to be on Risk, and it just effects that, thanks anyway Paul. ... Remove Java from your system and then reinstall it. ...
    (alt.comp.hardware.pc-homebuilt)
  • Re: Joel Spolsky on languages for web programming
    ... Risk Management is about dealing with risk, ... For those of us that know Ruby, the best we can do to spread it is to ... Java shop of doing something in Java may be very low if their staff is ... LISP or whatever language they have the sufficient experience with to ...
    (comp.lang.ruby)
  • Re: jsp can not find date
    ... understanding of this behaviour by predicting personality traits (self ... I am willing to accept this risk every so often, ... Sun Certified Programmer for the Java 2 Platform ... Sun Certified Developer for the Java 2 Platform ...
    (comp.lang.java.help)