On Wed, Oct 14, 2009 at 3:38 AM, Stephen Colebourne wrote:
While I agree that the nonNull methods below are useful and should be in the
> JDK, I question whether they should be on j.u.Objects.
>
> I believe that there is a whole category of methods to pre-validate the
> arguments of a method, such
Joseph D. Darcy wrote:
If such a validation class is added to the platform, the nonNull
methods can be moved there. Until then, they can live in Objects.
At first glance, such an approach makes perfect sense. However, we
should really stop and question whether it is right or not.
One point th
Stephen Colebourne wrote:
Joseph D. Darcy wrote:
If such a validation class is added to the platform, the nonNull
methods can be moved there. Until then, they can live in Objects.
At first glance, such an approach makes perfect sense. However, we
should really stop and question whether it is r
Stephen,
My interpretation of Joe's email was that it would stay in j.u.Objects
unless someone (other than him) contributes the Validate class and
tests. Granting your point, his choice would otherwise stand and
re-factoring it after JDK 7 would be impossible.
I am interested in such a class and
Joseph D. Darcy wrote:
If such a validation class is added to the platform, the nonNull
methods can be moved there. Until then, they can live in Objects.
At first glance, such an approach makes perfect sense. However, we
should really stop and question whether it is right or not.
One point tha
Jesús Viñuales wrote:
I agree with Stephen. There are a slew of validation methods that
would be beneficial, and if you really want to drive the JDK towards
standard validation, refactor them out into a Validation class. Look
at what Spring has written for themselves:
http://static.springsource.
> I agree with Stephen. There are a slew of validation methods that
> would be beneficial, and if you really want to drive the JDK towards
> standard validation, refactor them out into a Validation class. Look
> at what Spring has written for themselves:
>
>http://static.springsource.org/spring/doc
I agree with Stephen. There are a slew of validation methods that
would be beneficial, and if you really want to drive the JDK towards
standard validation, refactor them out into a Validation class. Look
at what Spring has written for themselves:
http://static.springsource.org/spring/docs/2.5.x/ap
All,
While I agree that the nonNull methods below are useful and should be in
the JDK, I question whether they should be on j.u.Objects.
I believe that there is a whole category of methods to pre-validate the
arguments of a method, such as Commons Lang Validate, or Google Prevalidate.
http:/
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 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,
Jos
Joe,
Thanks very much!
Josh
On Tue, Oct 13, 2009 at 11:12 AM, Joseph D. Darcy 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
>> integrati
2009/10/9 Eamonn McManus :
>> The spec, you mention, refers to the instance method equals(), but here
>> we are talking about static helpers.
>
> The difference between Marek's suggestion and Joe's is what happens when
> the equals(Object) method of a or b returns true for a null argument, and
> th
Am 09.10.2009 11:36, Eamonn McManus schrieb:
> The spec, you mention, refers to the instance method equals(), but here
> we are talking about static helpers.
The difference between Marek's suggestion and Joe's is what happens when
the equals(Object) method of a or b returns true for a null argum
> The spec, you mention, refers to the instance method equals(), but here
> we are talking about static helpers.
The difference between Marek's suggestion and Joe's is what happens when
the equals(Object) method of a or b returns true for a null argument, and
that is what I was saying violates th
Am 09.10.2009 10:56, Eamonn McManus schrieb:
Hi,
Marek Kozieł wrote:
>> +public static boolean equals(Object a, Object b) {
>> +return (a == b) || (a != null && a.equals(b));
>> +}
>
> Hello,
> I would suggest other implementation of equals method:
>
> public static boolean e
Hi,
Marek Kozieł wrote:
>> +public static boolean equals(Object a, Object b) {
>> +return (a == b) || (a != null && a.equals(b));
>> +}
>
> Hello,
> I would suggest other implementation of equals method:
>
>public static boolean equals(Object a, Object b) {
>if (a
2009/10/8 Joseph D. Darcy :
> 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 200
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!
+
+/**
+ *
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
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
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
23 matches
Mail list logo
