Hi Joe,
>Actually, I would be sorta shocked if Java really did optimize away
> if(Version.getVersion().equals("Xerces 2.0.2"))
>... since the compiler has no way of knowing that getVersion(), even
>if it *is* static, does not have side-effects. It may not in the
>current implementation of the Version class, but it might in the next
>release.
Well, the proof is in the pudding. So I wrote up two simple classes--one
with a private static final String member and a static getter; the other
which did the appropriate .equals test. And, at least on the three modern
JDK's I tested (two from I BM, one from Sun) you're proven right: the
check is done at run-time.
Anybody else think of a reason not to make this change? Having the getter
static *does* make sense to me, so long as it'll actually work in all
situations...
>static Version.main(). Presumably, Java compilers are smart enough not >to
try to optimize away _that_ call!
I don't think our Version.main differs from Xalan's too dramatically.
>Oh, THAT's no problem. Xalan itself solved this, quite trivially, when
>we changed our own Version APIs to the new convention: We carried both
>classes, with the old one as a (deprecated) front-end for the new one
>so we didn't have to maintain the data in duplicate...
Is the old one the XSLProcessorVersion class? If so, sure looks like the
new one wraps it--which would seem to make a lot of sense, because then, if
an older Xalan precedes the new on the classpath, the app still gets the
correct (old) version values. Or am I misreading the source?
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]
