On Aug 16, 2005, at 1:58 PM, Mark Womack wrote:
We can make it so that log4j is compatible with 1.2 and happy when
it runs.
Just compile using jdk 1.2 instead of jdk 1.3 or 1.4.
That should be possible, but I suggested using Jikes while producing
the distribution since it seemed to be an adequate and less
complicated solution.
I made attempts to compile under JDK 1.2, but that required
rebuilding Ant 1.6.5 or reverting to an Ant 1.5 that doesn't suffer
(and more significantly) from the same problem, applying the change
to LoggingReceiver to work-around its compiler bug, and assembling
the necessary jar and tweaking the classpath since quite a few of
which have been added to JDK in 1.3 and later and are assumed to be
in the build environment.
I think the messages
we are seeing are related to compiling the release lib with 1.4
instead of
1.2 (or 1.1 in the case of 1.2.12). And they are non-fatal
warnings, not
errors.
I have not seen them result in log4j not properly functioning. But
Ant builds suffering from the same issue are failing to function, so
I think the issue should be addressed.
I have to imagine that compiling with jdk 1.2 (or 1.1) will
generate compatible byte code for that jdk. And it appears that
Ant will
support compiling with different jdk's while itself runs in jdk
1.4. I
don't know if there is any performance penalty for running jdk 1.2
byte code
in 1.3/1.4.
If you feel comfortable configuring Ant to use a classic compiler
while running on a later VM, that would be an option. I'd assume
that you'd be specifying -Dbuild.compiler=classic and need to make
sure that JDK javac was on the path and that tools.jar was not on the
classpath (likely by running under a JRE and not a JDK). However,
switching to an earlier javac seems equivalently disruptive as
switching to jikes.
My understanding is that any performance penalty would be at class
load time and not run-time. If there was a performance penalty, then
the user is free to recompile the jar with whatever compiler they
prefer.
Assuming the above, the question still remains. Is there a compelling
reason to dump jdk 1.2 compatibility besides easing the building
and testing
requirements?
I haven't seen a compelling reason. However, I think the consensus
is that the threshold for abandoning JDK 1.2 compatibility on the 1.3
branch is not high.
Hopefully, not to confound the issue even more, but my expectation is
that when we start the log4j 2.0 branch we'd set the target as JDK
1.5, though possibly provide variants that would run on earlier
JDK's. For example, I'd expect log4j 2.0 to use StringBuilder (non
synchronized equivalent of StringBuffer) in the source code. We
could consider providing alternative builds that would tweak the
source code to use StringBuffer.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
