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 adde
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 iss
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
+ test
Changeset: 694951adefec
Author:chegar
Date: 2011-01-13 13:24 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/694951adefec
6964547: Impossible to set useV4 in SocksSocketImpl
Summary: Add socksProxyVersion property
Reviewed-by: alanb, michaelm
! make/sun/net/FILES_java.gmk
! s
Changeset: 38729ba6eb4f
Author:michaelm
Date: 2011-01-12 15:05 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/38729ba6eb4f
6829919: URLClassLoader.close() doesn't close resource file if
getResourceAsStream(...) was called before
Reviewed-by: chegar
! src/share/classes/java/
Changeset: 3215b22cd90e
Author:michaelm
Date: 2011-01-13 16:33 +
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3215b22cd90e
7003398: NetworkInterface equals() and hashCode() behaviors depend on
permissions granted
Reviewed-by: chegar, alanb
! src/share/classes/java/net/Netwo
> I wonder the design for Proxy and InvocationHandler can be
> enhanced by creating a default equals/toString/hashCode implementation
> for Proxy correctly, not ask developers to do it again and again
> whenever he uses Proxy. Anyway, this may be another story.
See: http://bugs.sun.com/bugdat
Changeset: d33d8c381aa1
Author:jjg
Date: 2011-01-13 11:48 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d33d8c381aa1
6430241: Hard to disable symbol file feature through API
Reviewed-by: mcimadamore
! src/share/classes/com/sun/tools/javac/file/JavacFileManager.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 01/13/2011 02:06 PM, Brian Goetz wrote:
I propose to change these to be called checkNonNull(), so their
null-checking behavior is obvious to readers of code
I agree with this, but...
and to leave room
to LATER provide methods like
public static T nonNull(T[] obj) {
return (obj == null) ?
> Date: Thu, 13 Jan 2011 15:06:54 -0500
> From: brian.go...@oracle.com
> ...
>
> I propose to change these to be called checkNonNull(), so their null-checking
> behavior is obvious to readers of code, ...
An even better name would be ensureNonNull(), which captures the notion
that if the method
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 nu
Maybe you have a nonNull() that throws NPE, and a nonNullSafe() ?
On Thu, Jan 13, 2011 at 3:12 PM, Tom Hawtin 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)", but this one is
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 nonNull() to work around this (and
some of the
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
s
On 01/13/2011 11:11 PM, Brian Goetz wrote:
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 non
and
public static 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 defaulted(T test, T defVal) {
return test == null ? defVal : test;
}
This would cover both of the above c
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:
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
> 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."
Rig
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 NullPointerExcep
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) suggestion does capture the precise meaning,
though it begs the question of what, exactly, will be thrown
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) suggestion does capture the precise meaning,
though it
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:
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.) Ja
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) suggestio
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 (including the more general version that takes a
default, and versions for
> 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 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 (including t
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 asNo
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
wou
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,
is(not(nul
On 13/01/2011 22:11, Brian Goetz wrote:
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 nonNull() t
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
! src/share/classes/java/util/Collections
Thinking some more:
- The name nonNull() is just confusing. It could reasonably mean one
of several things, and we've seen this in people's reactions: some don't
like it for the throwing behavior because its not clear that it has a
strong checking behavior, others don't like it for the defau
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
! src/share/cla
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 to
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
! src/share/classes/ja
39 matches
Mail list logo
