At 02:50 AM 6/18/2005, Simon Kitching wrote:
>
> No doubt that you are right but I wonder how you reached this conclusion?
> The java.lang.VerifyError
> is so cryptic. Which version of the JDK are you using?
The output is the same on JDK 1.3 and JDK 1.5. I wrote a trivial test
program that just called logger.log(FQCN, Level.DEBUG, message, null)
then ran "javap -c ..."; the bytecode output clearly shows which method
has been bound to.
Thanks Simon. That's a useful technique to put in the bag of tricks to
know.
Well, this patch *does* allow code compiled against 1.3 to run against
1.2. But it does it via a rather dodgy assumption: that the compiler
won't try to check
getLogger().log(FQCN, (Priority) Level.DEBUG, message, t );
at compile-time. Casting a constant to a specific type is certainly
something that *could* be done at compile time, and would report an
error. I wouldn't be at all surprised to see future versions of javac do
this check. And I bet this code wouldn't compile with gcj. NB: Of course
the check has to be done at runtime too, for typesafety but that doesn't
mean the compiler won't do it at compiletime too.
Excellent point. I was not aware of it.
And it's moot anyway as JCL can't make an official release based upon
compiling against log4j-1.3 alpha code.
Well, we can expect the code to run fine in both versions of log4j, so
your position may be a little too categoric. I am not sure there is a
better alternative, but again, it's your decision ultimately.
If log4j1.3 really is going to be binary-incompatible against log4j1.2
(ie we can't release one Log4JLogger class compiled against 1.2 that
will work against 1.3) then I would probably recommend that we split
Log4JLogger into two parts: Log4J12Logger and Log4J13Logger. The former
would be compiled against log4j-1.2 and the latter against log4j-1.3
alpha code. That's a weird distortion of our build process though;
normally a build for any project is done against one consistent
classpath.
And releasing code compiled against an alpha release isn't very nice. It
would be very embarrassing if log4j then changed API before an official
1.3 release which broke the logger in JCL.
I see your point. Assuming everyone involved in log4j is cognizant of
this problem, I think you can expect current arrangement of Logger,
Category, Level etc. to persist through until 1.3 final.
You may want to ask for a pledge from the group which I would expect
to be granted as well as honored in the future.
The alternative would be to not bundle support for 1.3 in the next
release, and release log4j 1.3 support as a JCL "add-on" available as a
separate download once log4j 1.3 is released.
Is that better than the current status where we are at least assured
to have runtime compatibility?
Are you really sure you want to break binary compatibility between 1.2
and 1.3??
Breaking compile-time compatibility at this core level was not
intentional, that much should be obvious, at least I would hope so.
Moreover, I still consider runtime compatibility to be valuable,
something not to be hastily discarded.
Regards,
Simon
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
