On 11/18/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:
On 11/18/06, Joachim Draeger <[EMAIL PROTECTED]> wrote:
> Am Samstag, den 18.11.2006, 08:53 + schrieb robert burrell donkin:
>
> > > Imho it is really interesting to see that in jdk 1.5 the string
> > > concatenation is replaced by
On 11/18/06, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Samstag, den 18.11.2006, 08:53 + schrieb robert burrell donkin:
> > Imho it is really interesting to see that in jdk 1.5 the string
> > concatenation is replaced by StringBuilder by default and this way is
> > even better than using
Noel J. Bergman wrote:
Stefano Bagnara wrote:
I think we should wait to refactor this component until we'll switch to
java 5 as the required jvm so we can introduce a Logger interface with
the mixin's methods we need.
Can you illustrate the pattern you have in mind for such a future approach
Stefano Bagnara wrote:
> I think we should wait to refactor this component until we'll switch to
> java 5 as the required jvm so we can introduce a Logger interface with
> the mixin's methods we need.
Can you illustrate the pattern you have in mind for such a future approach?
--- Noel
Am Samstag, den 18.11.2006, 08:53 + schrieb robert burrell donkin:
> > Imho it is really interesting to see that in jdk 1.5 the string
> > concatenation is replaced by StringBuilder by default and this way is
> > even better than using the StringBuffer.
>
> perhaps one plan would be to factor
On 11/18/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
I don't like this approach.
most people don't like this approach the first time they see it: it feels wrong
but give it time and think about it carefully before rushing to judgement
I think we should wait to refactor this component unti
I don't like this approach.
I think we should wait to refactor this component until we'll switch to
java 5 as the required jvm so we can introduce a Logger interface with
the mixin's methods we need.
If you want to avoid complex evaluation for debugging you will have to
use the isEnabled
On 11/18/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:
On 11/17/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Bernd Fondermann wrote:
> > On 11/17/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> >>
> >> Output code 2 from jdk 1.4
> >> > String s2 = s + "test" + s1 + "test" + i;
>
On 11/17/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Bernd Fondermann wrote:
> On 11/17/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>>
>> Output code 2 from jdk 1.4
>> > String s2 = s + "test" + s1 + "test" + i;
>>
>> Output code 2 from jdk 1.5
>> > String s2 = (new StringBuilde
Bernd Fondermann wrote:
On 11/17/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Output code 2 from jdk 1.4
> String s2 = s + "test" + s1 + "test" + i;
Output code 2 from jdk 1.5
> String s2 = (new StringBuilder()).append(s).append("test")
> .append(s1).append("test").append(i).t
:-)
Vincenzo
Joachim Draeger wrote:
Vincenzo Gianferrari Pini wrote:
BTW: I have often seen NPE *bugs* in debug messages, that appeared
magically when the costumer has turned on *de*bugging. :-) This could
avoided by putting a try/catch block around...
Im against this.. Even if the N
Vincenzo Gianferrari Pini wrote:
BTW: I have often seen NPE *bugs* in debug messages, that appeared
magically when the costumer has turned on *de*bugging. :-) This could
avoided by putting a try/catch block around...
Im against this.. Even if the NPE is in the debug message it should not
Norman Maurer wrote:
Joachim Draeger schrieb:
...
BTW: I have often seen NPE *bugs* in debug messages, that appeared
magically when the costumer has turned on *de*bugging. :-) This could
avoided by putting a try/catch block around...
Joachim
Im against this.. Even if the N
Joachim Draeger schrieb:
> Hi Bernd,
>
> Am Freitag, den 17.11.2006, 08:42 +0100 schrieb Bernd Fondermann:
>
>
>>> I also ran with jdk5 that code in a loop of 1 million iterations using
>>> foo = "foo" and bar = "bar" (this is FAR from any realistic scenario).
>>>
>> Microbenchmarking, a
Hi Bernd,
Am Freitag, den 17.11.2006, 08:42 +0100 schrieb Bernd Fondermann:
> > I also ran with jdk5 that code in a loop of 1 million iterations using
> > foo = "foo" and bar = "bar" (this is FAR from any realistic scenario).
>
> Microbenchmarking, again! ;-)
> Could it be you are testing loop
On 11/17/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Output code 2 from jdk 1.4
> String s2 = s + "test" + s1 + "test" + i;
Output code 2 from jdk 1.5
> String s2 = (new StringBuilder()).append(s).append("test")
> .append(s1).append("test").append(i).toString();
I also ran wi
Stefano Bagnara wrote:
> Input code 2:
> String res = foo + "test" + bar + "test" + i;
> Output code 2 from jdk 1.4
> String s2 = s + "test" + s1 + "test" + i;
> Output code 2 from jdk 1.5
> String s2 = (new StringBuilder()).append(s).append("test")
> .append(s1).append("test").append
robert burrell donkin wrote:
On 11/14/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Maybe this helps on this topic:
http://wiki.java.net/bin/view/Javapedia/AlwaysUseStringBufferMisconception#Concatenating_Literal_Strings
note that the misconception the link talks about is concatinating
strin
On 11/14/06, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Hi!
Am I hitting another controversy topic? ;-)
Example from ImapHandler.java
catch ( IOException e ) {
if ( getLogger().isErrorEnabled() ) {
StringBuffer exceptionBuffer =
new
ommand
> issue.
> To make it clear: I'm not proposing refactoring all around James. I just
> don't want to make extensive use of isLogEnabled() and StringBuffer().
> I'm going to remove it from Imap code where I think it brings more
> readability.
>
> WDYT?
A
On 11/14/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Maybe this helps on this topic:
http://wiki.java.net/bin/view/Javapedia/AlwaysUseStringBufferMisconception#Concatenating_Literal_Strings
note that the misconception the link talks about is concatinating
string literals, not variables
use
The path that you suggest is the exact opposite of a code review and code
change that we deliberately undertook after performance testing.
isEnabled should be used before formatting the message, and
StringBuffers is more efficient than String concatentation at very little
cost.
We can review to se
:-) thanks, interesting read.
although I must admit that my memory/GC statement indeed was a bit
sloppy and is not covered here, AFAICS.
Bernd
On 11/14/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Maybe this helps on this topic:
http://wiki.java.net/bin/view/Javapedia/AlwaysUseStringBufferM
Maybe this helps on this topic:
http://wiki.java.net/bin/view/Javapedia/AlwaysUseStringBufferMisconception#Concatenating_Literal_Strings
Stefano
Danny Angus wrote:
On 11/14/06, Bernd Fondermann <[EMAIL PROTECTED]> wrote:
On 11/14/06, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Memory garbage
On 11/14/06, Bernd Fondermann <[EMAIL PROTECTED]> wrote:
On 11/14/06, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Memory garbage should not be a problem any longer in the light of
generational GCs.
I'm not sure how you arrive at this sweeping conclusion!
Profligate use of memory is a problem
ing really much concats.
I would use isDebugEnabled() only inside a loop and not in a per command
issue.
To make it clear: I'm not proposing refactoring all around James. I just
don't want to make extensive use of isLogEnabled() and StringBuffer().
I'm going to remove it from Imap code where
er command
issue.
BTW:
catch ( IOException e ) {
getLogger().error( "Cannot open connection from " + remoteHost + " ("
+ remoteIP + "): " + e.getMessage() );
throw e;
}
To make it clear: I'm not proposing refactoring all around Jam
27 matches
Mail list logo
