• Rohan (unregistered)

    Wish I was a consultant...

  • skicow (unregistered)

    I love how the variable VERSION contains the string "version".

  • Stephen (unregistered)

    The only thing I can really say for this one is:

    private static WOW = "wow";
    <snip>
    System.WriteLn(WOW);

    I guess that I am just shocked and amazed thsat some could be oblivious to the world. It is like he lived in some kind of cave or something. Maybe he's a PHB in disguise?

  • Stephen (unregistered)

    Ermm... Yea ignore my syntax errors :/

  • Ovidiu (unregistered)

    Hey, at least the guy almost has versioning support built-in :)

  • Jeff (unregistered)

    private static final char Q_MARK = "?";

    I've heard the language committies are considering changing the question mark to &#8225;
    so we better start coding around that.

  • Jeff (unregistered)

    Well, that didn't work.

  • Johnie (unregistered)

    I'm just waiting for one that goes:
    private static final char a = 'a';

    private static final char b = 'b';

    private static final char c = 'c';

    private static final char d = 'd';

    private static final char e = 'e';

    ...

    System.out.println(h+e+l+l+o+comman+space+w+o+r+l+d);

  • Andrew (unregistered)

    I like the way he couldnt spell "APOSTROPHE"

  • The Wolf (unregistered)

    Thats just sad?

  • Jannik Anker (unregistered)

    Hehe. Apostrope. Wazzah?

  • linuxfood (unregistered)

    I'm in awe of this guy...

    I'm not sure if I should feel scared or just laugh my ass off or both.

  • TheF0o1 (unregistered)

    To be fair, JAXP was only added as a standard part of the Java platform in J2SE version 1.4.0, just a few years ago. I'd like to know how long ago this code was written. I've seen consultants that have a library of old code that they reuse on different projects.

  • Jeff (unregistered)

    I thought a bracket was [ or ] .... what does he call those characters when he needs them?

  • Artik (unregistered)

    It's mnot a pelling mistake, i suspect the code comes from a french company

  • J Q Random (unregistered)

    Except "apostrophe" in French is "apostrophe".

  • Hassan Voyeau (unregistered)

    This code is absolute rubbish, and I can see no way to defend it...

  • Chris Capel (unregistered)

    A theme I've seen come up pretty often (like, twice?) in this blog is defining symbolic constants for literal constants that will not change anytime before armageddon. I don't see how anyone would get the idea that this is a good thing, except if they're paid by code volume and unscruplous. Any ideas?

  • Toni Kingo (unregistered)

    But - does Java actually support XML ?

  • Hassan Voyeau (unregistered)

    Of course it does -- http://java.sun.com/xml/

  • cablito (unregistered)

    whats wrong with writting portable code?

  • Chris Capel (unregistered)

    What's not portable about buffer.append("<?xml version=&quot;1.0&quot;?>"); ?

  • Tuck (unregistered)

    As a rule of thumb, you shouldn't have numeric constants in code (other than loop indices). I think this is an example of extending that rule to string and character constants.

  • Johannes Faustus (unregistered)

    I hate to say it, but there is some (perhaps minor) justification in Java to this bizarre-looking approach. It's not a perfect coding example -- but how often do we see those?


    (1) Java, King of String

    Java has a fairly unusual approach to building strings, at least for those who code in C or C++. When you concatenate, say, a "" to the end of the Java string str1 (quoting from Sun):

    Java strings are immutable, they don't change after they're created. What actually happens is that:

    A StringBuffer is set up

    str1 is copied to it

    The "    " is appended to the buffer

    The result is converted to a string

    The str1 reference is made to point at that string.

    The old string that str1 previously referenced is then made available for garbage collection.



    (2) Premature Optimization, Bane of the Young

    It's widely known that impressive performance problems in stock Java code come from string concatenation. In fact, in my tattered old copy of Dov Bulka's "Java Performance and Scalability, Volume 1", the very first optimization (pages 1 - 6) is the use of a string buffer instead of a "destination string" when building a longer string from component strings. There's a very impressive "before and after" performance bar graph, with the "before" bar reaching the top of the printed page and "after" being a thin horizontal line beside it - representing 2200 milliseconds for a naive string-to-string concatenation versus 8 milliseconds for the same operation using a string buffer.

    As a result, receptive young Java programmers are themselves programmed to avoid string concatenation at any cost. Their little buttocks are peppered with spanks if they concatenate more than (say) two strings together. So the spectacle in this example is far from rare.



    (3) We're Recycling to Reduce Our Re-Use

    Many of us would defend the use of constants rather than literals in places where the literal values might change over time. The example code we're excoriating is a bit extreme, but represents a form of good style -- as indicated by this entry from the New Hacker's Dictionary:

    "magic number": In source code, some non-obvious constant whose value is significant to the operation of a program and that is inserted inconspicuously in-line (hardcoded), rather than expanded in by a symbol set by a commented #define. Magic numbers in this sense are bad style.

    And we have to recommend the writer's close attention to constant naming as recommended in "The Elements of Java Style":

    [Dictum] 31: Use uppercase letters for each word and separate each pair of words with an underscore when naming constants.


    However, we must wonder whether there's a little featherbedding going on. Constants - even long lists of obvious constants like we see here - are valuable if they can be used and reused throughout a system. If tomorrow the W3C changes the format of XML such that LEFT_BRACKET becomes, say, "[", an application using the writer's string constants would be easily updated. However, that can't work when the constants are hidden and private, as they are defined here. We can just imagine, scattered through this application, little private islands of single-use string constants bulking up the line count.



    (4) Diagnosis

    It looks like this writer adheres to the letter of the Java law, but has some problems stringing those letters together to make good sense.



    "If you want truly to understand something, try to change it." Kurt Lewin

  • Joe User (unregistered)

    Enterprise beans are a laugh.

  • Matt (unregistered)

    Also, shouldn't he be using single quotes on his chars?
    private static final char LEFT_BRACKET = '<';
    // not ("<")

    Wouldn't you get:
    Type mismatch: cannot convert from String to char

  • Hassan Voyeau (unregistered)

    Matt, you are indeed correct, String and char are incompatible types for the assignment operator, and to the best of my knowledge, Java does not have operator overloading. Maybe this programmer is using a preprocessor.

  • Cheli (unregistered)

    I used to work in a Cold Fusion shop (am I allowed to post here?) and observed this little gem of css workaround:

    <cfscript>
    font = structNew();
    font.black = "black";
    font.white = "white";
    font.etc = "what a blow hole";
    </cfscript>

    ....

    <font color="<cfoutput>#font.black#</cfoutput>">

  • Magnus (unregistered)

    Could this be a case of imitating the spec a bit too closely? It kind of resembles http://w3.org/TR/2004/REC-xml-20040204/#sec-prolog-dtd in a perverse way.

  • andrzej (unregistered)

    Hillarious...but one of the respondent's comments about using symbolic constants does make sense many times, albeit not in this example.

    It can be very useful to localize constant values that might be used in more than one location in the code later one. Say things like initial buffer sizes, attribute names that need to be located, etc. That way if the value ever changes in the future, you just change it in one place.

    Mind you, if you expect the change to happen, then making it a property or some such from a config file may make more sense. Using the constant only makes sense if you don't expect the value to change.

  • Someone who knows (unregistered)

    That's Accenture code, I guarantee it. They ship us crap like this all the time.

Leave a comment on “If only Java supported XML ...”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article