Mario Torre wrote:
Il 08/10/2009 20:10, Joseph D. Darcy ha scritto:
Hi Joseph!
Of course, it's nitpicking but:
> + System.err.printf("When equating %s to %s, got %b intead of %b%n.",
> + a, b, result, expected);
has a typo in there :)
There are others similar, copy and p
Hello.
Joshua Bloch wrote:
Joe,
Hi. I think it's great that you're doing this. A few comments:
+public class Objects {
+private Objects() {
+throw new AssertionError("No java.util.Objects instances
for you!");
+}
Cute!
+
+/**
+ *
Joe,
Joseph D. Darcy said the following on 10/09/09 04:30:
System.out.println("" + referenceOfAnyType);
will print "null" if referenceOfAnyType is null.
This is what the platform has done since the beginning.
Yes because String concatenation can not tolerate null values appearing,
so it is
Joe,
I understand your point, and that's why I countered with my String and
StringBuilder points. Those two classes are used underneath the covers
for inline concatenation, but, again, java.util.Objects has grander
intentions than string concatenation. This class is for all objects,
and however St
Another piece of functionality requested in the j.u.Objects thread was a
deepEquals(Object a, Object b.) method that "did the right thing" if the
arguments happened to dynamically be arrays.
I've been thinking a bit how this might be implemented.
The array-ness of a and b would need to be dete
Il 08/10/2009 20:10, Joseph D. Darcy ha scritto:
Hi Joseph!
Of course, it's nitpicking but:
> + System.err.printf("When equating %s to %s, got %b intead of %b%n.",
> + a, b, result, expected);
has a typo in there :)
There are others similar, copy and paste errors I suppos
Ulf Zibis said the following on 10/08/09 21:58:
Am 08.10.2009 12:59, David Holmes - Sun Microsystems schrieb:
It's a memory model issue. The code is like this:
public String getName() {
if (name == null)
name = getName0();
return name;
}
but in theory, a
Joe,
Hi. I think it's great that you're doing this. A few comments:
> +public class Objects {
> +private Objects() {
> +throw new AssertionError("No java.util.Objects instances for
> you!");
> +}
>
Cute!
> +
> +/**
> + * Returns {...@code true} if the arguments are equ
Joe,
I'll volunteer some "find usage" stats from the code base I work on for a
living:
565 ObjectUtils.toString(Object) calls.
487 String.valueOf(Object) calls.
Hopefully others can contribute their "find usage" stats. It seems to me that
both behaviors are useful.
Jason
>
Hello.
During the vigorous discussion of what Objects.toString(Object) should
be defined to do, a number of alternatives were suggested:
public static toString(Object a, String default) // return default if (a
== null) else a.toString()
public static toDefaultString(Object a) // return the st
Hello.
In the discussion about java.util.Objects, a few existing JDK methods
were mentioned for possible var-argification:
java.util.Arrays.hashCode(Object[] a)
java.util.Arrays.deepHashCode(Object[] a)
java.util.Arrays.toString(Object[] a)
Also of possible general interest are some methods o
Paul Benedict wrote:
Why would you choose to return "null" for any null object?
Because that is how the platform has always treated null in string
concatenation.
If you were defining new operations for String, StringBuilder, or
StringBuffer, I would agree with your choice. Since yo
>> Why would you choose to return "null" for any null object?
>
> Because that is how the platform has always treated null in string
> concatenation.
If you were defining new operations for String, StringBuilder, or
StringBuffer, I would agree with your choice. Since you are now
defining a global
Paul Benedict wrote:
Joe,
I'm preparing the first round of java.util.Objects with the
single-argument static toString method return "null" for null for final
review.
Why would you choose to return "null" for any null object?
Because that is how the platform has always treated null
Joe,
> I'm preparing the first round of java.util.Objects with the
> single-argument static toString method return "null" for null for final
> review.
Why would you choose to return "null" for any null object? Everyone
who has opined did disagree with replicating String.valueOf()
behavior. I don'
Hello.
Please code review the first-round of java.util.Objects; the patch is below:
http://cr.openjdk.java.net/~darcy/6797535.0/
-Joe
--- old/make/java/java/FILES_java.gmk 2009-10-08 11:04:03.0 -0700
+++ new/make/java/java/FILES_java.gmk 2009-10-08 11:04:02.0 -0700
@@ -258,6
Jason Mehrens wrote:
+1, return empty string for the one arg and add the two arg
variant. The j.u.Properties.getProperty(String, String) could use it
first. Just curious, what does project jigsaw think of j.u.Objects?
I'm preparing the first round of java.util.Objects with the
single-argume
+1, return empty string for the one arg and add the two arg variant. The
j.u.Properties.getProperty(String, String) could use it first. Just curious,
what does project jigsaw think of j.u.Objects?
Jason
> Date: Thu, 8 Oct 2009 11:47:49 +0100
> Subject: Objects.toString [Re: What method
+1 for me.
+1 also for having the overloaded version that can accept a fallback string.
Paul
+1 or drop Objects.toString(obj) completely.
-Ulf
Am 08.10.2009 12:47, Stephen Colebourne schrieb:
A number of us are proposing that Objects.toString(obj) should return
"" when the object is null. I'm strongly in favour of this, and it
removes any discussion of duplicated API (as it does somet
A number of us are proposing that Objects.toString(obj) should return
"" when the object is null. I'm strongly in favour of this, and it
removes any discussion of duplicated API (as it does something
different and more useful).
In favour/against +1/-1 ?
Stephen
2009/10/7 Joseph D. Darcy :
> Davi
Am 08.10.2009 12:59, David Holmes - Sun Microsystems schrieb:
Hi Ulf,
It's a memory model issue. The code is like this:
public String getName() {
if (name == null)
name = getName0();
return name;
}
but in theory, accoridng to the JMM experts, it could ac
Am 08.10.2009 06:35, David Holmes - Sun Microsystems schrieb:
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
Hi Ulf,
Ulf Zibis said the following on 10/08/09 20:07:
Am 08.10.2009 06:35, David Holmes - Sun Microsystems schrieb:
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
24 matches
Mail list logo