Re: What methods should go into a java.util.Objects class in JDK 7?
Ulf Zibis wrote: : In java.nio.file.Filesystem b72 I don't find information about sharing attributes. These are provider specific open options so they aren't in the javadoc. If you look at the dosSharingOptionTests in jdk/test/java/nio/Path/SBC.java you will see tests for these options. -Alan.
Re: j.ul.Objects follow-up: methods for var-argification?
Le 12/10/2009 20:41, Joseph D. Darcy a écrit :
Rémi Forax wrote:
Le 12/10/2009 19:25, Joseph D. Darcy a écrit :
Joshua Bloch wrote:
Joe,
I'm not sure I like this idea. My one experience with forcing an
array method to do double duty as varargs method was a disaster.
The method was Arrays.asList, and the result was Puzzler # 7 from
The Continuing Adventures of Java™Puzzlers: Tiger Traps. Here it
is:
*7. “Fib O’Nacci”*
public class Fibonacci {
private static final int LENGTH = 7;
public static void main(String[] args) {
int[] fib = new int[LENGTH];
fib[0] = fib[1] = 1; // First 2 Fibonacci numbers
for (inti = 2; i LENGTH; i++)
fib[i] = fib[i -2] + fib[i -1];
System.out.println(Arrays.asList(fib));
}
}
The main moral of the puzzle was:
Use varargssparingly in your APIs
•It can hide errors and cause confusion
•This program wouldn't compile under 1.4
Arrays.hashCode, equals, and toString are already overloaded out
the wazoo; adding varargs to the mix could be deadly. Also, Arrays
is not the place where people would go looking for what is
essentially a hashing utility. So I'm not in favor of varargifying
the existing methods in Arrays, but I am in favor of adding a
convenience method like this somewhere:
/**
* Generates a hash code for a sequence of input values. The
hash code is
* generated as if all the input values were placed into an
array, and that
* array were hashed by calling {...@link Arrays#hashCode(Object[])}.
* p/
* pThis method is useful for implementing {...@link
Object#hashCode()} on
* objects containing multiple fields. For example, if an
object that has
* three fields, {...@code x}, {...@code y}, and {...@code z}, one
could write:
* pre
* #064;Override public int hashCode() {
* return Objects.hashCode(x, y, z);
* }
* /pre
* bWarning: When a single object reference is supplied, the
returned
* value does not equal the hash code of that object
reference./b This
* value can be computed by calling {...@link #hashCode(Object)}.
*/
public static int hash(Object... components) {
return Arrays.hashCode(components);
}
Viewed in isolation, it's simple, straightforward, and will help
people write high quality hashCode methods. I don't think Objects
is a bad place for it, but you could put it is a hash utility
class if we wrote such a thing.
Okay; unless and until a hash utility is added somewhere, this
hash(Object ...) can live in Objects.
-Joe
In that case, we can also add some methods hash that avoid create an
array
for let say 2 to 5 arguments:
hash(Object, Object), hash-Object, Object, Object),
hash(Object,Object,Object,Object)
and hash(Object,Object,Object,Object,Object).
I don't think such methods are justified at present.
-Joe
It's not a good idea to have a hashCode() that allocate objects,
at least until escape analysis is implemented in all VMs.
Rémi
Re: j.ul.Objects follow-up: methods for var-argification?
On Mon, Oct 12, 2009 at 12:52 PM, Rémi Forax fo...@univ-mlv.fr wrote: It's not a good idea to have a hashCode() that allocate objects, at least until escape analysis is implemented in all VMs. Agree with Joe--these methods don't carry their weight. If the allocation is too much to bear, it's easy enough to write the hash by hand. Plus, it won't have the overhead of a method invocation. ;-) That's not to say I don't think you should ever do this. Bob
Re: First round of java.util.Objects for code review (bug 6797535)
Joe,
Thanks very much!
Josh
On Tue, Oct 13, 2009 at 11:12 AM, Joseph D. Darcy joe.da...@sun.com wrote:
Joshua Bloch wrote:
Joe,
Hi. I've attached a file containing the methods and a JTReg basic test
for inclusion in your BasicObjectTests. I adhered to your style, for easy
integration. If you could take it from here, I'd be ever so grateful.
Will do.
Cheers,
-Joe
Thanks,
Josh
On Thu, Oct 8, 2009 at 6:21 PM, Joe Darcy joe.da...@sun.com mailto:
joe.da...@sun.com wrote:
I strongly suggest that you do add these two methods:
/**
* Checks that the specified object reference is not {...@code
null}. This
* method is designed primarily for doing parameter
validation in methods
* and constructors, as demonstrated below:
* pre
* public Foo(Bar bar) {
* this.bar = Objects.nonNull(bar);
* }
* /pre
*
* @param obj the object reference to check for nullity
* @return {...@code obj} if not {...@code null}
* @throws NullPointerException if {...@code obj} is {...@code
null}
*/
public static T T nonNull(T obj) {
if (obj == null)
throw new NullPointerException();
return obj;
}
/**
* Checks that the specified object reference is not {...@code
null} and
* throws a customized {...@link NullPointerException} if it
is. This method
* is designed primarily for doing parameter validation in
methods and
* constructors with multiple parameters, as demonstrated
below:
* pre
* public Foo(Bar bar, Baz baz) {
* this.bar = Objects.nonNull(bar, bar must not be null);
* this.baz = Objects.nonNull(baz, baz must not be null);
* }
* /pre
*
* @param obj the object reference to check for nullity
* @param message detail message to be used in the event
that a {...@code
*NullPointerException} is thrown
* @return {...@code obj} if not {...@code null}
* @throws NullPointerException if {...@code obj} is {...@code
null}
*/
public static T T nonNull(T obj, String message) {
if (obj == null)
throw new NullPointerException(message);
return obj;
}
They do a great job reducing the verbiage in validity-checking
of arguments that must not be null.
I've filed bug 6889858 Add nonNull methods to java.util.Objects for
these last two methods. If you want to finish off the engineering
need for a changeset, some light tests, etc., I'll file the
Sun-internal paperwork for these.
Re: j.ul.Objects follow-up: methods for var-argification?
Rémi Forax wrote:
Le 12/10/2009 19:25, Joseph D. Darcy a écrit :
Joshua Bloch wrote:
Joe,
I'm not sure I like this idea. My one experience with forcing an
array method to do double duty as varargs method was a disaster.
The method was Arrays.asList, and the result was Puzzler # 7 from
The Continuing Adventures of Java™Puzzlers: Tiger Traps. Here it is:
*7. “Fib O’Nacci”*
public class Fibonacci {
private static final int LENGTH = 7;
public static void main(String[] args) {
int[] fib = new int[LENGTH];
fib[0] = fib[1] = 1; // First 2 Fibonacci numbers
for (inti = 2; i LENGTH; i++)
fib[i] = fib[i -2] + fib[i -1];
System.out.println(Arrays.asList(fib));
}
}
The main moral of the puzzle was:
Use varargssparingly in your APIs
•It can hide errors and cause confusion
•This program wouldn't compile under 1.4
Arrays.hashCode, equals, and toString are already overloaded out the
wazoo; adding varargs to the mix could be deadly. Also, Arrays is
not the place where people would go looking for what is essentially
a hashing utility. So I'm not in favor of varargifying the existing
methods in Arrays, but I am in favor of adding a convenience method
like this somewhere:
/**
* Generates a hash code for a sequence of input values. The
hash code is
* generated as if all the input values were placed into an
array, and that
* array were hashed by calling {...@link Arrays#hashCode(Object[])}.
* p/
* pThis method is useful for implementing {...@link
Object#hashCode()} on
* objects containing multiple fields. For example, if an object
that has
* three fields, {...@code x}, {...@code y}, and {...@code z}, one could
write:
* pre
* #064;Override public int hashCode() {
* return Objects.hashCode(x, y, z);
* }
* /pre
* bWarning: When a single object reference is supplied, the
returned
* value does not equal the hash code of that object
reference./b This
* value can be computed by calling {...@link #hashCode(Object)}.
*/
public static int hash(Object... components) {
return Arrays.hashCode(components);
}
Viewed in isolation, it's simple, straightforward, and will help
people write high quality hashCode methods. I don't think Objects
is a bad place for it, but you could put it is a hash utility
class if we wrote such a thing.
Okay; unless and until a hash utility is added somewhere, this
hash(Object ...) can live in Objects.
-Joe
In that case, we can also add some methods hash that avoid create an
array
for let say 2 to 5 arguments:
hash(Object, Object), hash-Object, Object, Object),
hash(Object,Object,Object,Object)
and hash(Object,Object,Object,Object,Object).
I don't think such methods are justified at present.
-Joe
Re: j.u.Objects follow-up: deepEquals(Object, Object)?
Joshua Bloch wrote: I don't think method really pays for itself. If it belongs anywhere, it belongs in java.util.Arrays. Josh I think there is room in the platform for this functionality. Even if this is mostly used in tests, code used in tests is code too :-) I think Objects is a better home for deepEquals(Object, Object) than Arrays since the arguments are not arrays and since it is a sibling method to equals(Object, Object). -Joe
Re: First round of java.util.Objects for code review (bug 6797535)
Joe,
Hi. I've attached a file containing the methods and a JTReg basic test
for inclusion in your BasicObjectTests. I adhered to your style, for easy
integration. If you could take it from here, I'd be ever so grateful.
Thanks,
Josh
On Thu, Oct 8, 2009 at 6:21 PM, Joe Darcy joe.da...@sun.com wrote:
I strongly suggest that you do add these two methods:
/**
* Checks that the specified object reference is not {...@code null}. This
* method is designed primarily for doing parameter validation in
methods
* and constructors, as demonstrated below:
* pre
* public Foo(Bar bar) {
* this.bar = Objects.nonNull(bar);
* }
* /pre
*
* @param obj the object reference to check for nullity
* @return {...@code obj} if not {...@code null}
* @throws NullPointerException if {...@code obj} is {...@code null}
*/
public static T T nonNull(T obj) {
if (obj == null)
throw new NullPointerException();
return obj;
}
/**
* Checks that the specified object reference is not {...@code null} and
* throws a customized {...@link NullPointerException} if it is. This
method
* is designed primarily for doing parameter validation in methods and
* constructors with multiple parameters, as demonstrated below:
* pre
* public Foo(Bar bar, Baz baz) {
* this.bar = Objects.nonNull(bar, bar must not be null);
* this.baz = Objects.nonNull(baz, baz must not be null);
* }
* /pre
*
* @param obj the object reference to check for nullity
* @param message detail message to be used in the event that a {...@code
*NullPointerException} is thrown
* @return {...@code obj} if not {...@code null}
* @throws NullPointerException if {...@code obj} is {...@code null}
*/
public static T T nonNull(T obj, String message) {
if (obj == null)
throw new NullPointerException(message);
return obj;
}
They do a great job reducing the verbiage in validity-checking of
arguments that must not be null.
I've filed bug 6889858 Add nonNull methods to java.util.Objects for
these last two methods. If you want to finish off the engineering need for
a changeset, some light tests, etc., I'll file the Sun-internal paperwork
for these.
NonNull.java
Description: Binary data
hg: jdk7/tl/jdk: 6349921: (enum) Include links from java.lang.Enum to EnumSet and EnumMap
Changeset: 151baf5e19ca Author:darcy Date: 2009-10-13 17:34 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/151baf5e19ca 6349921: (enum) Include links from java.lang.Enum to EnumSet and EnumMap Reviewed-by: martin ! src/share/classes/java/lang/Enum.java
