Wasn't intentional, but I don't think we need to change it (at
least at the moment).
The LoggingEvent methods (getProperties, getPropertyKeySet) copied
over from log4j 1.3 already used Map and Set, so it would not be
possible to compile on JDK 1.1 without changing the return types,
but the 1.1 and 1.2 javac's haven't been able to compile log4j for
a long time due to compiler bugs. I don't think that you'd get a
ClassNotFoundException unless you called one of these methods and
they aren't used internally within log4j 1.2, so it should not
affect any hypothetical JDK 1.1 user.
It does look like the new implementation of AsyncAppender (since
1.2.14) uses ArrayList and HashMap in its implementation would not
work on JDK 1.1 where the older implementation might have. Nobody
has reported it. The JDK 1.2 classes could be replaced with JDK
1.1 equivalents without changing the signature.
The only viable JDK 1.1 compatible environment is Microsoft Visual
J# and maybe it would be good to see where we are with that. I'd
suspect that you'd have to stub a lot of things out since I'm
guessing that javamail, JMS and the like aren't available for
Visual J#. If you were using Visual J#, you could use log4net.
I'm honestly open to having 1.2.14+ require JDK 1.2 and above. As
long as we are open about it in the release notes. There are
previous releases, just as stable and useful (geez, I was using 1.2.8
for absolutely years without ever needing to upgrade). Anyone who is
stuck in JDK1.1 land has far bigger issues than log4j I'd imagine...
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
