Hi Andy,
Well, I never thought anyone would wade through that long message and
actually look at what I was proposing. (Shucks. :-))
>fVersion final.
Here is one case (there may be others) where we CANNOT
>make this field "final". This field was final to begin
with but then >there was a problem reported by users --
IBMers, in fact.
Here's the >deal: the users in question have code that
relies on the version >information found in the Version
class. So they have code something like >this:
if (Version.fVersion.equals("2.0.1")) { ... }
However, if the >fVersion field is made final, the Java
compiler adds the constant >directly to the compiled
class. Therefore, the comparison is always made >against
the constant value at the time of compilation and not
the value >in the Version class class loaded at runtime.
See the problem?
Not really. :-) This looks like almost the canonical case for why final
is useful to me... Were they modifying this field? Because the only time
the field's value without final would be different than in the compiled
class would be if somebody changed it; and if somebody can change it then
they can potentially step on other people.
The only reason I can see of changing this field's value would be to detect
whether you're using some modified version of Xerces. But if one's already
modifying Xerces, surely this wouldn't be too much of an added
encumbrance.
Can you recall any more details?
Cheers!
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
