Chris Hegarty wrote:
Are you referring to java.net.Proxy? Proxy.equals depends on the
resolution of its address. Address resolution could change over time,
depending on the caching policy. java.net.URL has a similar issue.
Just on this, are there issues with java.net.Proxy that should be
On 01/13/11 10:34 AM, Alan Bateman wrote:
Chris Hegarty wrote:
Are you referring to java.net.Proxy? Proxy.equals depends on the
resolution of its address. Address resolution could change over time,
depending on the caching policy. java.net.URL has a similar issue.
Just on this, are there
Changeset: 538f913777cf
Author:michaelm
Date: 2011-01-13 11:01 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/538f913777cf
6896088: URLClassLoader.close() apparently not working for JAR URLs on Windows
Reviewed-by: chegar
! src/share/classes/sun/misc/URLClassPath.java
+
I relatively recently discovered the existence of the new
java.util.Objects class, a repository of useful methods that people end
up rewriting endlessly for each project in classes named Util and such.
Most of the methods have to do with centralizing null handling (such
as Objects.hashCode(),
On 13/01/2011 20:06, Brian Goetz wrote:
Most of the other methods in this class are of the form do the right
thing if the object is null (or an array), but this one is throw an
exception if the object is null. The intent is clear -- it is for
simplifying fail-fast behavior by checking for
Maybe you have a nonNull() that throws NPE, and a nonNullSafe() ?
On Thu, Jan 13, 2011 at 3:12 PM, Tom Hawtin tom.haw...@oracle.com wrote:
On 13/01/2011 20:06, Brian Goetz wrote:
Most of the other methods in this class are of the form do the right
thing if the object is null (or an array),
I know that on the Oracle side we did internally discuss the potential
performance impact. The main performance concern seems to be the extra GC work
from creating the array of values (or the entry stack in the case of
Hashtable). We decided though that for most collections the small size and
On 01/13/2011 11:11 PM, Brian Goetz wrote:
rathole
I disagree with Tom here. We have *already* made the billion dollar
mistake, and we can't eliminate that headache (but we can provide
easier access to aspirin.) Java developers are *constantly* writing
methods like the suggested
and
public staticT T nonNull(String obj) {
return (obj == null) ? : obj;
}
etc.
I don't know, this doesn't feel right to me. It would probably make more
sense to have a:
public static T T defaulted(T test, T defVal) {
return test == null ? defVal : test;
}
This would cover both of the above
Am 13.01.2011 23:31, schrieb Rémi Forax:
I think I prefer throwIfNull() which is explicit.
+1
-Ulf
On 01/13/2011 04:31 PM, Rémi Forax wrote:
On 01/13/2011 11:11 PM, Brian Goetz wrote:
rathole
I disagree with Tom here. We have *already* made the billion dollar
mistake, and we can't eliminate that headache (but we can provide
easier access to aspirin.) Java developers are *constantly* writing
Date: Thu, 13 Jan 2011 17:11:37 -0500
From: brian.go...@oracle.com
...
One last question for Mark on the ensureXxx() convention: methods like
ensureXxx() sometimes mean make this true (like ensureCapacity() in
collections implementations) rather than barf if it is not true.
Right.
Rémi Forax said the following on 01/14/11 08:31:
I think I prefer throwIfNull() which is explicit.
+1
As to what gets thrown, none of these suggestions make that obvious from
their name so I would not be concerned about that. Every Java programmer
is very early introduced to
On 01/13/2011 11:41 PM, David M. Lloyd wrote:
On 01/13/2011 04:31 PM, Rémi Forax wrote:
On 01/13/2011 11:11 PM, Brian Goetz wrote:
rathole
I disagree with Tom here. We have *already* made the billion dollar
mistake, and we can't eliminate that headache (but we can provide
easier access to
Am 13.01.2011 23:38, schrieb Brian Goetz:
People use these to simplify cases like
if (foo != null)
for (Foo f : foo) { ... }
to
for (Foo f : nonNull(foo)) { ... }
To be honest, I don't understand the real value of nonNull().
If the argument is null, NPE would be thrown anyway.
Do I
On 01/13/2011 05:36 PM, David Holmes wrote:
Brian Goetz said the following on 01/14/11 09:15:
to go either way (both checkNonNull and ensureNonNull better
match the actual behavior of the method than plain nonNull) but
we might as well pick the right convention.
Rémi's throwIfNull(x)
Date: Thu, 13 Jan 2011 18:15:30 -0500
From: brian.go...@oracle.com
...
Between checkNonNull() and throwIfNull(), I lean towards the former. In any
case the answer should be driven by what is more obvious to the reader.
Agreed.
On 01/14/2011 01:20 AM, mark.reinh...@oracle.com wrote:
Date: Thu, 13 Jan 2011 18:15:30 -0500
From: brian.go...@oracle.com
...
Between checkNonNull() and throwIfNull(), I lean towards the former. In any
case the answer should be driven by what is more obvious to the reader.
Agreed.
On Thu, Jan 13, 2011 at 7:06 PM, Brian Goetz brian.go...@oracle.com wrote:
For clarification only (we're not suggesting adding these NOW, but instead
preserving the option):
People constantly write methods like
public String nonNull(String s) { return s != null ? s : }
and other versions
I'm still troubled by the check prefix, though. It implies that the
named condition will be tested but it doesn't clearly relate the result
of that test to the method's exception-throwing behavior.
Here's an idea: Why not treat this as a (degenerate) kind of conversion
operation? Call it
Should these checks even be part of java.lang? It promotes creeping in many
different assertion utility methods throughout the libraries. I personally
prefer the more flexible Hamcrest style, e.g. assertThat(foo,
is(not(nullValue(, which allows extensibility through matchers. However, I
They are not, they are java.util.
On 1/13/2011 9:25 PM, Ben Manes wrote:
Should these checks even be part of java.lang? It promotes creeping in
many different assertion utility methods throughout the libraries. I
personally prefer the more flexible Hamcrest style, e.g. assertThat(foo,
On 13/01/2011 22:11, Brian Goetz wrote:
rathole
I disagree with Tom here. We have *already* made the billion dollar
mistake, and we can't eliminate that headache (but we can provide easier
access to aspirin.) Java developers are *constantly* writing methods
like the suggested carpet-sweeping
Changeset: 29f2e311cce7
Author:mduigou
Date: 2011-01-13 20:32 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/29f2e311cce7
6728865: Provide a better heuristics for Collections.disjoint method
Reviewed-by: alanb, dholmes, chegar, forax
!
Changeset: a466f00c5cd2
Author:bpatel
Date: 2011-01-13 21:28 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a466f00c5cd2
7010528: javadoc performance regression
Reviewed-by: jjg
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java
!
I believe that the past performance concern was about the change from using
ObjectOutputStream.defaultWriteObject to using OOS.putFields/writeFields, which
adds some overhead-- although if you need to use them, you need to use them.
(This wouldn't apply to the Hashtable fix, which looks fine
Changeset: 59e352561146
Author:darcy
Date: 2011-01-13 22:21 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/59e352561146
7012279: Project Coin: Clarify AutoCloseable and Throwable javadoc
Reviewed-by: jjb
! src/share/classes/java/lang/AutoCloseable.java
!
27 matches
Mail list logo
