logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
Date Tue, 16 Aug 2005 20:46:20 GMT

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  

> 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message