On Tue, Oct 6, 2009 at 09:40, Paulo Levi i30...@gmail.com wrote:
I thought there was the danger of deadlocks if the std.out and std.err
wasn't drained?
Well, yes, there is a danger of deadlocks, but this can be avoided by:
- having separate threads read stdout and stderr
- closing the various
Changeset: f69b40e43bff
Author:kamg
Date: 2009-10-06 22:01 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f69b40e43bff
6885916: Memory leak in inferencing verifier (libverify.so)
Summary: Use the memory management already present to track allocated memory
Reviewed-by:
Paul Benedict wrote:
If you want Objects.toString() to provide value, consider mimicking
the functionality from Apache Commons:
http://commons.apache.org/lang/api-2.4/org/apache/commons/lang/ObjectUtils.html
My biggest complaint about String.valueOf(Object) is that it will
actually return null
Stephen Colebourne said the following on 10/07/09 18:10:
BTW, I don't accept the argument that one and only one way to do
something is part of the JDK.
While the JDK is far from a model example of providing one way to do
something, that doesn't mean we should gratuitously add superfluous and
Hi Stephen,
[...]
In key places there are multiple options. NIO Path vs File and
Calendar vs Date are examples.
As you know, Path (resp. Calendar) is just an attempt to correct the
mess introduced by File (resp. Date).
So yes, there is duplication but this duplication is done to
Changeset: f864c15f6779
Author:chegar
Date: 2009-10-07 17:23 +0100
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f864c15f6779
6887364: SetOutgoingIf.java fails if run on multihomed machine without PIv6 on
all interfaces
Reviewed-by: alanb
!
David Holmes - Sun Microsystems wrote:
Stephen Colebourne said the following on 10/07/09 18:10:
BTW, I don't accept the argument that one and only one way to do
something is part of the JDK.
While the JDK is far from a model example of providing one way to do
something, that doesn't mean we
Joe,
Here are a few more resources that you may want to investigate for
java.util.Objects:
*
http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/base/Objects.html
*
Ulf,
Though I did not write the cache code my reading suggests the existing cache
impl tries to avoid the relatively expensive synchronization for most
use scenarios,
your approach however hits the synchronization for each/every lookup
invocation.
So you should at least consider to put the
Joe,
These look ok to me
-lance
Joseph D. Darcy wrote:
Hello.
Please review these simple cleanup fixes in the wrapper classes:
6480728: Byte.valueOf(byte) returns a cached value but
Byte.valueOf(String)
6655735: Integer.toString() and String.valueOf(int) contain slow
delegations
The
On Wed, Oct 7, 2009 at 15:58, Ulf Zibis ulf.zi...@gmx.de wrote:
For my better understanding:
Can you explain me the real bug in
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6881442.
In my understanding, loading the name field twice is too only a
performance bug. Please correct me!
Ulf,
Ulf Zibis said the following on 10/08/09 08:58:
For my better understanding:
Can you explain me the real bug in
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6881442.
In my understanding, loading the name field twice is too only a
performance bug. Please correct me!
12 matches
Mail list logo