You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Boris Unckel <bo...@gmx.net> on 2006/01/19 19:17:44 UTC
[logging] Bug 38174 and JCL 1.1
Hello,
Simon Kitching wrote:
>>> NB: I'm hoping to knock JCL1.1 into releasable state over the coming
>>> weekend and hold a vote on creating the first RC.
>> Please check to put the patch in bug 38174 into RC. Even if you decide
>> against the logic in the new "doLog" methods, it would be nice to have
>> the other cleanup (javadoc, same null behaviour for all classes).
>
> Please check my comments on that bugzilla entry.
>
I have read your comments and opinions in the bugzilla entry[1].
As I do not want to put so much time in a more or less boring task
(improving the JavaDoc and care for doLog single method logic is a lot of
copy and correct paste) I have removed anything of the exception behaviour.
I have also removed the String.valueOf when the underlying logger accepts
objects as message.
Every file has single patch. With accident cause I did an format after
removing the exception handling - sorry for that, it will cause more diff
than is really different.
Please consider again to put this into release.
Thanks!
Regards
Boris
[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=38174
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] Bug 38174 and JCL 1.1
Posted by Simon Kitching <sk...@apache.org>.
I've read through this reference, and it doesn't mention final qualifier
on parameters.
I also *think* this is safe, and that final is just a compile-time
constraint. However I'm not 100% sure, so would prefer to not make that
change here.
Section D.1.2 of this document suggests final is ok, but this info is a
little out-of-date:
http://java.sun.com/docs/books/jls/first_edition/html/1.1Update.html
However in the end, this "final" thing isn't going to improve the
efficiency of the code, and carries a small chance of breaking things so
I'd suggest not applying it.
Regards,
Simon
On Thu, 2006-01-19 at 21:26 +0100, Martin van den Bemt wrote:
> Hi robert,
>
> See 13.4.8 final Fields and Constants at
> http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html
>
> Short answer : yes and no :)
>
> Mvgr,
> Martin
>
> robert burrell donkin wrote:
> >
> > i notice that a lot of the parameters are now declared final (which is -
> > usually - good). i would have expected that this should not effect
> > binary compatibility but unfortunately, i can't find anywhere in the JLS
> > where this is definitely specified. i'm very reluctant to add any
> > changes which risk (at all) binary compatibility issues.
> >
> > anyone know of a definitive reference?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] Bug 38174 and JCL 1.1
Posted by Martin van den Bemt <ml...@mvdb.net>.
The only thing I can think of based on that document that the method signature stays the same and if
the field is incorrecly modified you get the IllegalAccessException.
Although I would definitely test with some tool to make sure :)
Mvgr,
Martin
robert burrell donkin wrote:
> On Thu, 2006-01-19 at 21:26 +0100, Martin van den Bemt wrote:
>
>>Hi robert,
>>
>>See 13.4.8 final Fields and Constants at
>>http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html
>
>
> oops sorry - should have been more specific
>
> i meant parameters (not fields or constants). these are briefly covered
> in 13.4.12.
>
> for example, is changing
>
> public void foo(Bar bar) {...}
>
> to
>
> public void foo(final Bar bar) {...}
>
> a binary-preserving transformation?
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] Bug 38174 and JCL 1.1
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thu, 2006-01-19 at 21:26 +0100, Martin van den Bemt wrote:
> Hi robert,
>
> See 13.4.8 final Fields and Constants at
> http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html
oops sorry - should have been more specific
i meant parameters (not fields or constants). these are briefly covered
in 13.4.12.
for example, is changing
public void foo(Bar bar) {...}
to
public void foo(final Bar bar) {...}
a binary-preserving transformation?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [logging] Bug 38174 and JCL 1.1
Posted by James Carman <ja...@carmanconsulting.com>.
Parameters are neither fields nor constants. There's a section below that
dealing with method/constructor parameters. It doesn't mention anything
about making them final breaking binary compatibility. I would seriously
doubt that it does, especially since it's call by value (value of a
reference or value of a primitive). The only code that can change the value
of the reference (not the object pointed to by the reference) is the code
inside the method (this is all moot for primitive parameters). So, it
should be okay, I would think.
-----Original Message-----
From: Martin van den Bemt [mailto:mllist@mvdb.net]
Sent: Thursday, January 19, 2006 3:26 PM
To: Jakarta Commons Developers List
Subject: Re: [logging] Bug 38174 and JCL 1.1
Hi robert,
See 13.4.8 final Fields and Constants at
http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html
Short answer : yes and no :)
Mvgr,
Martin
robert burrell donkin wrote:
> On Thu, 2006-01-19 at 19:17 +0100, Boris Unckel wrote:
>
>>Hello,
>>
>>Simon Kitching wrote:
>>
>>>>>NB: I'm hoping to knock JCL1.1 into releasable state over the coming
>>>>>weekend and hold a vote on creating the first RC.
>>>>
>>>>Please check to put the patch in bug 38174 into RC. Even if you decide
>>>>against the logic in the new "doLog" methods, it would be nice to have
>>>>the other cleanup (javadoc, same null behaviour for all classes).
>>>
>>>Please check my comments on that bugzilla entry.
>>>
>>
>>I have read your comments and opinions in the bugzilla entry[1].
>>As I do not want to put so much time in a more or less boring task
>>(improving the JavaDoc and care for doLog single method logic is a lot of
>>copy and correct paste) I have removed anything of the exception
behaviour.
>>I have also removed the String.valueOf when the underlying logger accepts
>>objects as message.
>>
>>Every file has single patch. With accident cause I did an format after
>>removing the exception handling - sorry for that, it will cause more diff
>>than is really different.
>>
>>Please consider again to put this into release.
>
>
> i'm going through the patches (by hand) now.
>
> i notice that a lot of the parameters are now declared final (which is -
> usually - good). i would have expected that this should not effect
> binary compatibility but unfortunately, i can't find anywhere in the JLS
> where this is definitely specified. i'm very reluctant to add any
> changes which risk (at all) binary compatibility issues.
>
> anyone know of a definitive reference?
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] Bug 38174 and JCL 1.1
Posted by Martin van den Bemt <ml...@mvdb.net>.
Hi robert,
See 13.4.8 final Fields and Constants at
http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html
Short answer : yes and no :)
Mvgr,
Martin
robert burrell donkin wrote:
> On Thu, 2006-01-19 at 19:17 +0100, Boris Unckel wrote:
>
>>Hello,
>>
>>Simon Kitching wrote:
>>
>>>>>NB: I'm hoping to knock JCL1.1 into releasable state over the coming
>>>>>weekend and hold a vote on creating the first RC.
>>>>
>>>>Please check to put the patch in bug 38174 into RC. Even if you decide
>>>>against the logic in the new "doLog" methods, it would be nice to have
>>>>the other cleanup (javadoc, same null behaviour for all classes).
>>>
>>>Please check my comments on that bugzilla entry.
>>>
>>
>>I have read your comments and opinions in the bugzilla entry[1].
>>As I do not want to put so much time in a more or less boring task
>>(improving the JavaDoc and care for doLog single method logic is a lot of
>>copy and correct paste) I have removed anything of the exception behaviour.
>>I have also removed the String.valueOf when the underlying logger accepts
>>objects as message.
>>
>>Every file has single patch. With accident cause I did an format after
>>removing the exception handling - sorry for that, it will cause more diff
>>than is really different.
>>
>>Please consider again to put this into release.
>
>
> i'm going through the patches (by hand) now.
>
> i notice that a lot of the parameters are now declared final (which is -
> usually - good). i would have expected that this should not effect
> binary compatibility but unfortunately, i can't find anywhere in the JLS
> where this is definitely specified. i'm very reluctant to add any
> changes which risk (at all) binary compatibility issues.
>
> anyone know of a definitive reference?
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] Bug 38174 and JCL 1.1
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thu, 2006-01-19 at 20:23 +0000, robert burrell donkin wrote:
> On Thu, 2006-01-19 at 19:17 +0100, Boris Unckel wrote:
> > Hello,
> >
> > Simon Kitching wrote:
> > >>> NB: I'm hoping to knock JCL1.1 into releasable state over the coming
> > >>> weekend and hold a vote on creating the first RC.
> > >> Please check to put the patch in bug 38174 into RC. Even if you decide
> > >> against the logic in the new "doLog" methods, it would be nice to have
> > >> the other cleanup (javadoc, same null behaviour for all classes).
> > >
> > > Please check my comments on that bugzilla entry.
> > >
> >
> > I have read your comments and opinions in the bugzilla entry[1].
> > As I do not want to put so much time in a more or less boring task
> > (improving the JavaDoc and care for doLog single method logic is a lot of
> > copy and correct paste) I have removed anything of the exception behaviour.
> > I have also removed the String.valueOf when the underlying logger accepts
> > objects as message.
> >
> > Every file has single patch. With accident cause I did an format after
> > removing the exception handling - sorry for that, it will cause more diff
> > than is really different.
> >
> > Please consider again to put this into release.
>
> i'm going through the patches (by hand) now.
i've applied the javadoc changes. i may review the other bits later (if
time allows) but that's about it for me for tonight. i'm unlikely to be
online tomorrow. i plan to try to write some documentation on saturday.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [logging] Bug 38174 and JCL 1.1
Posted by James Carman <ja...@carmanconsulting.com>.
http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html
-----Original Message-----
From: robert burrell donkin [mailto:robertburrelldonkin@blueyonder.co.uk]
Sent: Thursday, January 19, 2006 3:23 PM
To: Jakarta Commons Developers List
Subject: Re: [logging] Bug 38174 and JCL 1.1
On Thu, 2006-01-19 at 19:17 +0100, Boris Unckel wrote:
> Hello,
>
> Simon Kitching wrote:
> >>> NB: I'm hoping to knock JCL1.1 into releasable state over the coming
> >>> weekend and hold a vote on creating the first RC.
> >> Please check to put the patch in bug 38174 into RC. Even if you decide
> >> against the logic in the new "doLog" methods, it would be nice to have
> >> the other cleanup (javadoc, same null behaviour for all classes).
> >
> > Please check my comments on that bugzilla entry.
> >
>
> I have read your comments and opinions in the bugzilla entry[1].
> As I do not want to put so much time in a more or less boring task
> (improving the JavaDoc and care for doLog single method logic is a lot of
> copy and correct paste) I have removed anything of the exception
behaviour.
> I have also removed the String.valueOf when the underlying logger accepts
> objects as message.
>
> Every file has single patch. With accident cause I did an format after
> removing the exception handling - sorry for that, it will cause more diff
> than is really different.
>
> Please consider again to put this into release.
i'm going through the patches (by hand) now.
i notice that a lot of the parameters are now declared final (which is -
usually - good). i would have expected that this should not effect
binary compatibility but unfortunately, i can't find anywhere in the JLS
where this is definitely specified. i'm very reluctant to add any
changes which risk (at all) binary compatibility issues.
anyone know of a definitive reference?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] Bug 38174 and JCL 1.1
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thu, 2006-01-19 at 19:17 +0100, Boris Unckel wrote:
> Hello,
>
> Simon Kitching wrote:
> >>> NB: I'm hoping to knock JCL1.1 into releasable state over the coming
> >>> weekend and hold a vote on creating the first RC.
> >> Please check to put the patch in bug 38174 into RC. Even if you decide
> >> against the logic in the new "doLog" methods, it would be nice to have
> >> the other cleanup (javadoc, same null behaviour for all classes).
> >
> > Please check my comments on that bugzilla entry.
> >
>
> I have read your comments and opinions in the bugzilla entry[1].
> As I do not want to put so much time in a more or less boring task
> (improving the JavaDoc and care for doLog single method logic is a lot of
> copy and correct paste) I have removed anything of the exception behaviour.
> I have also removed the String.valueOf when the underlying logger accepts
> objects as message.
>
> Every file has single patch. With accident cause I did an format after
> removing the exception handling - sorry for that, it will cause more diff
> than is really different.
>
> Please consider again to put this into release.
i'm going through the patches (by hand) now.
i notice that a lot of the parameters are now declared final (which is -
usually - good). i would have expected that this should not effect
binary compatibility but unfortunately, i can't find anywhere in the JLS
where this is definitely specified. i'm very reluctant to add any
changes which risk (at all) binary compatibility issues.
anyone know of a definitive reference?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org