> > 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.
The javac tag supports an "executable" attribute that lets you specify a path to the javac to use. Between that and the other attributes, I think we will have enough control to do what we want? I agree that switching to the jdk 1.2 compiler for v1.2.12 at this point will be a disruptive risk, but something we may want to consider and deal with. But for log4j v1.3 we should certainly look at it. > > 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. Agreed, we need to understand it better. > > > > 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. We may have a low threshold, but we are not the primary users of the framework. And abandoning jdk 1.2 for our convenience is not a good reason. I find it incredibly annoying when I go to use a tool or a framework and find that doesn't support the version I am running, or is not compatible with the environment I have, so I have to upgrade, etc. But I am still open to hear a compelling reason to dump jdk 1.2 support. > 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. All bets are off with log4j 2.0. We can make appropriate decisions when we get to that gate. -Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
