Hi all,
Hopefully, folks will remember to a couple of weeks back when I articulated
the need for Xerces to take heed of "static mutability" issues, since we're
being deployed in platforms where that's a significant issue. At the time,
one of the contentious points was how to handle the
org.apache.xerces.impl.Version#fVersion String, which has had the audacity
to be public, static and non-final for a very long time.
We can't make it private because suddenly that would break many people's
code; can't make it final because then version checks would get done at
compile-time--quite a bad time for a run-time-version check to be made.
The best solution I can think of is to add a getVersion(): String method
to this class, and strongly urge people to begin using this. We can
guarantee that this is statically immutable, and if people write their code
like this
try {
xercesVersion = org.apache.xerces.impl.Version.getVersion();
} catch (NoSuchMethodError n) {
// ancient Xerces2 is first on classpath!
xercesVersion = org.apache.xerces.impl.Version.fVersion;
}
then their code should work irrespective of the ordering of Xerces2's on
the classpath.
What do people think? Is this even a really big problem? I haven't heard
too much of an outcry yet about the fact that, given both on a classpath,
there really isn't an obvious way to determine whether Xerces1 or Xerces2
is first, given the incompatible packagings of their Version classes...
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]
