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.
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?
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.
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
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.
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.