Re: What methods should go into a java.util.Objects class in JDK 7?

[Osvaldo Pinali Doederlein]

+1 for Elvis operator, +1000 for [non-]nullability support in the 
typesystem like Fan. Ideally, the latter featutre should be supported at 
the bytecode level (not sugar) so a big number of variables would be 
hard-tagged as never null, which I suppose would result in faster code 
without dependency on nullcheck removal optimizations that are not 
always feasible and even when possible, have costs like code bloat.
+0.5 for the two Objects.nonNull() methods. They are useful at least 
because they avoid double evaluation. I'd prefer all Objects methods to 
live in the global namespace - just static-import Objects.* by default - 
but I understand the issues. And I'd prefer to rename these methods to 
nvl(), identical to SQL so it's a good name even if terse, and I prefer 
terse names in functions that are likely to be used multiple times in 
complex expressions (many people prefer a operator like Elvis because 
even nvl() may be too cumbersome).
-1000 for automatic swallowing of nulls like JavaFX Script, that I 
reported as a bug (http://javafx-jira.kenai.com/browse/JFXC-3447).


Just my 2c.

Em 16/11/2009 14:28, Marek Kozieł escreveu:

2009/11/16 Stephen Colebourne:
   

2009/11/16 David Holmes - Sun Microsystems:
 

In this specific case, the question was "why include it when you can
use a?b:c". Well, I've seen resistance by developers to that language
feature, and I know some places outright block it in coding standards.
For many, a method call is preferred, and "overhead" isn't what
matters.
 

I find such a mentality to programming to be utterly incomprehensible. Who
are these people? And what motivates them?

I say let these people define their own libraries to support their
pathologies - don't lumber it on the rest of the general population of
programmers.
   

This is where things can get very heated, so please take this as just
my take on what I see.

The community that defines Java - Sun, Google, Open Source, Bloggers -
are, in general, the experts and gurus in the field. Most people
reading this list have no problem with the ternary statement. Most of
us realise that null avoidance is better than null-handling. However,
we are, by far, the *minority* of Java developers, not the majority.

My call is not to let the majority rule, but to understand that the
quality code and standards of Sun/Google/SiliconValley are far, far
rarer everywhere else. Sometimes as leaders it is necessary to accept
that not everyone is going to do things the 'right' way, and sometimes
it is better to help mitigate the 'wrong' way (hence Elvis and
friends). In other words, what do you do when telling people to do the
right thing fails?

As I say, this is as much about opinion and what you have experienced
as hard facts. For example, I know that nulls and null-handling is
everywhere in the codebase I work on, and I don't consider that to be
especially wrong or broken, nor do my colleagues.

BTW, for the future I'd remind everyone of Fan - http://fandev.org -
where all variable references are non-null by default, something which
we should all support.

Stephen

 

I agree with Stephen.

In real word you have to deal with "pathologies" which are made by others.
When you deal with muck you need pitchfork not a white gloves.

I discuses a lot about Elvis null-safe operator and conclusion was always same:
Java without it is better, but there is a lot of cases when we need it
to deal with crappy code.

   

Re: What methods should go into a java.util.Objects class in JDK 7?

[Marek Kozieł]

2009/11/16 Stephen Colebourne :
> 2009/11/16 David Holmes - Sun Microsystems :
>>> In this specific case, the question was "why include it when you can
>>> use a?b:c". Well, I've seen resistance by developers to that language
>>> feature, and I know some places outright block it in coding standards.
>>> For many, a method call is preferred, and "overhead" isn't what
>>> matters.
>>
>> I find such a mentality to programming to be utterly incomprehensible. Who
>> are these people? And what motivates them?
>>
>> I say let these people define their own libraries to support their
>> pathologies - don't lumber it on the rest of the general population of
>> programmers.
>
> This is where things can get very heated, so please take this as just
> my take on what I see.
>
> The community that defines Java - Sun, Google, Open Source, Bloggers -
> are, in general, the experts and gurus in the field. Most people
> reading this list have no problem with the ternary statement. Most of
> us realise that null avoidance is better than null-handling. However,
> we are, by far, the *minority* of Java developers, not the majority.
>
> My call is not to let the majority rule, but to understand that the
> quality code and standards of Sun/Google/SiliconValley are far, far
> rarer everywhere else. Sometimes as leaders it is necessary to accept
> that not everyone is going to do things the 'right' way, and sometimes
> it is better to help mitigate the 'wrong' way (hence Elvis and
> friends). In other words, what do you do when telling people to do the
> right thing fails?
>
> As I say, this is as much about opinion and what you have experienced
> as hard facts. For example, I know that nulls and null-handling is
> everywhere in the codebase I work on, and I don't consider that to be
> especially wrong or broken, nor do my colleagues.
>
> BTW, for the future I'd remind everyone of Fan - http://fandev.org -
> where all variable references are non-null by default, something which
> we should all support.
>
> Stephen
>

I agree with Stephen.

In real word you have to deal with "pathologies" which are made by others.
When you deal with muck you need pitchfork not a white gloves.

I discuses a lot about Elvis null-safe operator and conclusion was always same:
Java without it is better, but there is a lot of cases when we need it
to deal with crappy code.

-- 
Regards.
Lasu aka Marek Kozieł

Re: What methods should go into a java.util.Objects class in JDK 7?

[Stephen Colebourne]

2009/11/16 David Holmes - Sun Microsystems :
>> In this specific case, the question was "why include it when you can
>> use a?b:c". Well, I've seen resistance by developers to that language
>> feature, and I know some places outright block it in coding standards.
>> For many, a method call is preferred, and "overhead" isn't what
>> matters.
>
> I find such a mentality to programming to be utterly incomprehensible. Who
> are these people? And what motivates them?
>
> I say let these people define their own libraries to support their
> pathologies - don't lumber it on the rest of the general population of
> programmers.

This is where things can get very heated, so please take this as just
my take on what I see.

The community that defines Java - Sun, Google, Open Source, Bloggers -
are, in general, the experts and gurus in the field. Most people
reading this list have no problem with the ternary statement. Most of
us realise that null avoidance is better than null-handling. However,
we are, by far, the *minority* of Java developers, not the majority.

My call is not to let the majority rule, but to understand that the
quality code and standards of Sun/Google/SiliconValley are far, far
rarer everywhere else. Sometimes as leaders it is necessary to accept
that not everyone is going to do things the 'right' way, and sometimes
it is better to help mitigate the 'wrong' way (hence Elvis and
friends). In other words, what do you do when telling people to do the
right thing fails?

As I say, this is as much about opinion and what you have experienced
as hard facts. For example, I know that nulls and null-handling is
everywhere in the codebase I work on, and I don't consider that to be
especially wrong or broken, nor do my colleagues.

BTW, for the future I'd remind everyone of Fan - http://fandev.org -
where all variable references are non-null by default, something which
we should all support.

Stephen

Re: What methods should go into a java.util.Objects class in JDK 7?

[Paul Benedict]

I agree with Stephen that the Elvis operator should have been included.

Regardless, I think the proposed method is still a common idiom worth
having. It might not "save any keystrokes", but it's a certain way of
not flubbing ternary logic or a verbose if-else statement.

By the way, this is a lot easier than writing out the native logic check:
defaultIfNull(a, defaultIfNull(b, c));

Paul

Re: What methods should go into a java.util.Objects class in JDK 7?

[David Holmes - Sun Microsystems]

Stephen Colebourne said the following on 11/16/09 18:44:

In this specific case, the question was "why include it when you can
use a?b:c". Well, I've seen resistance by developers to that language
feature, and I know some places outright block it in coding standards.
For many, a method call is preferred, and "overhead" isn't what
matters.


I find such a mentality to programming to be utterly incomprehensible. 
Who are these people? And what motivates them?


I say let these people define their own libraries to support their 
pathologies - don't lumber it on the rest of the general population of 
programmers.


My 2c. YMMV. ;-)

David Holmes

Re: What methods should go into a java.util.Objects class in JDK 7?

[Stephen Colebourne]

2009/11/16 Martin Buchholz :
> On Sun, Nov 15, 2009 at 16:47, Rémi Forax  wrote:
>> Do you want to say something like "I need a closure here" :)
>>
>
> No.  I need a macro here!  (But not a C-style one)

No, what you need is the Elvis null-safe operator ?:  But then that
was rejected wasn't it...

Now, we have more objections against the method that was proposed to
be used when the operator was rejected. It would be funny if it wasn't
so maddening.

As I've said before, nulls are everywhere in real code. Absolutely
everywhere. And they cause so many problems in real, production code
that they should be top of the list of issues that should be
addressed.

In this specific case, the question was "why include it when you can
use a?b:c". Well, I've seen resistance by developers to that language
feature, and I know some places outright block it in coding standards.
For many, a method call is preferred, and "overhead" isn't what
matters.

Stephen

Re: What methods should go into a java.util.Objects class in JDK 7?

[Martin Buchholz]

On Sun, Nov 15, 2009 at 16:47, Rémi Forax  wrote:

>  Do you want to say something like "I need a closure here" :)
>
>
No.  I need a macro here!  (But not a C-style one)

Martin

Re: What methods should go into a java.util.Objects class in JDK 7?

[Rémi Forax]

Le 16/11/2009 00:48, Martin Buchholz a écrit :



On Sat, Nov 14, 2009 at 20:46, David Holmes - Sun Microsystems 
mailto:david.hol...@sun.com>> wrote:


Paul,

Paul Benedict said the following on 11/15/09 11:28:

I would like to propose adding this method:

/**
 * Selects the object if not {...@code null}; otherwise fallsback
to the
 * specified default object.
 *
 * @param object the object to test
 * @param defaultObject the default object
 * @return the object if not {...@code null}; otherwise the
default object
 */
public static Object defaultIfNull(Object object, Object
defaultObject) {
   return (object != null) ? object : defaultObject;
}


I don't get it. Why would anyone need the above when they can write:

   obj != null ? obj : otherObj


The obvious reason is to save creation of a temp variable

Some tmp = longExpression;
return tmp != null ? tmp : defaultValue;

But I'm not in favor of this proposal either.
The biggest problem is that you want
defaultObject to be an expression
that only gets evalutated if tmp == null.
And that suggests adding some kind of syntactic abstraction
that I would like to use myself, but is not
in the spirit of Java.

Martin


Do you want to say something like "I need a closure here" :)

Rémi




themselves ??? Compared to

   defaultIfNull(obj, otherObj)

you don't even save any keystrokes (and this is with a static import)!

David Holmes

Re: What methods should go into a java.util.Objects class in JDK 7?

[Martin Buchholz]

On Sat, Nov 14, 2009 at 20:46, David Holmes - Sun Microsystems <
david.hol...@sun.com> wrote:

> Paul,
>
> Paul Benedict said the following on 11/15/09 11:28:
>
>  I would like to propose adding this method:
>>
>> /**
>>  * Selects the object if not {...@code null}; otherwise fallsback to the
>>  * specified default object.
>>  *
>>  * @param object the object to test
>>  * @param defaultObject the default object
>>  * @return the object if not {...@code null}; otherwise the default object
>>  */
>> public static Object defaultIfNull(Object object, Object defaultObject) {
>>return (object != null) ? object : defaultObject;
>> }
>>
>
> I don't get it. Why would anyone need the above when they can write:
>
>obj != null ? obj : otherObj
>

The obvious reason is to save creation of a temp variable

Some tmp = longExpression;
return tmp != null ? tmp : defaultValue;

But I'm not in favor of this proposal either.
The biggest problem is that you want
defaultObject to be an expression
that only gets evalutated if tmp == null.
And that suggests adding some kind of syntactic abstraction
that I would like to use myself, but is not
in the spirit of Java.

Martin


> themselves ??? Compared to
>
>defaultIfNull(obj, otherObj)
>
> you don't even save any keystrokes (and this is with a static import)!
>
> David Holmes
>
>

Re: What methods should go into a java.util.Objects class in JDK 7?

[David Holmes - Sun Microsystems]

Paul,

No it is not rhetorical. Most of the one-liners (and I don't necessarily 
agree with them either) at least have some perceived convenience value. 
In this case I see no value add at all. In fact unless you count on 
inlining then this adds pure overhead with the method call.


David

Paul Benedict said the following on 11/16/09 00:01:

David,

I think your question is mostly rhetorical. Most of the code in this
class are one-liners. If you can answer it for this method, you have
answered it for all.

I also think it's a common idiom... and so are the other small stuff in here.

Paul

On Sat, Nov 14, 2009 at 10:46 PM, David Holmes - Sun Microsystems
 wrote:

Paul,

Paul Benedict said the following on 11/15/09 11:28:

I would like to propose adding this method:

/**
 * Selects the object if not {...@code null}; otherwise fallsback to the
 * specified default object.
 *
 * @param object the object to test
 * @param defaultObject the default object
 * @return the object if not {...@code null}; otherwise the default object
 */
public static Object defaultIfNull(Object object, Object defaultObject) {
   return (object != null) ? object : defaultObject;
}

I don't get it. Why would anyone need the above when they can write:

   obj != null ? obj : otherObj

themselves ??? Compared to

   defaultIfNull(obj, otherObj)

you don't even save any keystrokes (and this is with a static import)!

David Holmes

Re: What methods should go into a java.util.Objects class in JDK 7?

[Paul Benedict]

David,

I think your question is mostly rhetorical. Most of the code in this
class are one-liners. If you can answer it for this method, you have
answered it for all.

I also think it's a common idiom... and so are the other small stuff in here.

Paul

On Sat, Nov 14, 2009 at 10:46 PM, David Holmes - Sun Microsystems
 wrote:
> Paul,
>
> Paul Benedict said the following on 11/15/09 11:28:
>>
>> I would like to propose adding this method:
>>
>> /**
>>  * Selects the object if not {...@code null}; otherwise fallsback to the
>>  * specified default object.
>>  *
>>  * @param object the object to test
>>  * @param defaultObject the default object
>>  * @return the object if not {...@code null}; otherwise the default object
>>  */
>> public static Object defaultIfNull(Object object, Object defaultObject) {
>>    return (object != null) ? object : defaultObject;
>> }
>
> I don't get it. Why would anyone need the above when they can write:
>
>    obj != null ? obj : otherObj
>
> themselves ??? Compared to
>
>    defaultIfNull(obj, otherObj)
>
> you don't even save any keystrokes (and this is with a static import)!
>
> David Holmes
>
>

Re: What methods should go into a java.util.Objects class in JDK 7?

[David Holmes - Sun Microsystems]

Paul,

Paul Benedict said the following on 11/15/09 11:28:

I would like to propose adding this method:

/**
 * Selects the object if not {...@code null}; otherwise fallsback to the
 * specified default object.
 *
 * @param object the object to test
 * @param defaultObject the default object
 * @return the object if not {...@code null}; otherwise the default object
 */
public static Object defaultIfNull(Object object, Object defaultObject) {
return (object != null) ? object : defaultObject;
}


I don't get it. Why would anyone need the above when they can write:

obj != null ? obj : otherObj

themselves ??? Compared to

defaultIfNull(obj, otherObj)

you don't even save any keystrokes (and this is with a static import)!

David Holmes

Re: What methods should go into a java.util.Objects class in JDK 7?

[Paul Benedict]

I would like to propose adding this method:

/**
 * Selects the object if not {...@code null}; otherwise fallsback to the
 * specified default object.
 *
 * @param object the object to test
 * @param defaultObject the default object
 * @return the object if not {...@code null}; otherwise the default object
 */
public static Object defaultIfNull(Object object, Object defaultObject) {
return (object != null) ? object : defaultObject;
}

Paul

Re: What methods should go into a java.util.Objects class in JDK 7?

[Ulf Zibis]

Am 09.09.2009 22:40, Joe Darcy schrieb:

Hello.

For JDK 7, I think it is high-time the platform included a class like 
java.util.Objects to hold commonly-written utility methods.  For 
example, a two-argument static equals method that returned true if 
both arguments are null, returns false is one argument is null, and 
otherwise returns the result of calling arg1.equals(arg2)  (6797535 
"Add shared two argument static equals method to the platform").


A static hashCode method returning 0 for null and the value of 
arg.hashCode() has also been suggested.


A set of

   static int compareTo(int, int)
   static int compareTo(long, long)
   

methods probably belongs somewhere in the platform too.

What other utility methods would have broad enough use and 
applicability to go into a common java.util class?



Maybe a little late, but as I said regarding suggested "Strings" class:

Imagine, you could just write

   int result = compare(x, y);
   int hash = hashCode(x);

in any class, without having to statically import java.util.Objects.*.
This smartness would be possible, if those few static methods in Objects 
would be moved to java.lang.Object.


Introducing a static helper class 'ClassNames' consequently for each 
"normal" class 'ClassName' we would end up in don't having any static 
method in a normal class, and so we could drop this language concept 
completely from Java and instead introduce a kind of "static" class, 
where all method's are static by definition, similar to abstract class, 
where all methods are abstract.


I assume, the first of the '...s'-classes was 'Arrays', introduced, 
because array object's and there members (e.g. length) are not defined 
via normal class syntax.


IMO, introducing '...s'-classes for whatever class is a bad idea, and 
would _*satirize*_ the existence of _*static methods at all*_, whose 
worthy task it is , to provide helper functions to instances of objects, 
where they are defined.



But I think, it's not too late, to change it in JDK 7.


-Ulf

Re: What methods should go into a java.util.Objects class in JDK 7?

[Alan Bateman]

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: What methods should go into a java.util.Objects class in JDK 7?

[Ulf Zibis]

Am 12.10.2009 16:26, Alan Bateman schrieb:

Ulf Zibis wrote:

Am 12.10.2009 15:03, Ulf Zibis schrieb:
Additionally something like Path#unlock() would be helpful, if 
copy/delete fails. For example see: 
http://diamondcs.com.au/freeutilities/fileunlocker.php


Additionally see: http://ccollomb.free.fr/unlocker/
I assume this type of thing can lead to data loss and/or hard to 
diagnose corruption.


Of course, such method should be used with care. The developer/user 
should first retrieve/examine some information like the blocking process 
from the locked file. But this option should be more comfortable, than 
rebooting the hole system, which too could have data loss/corruption in 
consequence.

... and delete always has data loss in effect. ;-)

If you are running into sharing violations then try out the file 
system API as the Windows provider opens files by default to allow 
delete access (ie: close to Unix semantics by default with provider 
specific options to control the DOS sharing mode if you really want).


In java.nio.file.Filesystem b72 I don't find information about sharing 
attributes.


The only case where we still have a problem is memory-mapped files. 
Changing the long standing behavior of the java.io classes is another 
matter as that would likely break existing applications that rely on 
the current/long standing behavior.


-Alan.




-Ulf

Re: What methods should go into a java.util.Objects class in JDK 7?

[Ulf Zibis]

Am 12.10.2009 15:03, Ulf Zibis schrieb:
Additionally something like Path#unlock() would be helpful, if 
copy/delete fails. For example see: 
http://diamondcs.com.au/freeutilities/fileunlocker.php


Additionally see: http://ccollomb.free.fr/unlocker/

-Ulf

Re: What methods should go into a java.util.Objects class in JDK 7?

[Alan Bateman]

Ulf Zibis wrote:

:
Alan, that's cool, thanks. Hopefully this goes into trunk of JDK 7, (+ 
write access ?).

Can you give me direct link of ZipFileSystem.jar + javadoc + sources ?
Just clone the nio/nio repository. There's a README in 
jdk/src/share/demo/nio/ZipFileSystem.


If I run this example:
   System.out.println(
   
sun.nio.cs.ext.SJIS_0213.class.getResource("sjis0213.dat").toURI());

I get:
jar:file:/C:/Programme/Java/jdk1.7.0/fastdebug/jre/lib/charsets.jar!/sun/nio/cs/ext/sjis0213.dat 



This looks little different from your example (scheme + '!' instead '#').
Is that covered too by ZipFileSystem.jar ?
The URI syntax is defined by the provider and this demo provider uses 
hierarchical URIs with "zip" as the scheme. It wouldn't hard to wrap 
this provider with another that supports the legacy JAR URL syntax 
(although that syntax worries me in that it uses opaque URIs and will 
likely be a challenge if/when the platform is updated to support RFC 3986).


-Alan.

Re: What methods should go into a java.util.Objects class in JDK 7?

[Ulf Zibis]

Am 16.09.2009 18:08, Alan Bateman schrieb:

Joel Kamentz wrote:


:

Attempt to convert an URL to a local file, taking into 
account that it might be wrappered by jar:, that File.toURL doesn't 
process %20 and the like, etc.
  

File.toURL is deprecated. You might want to look at File.toURI.


Anyway, I would like to see zip/jar URIs as valid parameter to open a 
file/path/stream/channel via new File(URI) or Paths.get(URI).





Delete files or sub-trees, catching exceptions and instead 
just return success / failure.
  
This one comes up a lot and has been addressed in the file system API 
work in jdk7. So if you have a File f you can replace f.delete() with 
f.toPath().delete() and it will do what you want.


Recursive delete is relatively easy too, using Files.walkFileTree. 
There's an example in the javadoc that does this (look in 
java.nio.file.FileVisitor).


I would like to see some convenience methods for deleting/copying 
subtrees, without having to implement the FileVisitor examples.
Additionally something like Path#unlock() would be helpful, if 
copy/delete fails. For example see: 
http://diamondcs.com.au/freeutilities/fileunlocker.php


-Ulf

Re: What methods should go into a java.util.Objects class in JDK 7?

[Ulf Zibis]

+1

-Ulf


Am 16.09.2009 13:33, Stephen Colebourne schrieb:

2009/9/15 Martin Buchholz :
  

This test is particularly uninteresting.  I'll commit soon even if I
don't get any review comments.



 * Returns a hash code for this {...@code Byte}; equal to the result
 * of invoking {...@code intValue()}.

Doesn't this mean that the added part about intValue() will appear in
the summary text for the method in Javadoc? I'd consider the 'how the
method operates' to be detail, not summary, so would prefer:

 * Returns a hash code for this {...@code Byte}.
 * The hash code is equal to the result of invoking {...@code intValue()}.

Stephen


  

Re: What methods should go into a java.util.Objects class in JDK 7?

[Ulf Zibis]

Am 12.10.2009 15:43, Alan Bateman schrieb:

Ulf Zibis wrote:

:
Anyway, I would like to see zip/jar URIs as valid parameter to open a 
file/path/stream/channel via new File(URI) or Paths.get(URI).
There is a file system provider (albeit demo/prototype quality) for 
zip file in the nio repository. Just add ZipFileSystem.jar to your 
classpath and you can treat the contents of a zip or JAR file as a 
read-only file system. You can use URIs, such as 
zip:///home/foo.zip#/top/bar, to locate files if you wish.




Alan, that's cool, thanks. Hopefully this goes into trunk of JDK 7, (+ 
write access ?).

Can you give me direct link of ZipFileSystem.jar + javadoc + sources ?

If I run this example:
   System.out.println(
   
sun.nio.cs.ext.SJIS_0213.class.getResource("sjis0213.dat").toURI());

I get:
jar:file:/C:/Programme/Java/jdk1.7.0/fastdebug/jre/lib/charsets.jar!/sun/nio/cs/ext/sjis0213.dat

This looks little different from your example (scheme + '!' instead '#').
Is that covered too by ZipFileSystem.jar ?

-Ulf

Re: What methods should go into a java.util.Objects class in JDK 7?

[Alan Bateman]

Ulf Zibis wrote:

Am 12.10.2009 15:03, Ulf Zibis schrieb:
Additionally something like Path#unlock() would be helpful, if 
copy/delete fails. For example see: 
http://diamondcs.com.au/freeutilities/fileunlocker.php


Additionally see: http://ccollomb.free.fr/unlocker/
I assume this type of thing can lead to data loss and/or hard to 
diagnose corruption. If you are running into sharing violations then try 
out the file system API as the Windows provider opens files by default 
to allow delete access (ie: close to Unix semantics by default with 
provider specific options to control the DOS sharing mode if you really 
want). The only case where we still have a problem is memory-mapped 
files. Changing the long standing behavior of the java.io classes is 
another matter as that would likely break existing applications that 
rely on the current/long standing behavior.


-Alan.

Re: What methods should go into a java.util.Objects class in JDK 7?

[Alan Bateman]

Ulf Zibis wrote:

:
Anyway, I would like to see zip/jar URIs as valid parameter to open a 
file/path/stream/channel via new File(URI) or Paths.get(URI).
There is a file system provider (albeit demo/prototype quality) for zip 
file in the nio repository. Just add ZipFileSystem.jar to your classpath 
and you can treat the contents of a zip or JAR file as a read-only file 
system. You can use URIs, such as zip:///home/foo.zip#/top/bar, to 
locate files if you wish.


-Alan.

Re: What methods should go into a java.util.Objects class in JDK 7?

[Tom Hawtin]

Joseph D. Darcy wrote:

Classes with only private constructors, like j.u.Objects, are 
effectively final.  Adding final is harmless but unnecessary in these 
cases.  The platform is a bit inconsistent here; j.u.Collections is 
*not* marked final while j.l.Math is.


For a certain value of effective. *Current* *Java* *source* may not 
subclass a non-final class with only private constructors. I believe a 
verfiable subclass can be created as a class file that does not have a 
constructor (or possibly definitely throws an exception?). Unless 
something is seriously wrong, that shouldn't cause a security issue. It 
might be an issue for other languages on the JVM.


   In practice, it doesn't matter 
very much; I'll consider final-izing j.u.Objects on the next round of 
edits.


Oh don't put a finalizer on it. ;)

Tom Hawtin

Re: What methods should go into a java.util.Objects class in JDK 7?

[Paul Benedict]

My final comment on this trifling matter is regarding the
documentation. I don't think private methods/fields are included in
the JDK's javadoc. If the private constructor will not appear, I
recommend adding "final" and/or documenting the class as not
instantiable/subclassable. Now that I know the compiler will warn
about this issue (thank you Bob), the next consideration is for those
who are reading the docs online.

Paul

On Fri, Oct 9, 2009 at 9:07 PM, Bob Lee  wrote:
> On Fri, Oct 9, 2009 at 6:55 PM, Paul Benedict  wrote:
>>
>> Understood, but the keyword (pun) here is "effectively". Why let a
>> developer wait until runtime to find out his code will fail? At least
>> by marking the class as final, anybody who wishes to subclass it will
>> receive a compiler error. Rain on the parade early :-)
>
> Paul, this is caught at compile time, since you can't call the private
> constructor. The "final" would be redundant.
> Bob

Re: What methods should go into a java.util.Objects class in JDK 7?

[Paul Benedict]

Thank you, Bob. I stand corrected.

On Fri, Oct 9, 2009 at 9:07 PM, Bob Lee  wrote:
> On Fri, Oct 9, 2009 at 6:55 PM, Paul Benedict  wrote:
>>
>> Understood, but the keyword (pun) here is "effectively". Why let a
>> developer wait until runtime to find out his code will fail? At least
>> by marking the class as final, anybody who wishes to subclass it will
>> receive a compiler error. Rain on the parade early :-)
>
> Paul, this is caught at compile time, since you can't call the private
> constructor. The "final" would be redundant.
> Bob

Re: What methods should go into a java.util.Objects class in JDK 7?

[Bob Lee]

On Fri, Oct 9, 2009 at 6:55 PM, Paul Benedict  wrote:

> Understood, but the keyword (pun) here is "effectively". Why let a
> developer wait until runtime to find out his code will fail? At least
> by marking the class as final, anybody who wishes to subclass it will
> receive a compiler error. Rain on the parade early :-)
>

Paul, this is caught at compile time, since you can't call the private
constructor. The "final" would be redundant.

Bob

Re: What methods should go into a java.util.Objects class in JDK 7?

[Paul Benedict]

Joe,

> Classes with only private constructors, like j.u.Objects, are effectively
> final.  Adding final is harmless but unnecessary in these cases.

Understood, but the keyword (pun) here is "effectively". Why let a
developer wait until runtime to find out his code will fail? At least
by marking the class as final, anybody who wishes to subclass it will
receive a compiler error. Rain on the parade early :-)

Anyway, thanks for considering it in the next round.

Paul

Re: What methods should go into a java.util.Objects class in JDK 7?

[Joseph D. Darcy]

Paul Benedict wrote:

Joe,

I think java.util.Objects could benefit from the "final" modifier.
Since its constructor always fails, there is no reason to subclass it
(i.e., super constructor always fails). I believe Josh's "Effective
Java" book makes such a point about static utility classes.

Paul
  


Hello.

Classes with only private constructors, like j.u.Objects, are 
effectively final.  Adding final is harmless but unnecessary in these 
cases.  The platform is a bit inconsistent here; j.u.Collections is 
*not* marked final while j.l.Math is.  In practice, it doesn't matter 
very much; I'll consider final-izing j.u.Objects on the next round of edits.


-Joe

Re: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?]

[Joseph D. Darcy]

Eamonn McManus wrote:

David Holmes - Sun Microsystems wrote:
> So to me: String toString(Object o, String useIfNull) is the only 
method

> that provides true utility in this case.

I agree with that, and would just suggest to the person specifying the 
method
to add a @see String#valueOf(Object).  I find that the behaviour of 
that method


Agreed, that @see, amongst others, has been in the patch for this change

http://cr.openjdk.java.net/~darcy/6797535.1/

-Joe

Re: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?]

[Eamonn McManus]

David Holmes - Sun Microsystems wrote:
> So to me: String toString(Object o, String useIfNull) is the only method
> that provides true utility in this case.

I agree with that, and would just suggest to the person specifying the method
to add a @see String#valueOf(Object).  I find that the behaviour of that method
is usually exactly what I want when the argument is null (and I find the idea of
representing null by an empty string aberrant, but there you go), so for people 
like
me but who might not have noticed String.valueOf this will save them from 
peppering
Objects.toString(x, "null") throughout their programs.

Éamonn McManus · JMX Spec Lead · http://weblogs.java.net/blog/emcmanus


David Holmes - Sun Microsystems wrote:

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 defined to replace null with "null" (or replace a null from 
o.toString() with "null"). And I suspect that "null" was chosen over "" 
because it is then obvious when an unexpected null was encountered.


But Objects.toString(o) is not concerned with string concatenation so 
doesn't have to mimic that behaviour.


Personally I'd only put in the two-arg variant because:

a) a one-arg that simply forwards to String.valueOf is redundant as 
already discussed


b) a one-arg that hardwires the response to null (whether that be to 
return null or "null") will simply force the programmer to either switch 
to a different API or else add their own null handling logic - which 
defeats the purpose of putting in these utility/convenience methods.


So to me: String toString(Object o, String useIfNull) is the only method 
that provides true utility in this case.


David

Re: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?]

[Ulf Zibis]

Am 09.10.2009 01:53, David Holmes - Sun Microsystems schrieb:
So to me: String toString(Object o, String useIfNull) is the only 
method that provides true utility in this case.




I can follow this argumentation.
+1

-Ulf

Re: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?]

[David Holmes - Sun Microsystems]

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 defined to replace null with "null" (or replace a null from 
o.toString() with "null"). And I suspect that "null" was chosen over "" 
because it is then obvious when an unexpected null was encountered.


But Objects.toString(o) is not concerned with string concatenation so 
doesn't have to mimic that behaviour.


Personally I'd only put in the two-arg variant because:

a) a one-arg that simply forwards to String.valueOf is redundant as 
already discussed


b) a one-arg that hardwires the response to null (whether that be to 
return null or "null") will simply force the programmer to either switch 
to a different API or else add their own null handling logic - which 
defeats the purpose of putting in these utility/convenience methods.


So to me: String toString(Object o, String useIfNull) is the only method 
that provides true utility in this case.


David

Re: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?]

[Paul Benedict]

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 String/StringBuilder work with nulls is totally irrelevant
to how this class should behave. You are taking one use from one class
and making it the utility behavior for any object.

Paul

On Thu, Oct 8, 2009 at 1:30 PM, Joseph D. Darcy  wrote:
> 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 you are now
>> defining a global utility method for all objects, I think having
>> "null" being the de-facto string representation of null is simply
>> taking it too far.
>>
>
> System.out.println("" + referenceOfAnyType);
>
> will print "null" if referenceOfAnyType is null.
>
> This is what the platform has done since the beginning.
>
> -Joe
>
>

RE: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?]

[Jason Mehrens]

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

 

 

> Date: Thu, 8 Oct 2009 10:51:50 -0700
> From: joe.da...@sun.com
> Subject: Re: Objects.toString [Re: What methods should go into a 
> java.util.Objects class in JDK 7?]
> To: jason_mehr...@hotmail.com
> CC: core-libs-dev@openjdk.java.net


> I'm preparing the first round of java.util.Objects with the 
> single-argument static toString method return "null" for null for final 
> review. I'll send out a few follow-up emails, including one for 
> additional toStrings methods. I'm sympathetic to the two-argument 
> toString method with a default.

> -Joe

  
_
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/171222986/direct/01/

Re: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?]

[Joseph D. Darcy]

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 you are now
defining a global utility method for all objects, I think having
"null" being the de-facto string representation of null is simply
taking it too far.
  


System.out.println("" + referenceOfAnyType);

will print "null" if referenceOfAnyType is null.

This is what the platform has done since the beginning.

-Joe

Re: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?]

[Paul Benedict]

>> 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 utility method for all objects, I think having
"null" being the de-facto string representation of null is simply
taking it too far.

Paul

Re: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?]

[Joseph D. Darcy]

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 in string 
concatenation.



Everyone
who has opined did disagree with replicating String.valueOf()
behavior. 


The people who disagreed with the replication disagreed with the 
replication.  Others disagreed with the behavior.


-Joe

Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?]

[Paul Benedict]

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't see how this behavior is appropriate for all
objects: no data in should be no data (or at least empty data) going
out.

Paul

Re: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?]

[Joseph D. Darcy]

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-argument static toString method return "null" for null for final 
review.  I'll send out a few follow-up emails, including one for 
additional toStrings methods.  I'm sympathetic to the two-argument 
toString method with a default.


Project Jigsaw is about modularity so I don't see what connection there 
is between Jigsaw and j.u.Objects.


-Joe

 
Jason


 
> Date: Thu, 8 Oct 2009 11:47:49 +0100
> Subject: Objects.toString [Re: What methods should go into a 
java.util.Objects class in JDK 7?]

> From: scolebou...@joda.org
> To: core-libs-dev@openjdk.java.net
>
> 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
 




Hotmail: Powerful Free email with security by Microsoft. Get it now. 
<http://clk.atdmt.com/GBL/go/171222986/direct/01/>

RE: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?]

[Jason Mehrens]

+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 methods should go into a 
> java.util.Objects class in JDK 7?]
> From: scolebou...@joda.org
> To: core-libs-dev@openjdk.java.net
> 
> 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
 

  
_
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/171222986/direct/01/

Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?]

[Paul Benedict]

+1 for me.

+1 also for having the overloaded version that can accept a fallback string.

Paul

Re: Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?]

[Ulf Zibis]

+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 something
different and more useful).

In favour/against +1/-1 ?

Stephen

2009/10/7 Joseph D. Darcy :
  

David Holmes - Sun Microsystems wrote:


Stephen Colebourne said the following on 10/07/09 18:10:
  

BTW, I don't accept the argument that one and only one way to do
something is part of the JDK.


While the JDK is far from a model example of providing "one way" to do
something, that doesn't mean we should gratuitously add superfluous and
redundant functionality.
  

The JDK has a long history of providing convenience methods.  For example,
we have PrintStream.format and PrintStream.printf which are just two names
for the same functionality.



Type.valueOf is an established pattern for converting types.

The JDK is already severely bloated - new APIs should pay their own way.
  

Getting rid of more than half a dozen implementations of equals(Object,
Object) should just in the JDK should more than pay the for the entire
Objects class ;-)

-Joe






  

Objects.toString [Re: What methods should go into a java.util.Objects class in JDK 7?]

[Stephen Colebourne]

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 :
> David Holmes - Sun Microsystems wrote:
>>
>> Stephen Colebourne said the following on 10/07/09 18:10:
>>>
>>> BTW, I don't accept the argument that one and only one way to do
>>> something is part of the JDK.
>>
>> While the JDK is far from a model example of providing "one way" to do
>> something, that doesn't mean we should gratuitously add superfluous and
>> redundant functionality.
>
> The JDK has a long history of providing convenience methods.  For example,
> we have PrintStream.format and PrintStream.printf which are just two names
> for the same functionality.
>
>> Type.valueOf is an established pattern for converting types.
>>
>> The JDK is already severely bloated - new APIs should pay their own way.
>
> Getting rid of more than half a dozen implementations of equals(Object,
> Object) should just in the JDK should more than pay the for the entire
> Objects class ;-)
>
> -Joe
>
>

Re: What methods should go into a java.util.Objects class in JDK 7?

[Joseph D. Darcy]

David Holmes - Sun Microsystems wrote:

Stephen Colebourne said the following on 10/07/09 18:10:
BTW, I don't accept the argument that one and only one way to do 
something is part of the JDK. 


While the JDK is far from a model example of providing "one way" to do 
something, that doesn't mean we should gratuitously add superfluous 
and redundant functionality. 


The JDK has a long history of providing convenience methods.  For 
example, we have PrintStream.format and PrintStream.printf which are 
just two names for the same functionality.



Type.valueOf is an established pattern for converting types.

The JDK is already severely bloated - new APIs should pay their own way.


Getting rid of more than half a dozen implementations of equals(Object, 
Object) should just in the JDK should more than pay the for the entire 
Objects class ;-)


-Joe

RE: What methods should go into a java.util.Objects class in JDK 7?

[Jason Mehrens]

> Hi Stephen,
> 
> [...]
> > In key places there are multiple options. NIO Path vs File and 
> > Calendar vs Date are examples.
> 
> As you know, Path (resp. Calendar) is just an attempt to correct the 
> mess introduced by File (resp. Date).
> So yes, there is duplication but this duplication is done to correct a 
> wrong design.
> 
> > (Most code is written using IDEs these days, so having a predictable 
> > place to start from for autocomplete is important. Hence having 
> > equals/hashCode/compare but not toString would be very unintuitive to 
> > the Objects API).
> >
> > Stephen
> Rémi


The 2 toString variants from ObjectUtils are very handy to have for displaying 
values for UIs.  Perhaps those should be added to Objects to correct a wrong 
design (limited use) of returning "null" for null and would least provide new 
behavior.

Seems like the way to go unless these are going to cause more harm (confusion) 
than good.

 

Jason
  
_
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
http://clk.atdmt.com/GBL/go/177141664/direct/01/

Re: What methods should go into a java.util.Objects class in JDK 7?

[Rémi Forax]

Stephen Colebourne a écrit :

Paul Benedict wrote:

If you want Objects.toString() to provide value, consider mimicking
the functionality from Apache Commons:

http://commons.apache.org/lang/api-2.4/org/apache/commons/lang/ObjectUtils.html 



My biggest complaint about String.valueOf(Object) is that it will
actually return "null" for null objects. I can't stand that. If I have
no data, I don't want any printable data back. While my preference
might be too narrow for the JDK, the second overloaded version of
ObjectUtils#toString(String, String) seems like a winner to me. Allow
a default String to be provided when it is null:

public static String toString(Object o, String defaultStr) {
return (o != null) ? : String.valueOf(o) : defaultStr;
}




Hi Stephen,

[...]
In key places there are multiple options. NIO Path vs File and 
Calendar vs Date are examples.


As you know, Path (resp. Calendar) is just an attempt to correct the 
mess introduced by File (resp. Date).
So yes, there is duplication but this duplication is done to correct a 
wrong design.


(Most code is written using IDEs these days, so having a predictable 
place to start from for autocomplete is important. Hence having 
equals/hashCode/compare but not toString would be very unintuitive to 
the Objects API).


Stephen

Rémi

Re: What methods should go into a java.util.Objects class in JDK 7?

[Ulf Zibis]

Am 07.10.2009 01:43, Joe Darcy schrieb:


I don't think having a one-line forwarding method in Objects is that 
harmful.




On the other hand Character.MAX_SUPPLEMENTARY_CODE_POINT was rejected 
for JDK footprint reason.


-Ulf

Re: What methods should go into a java.util.Objects class in JDK 7?

[David Holmes - Sun Microsystems]

Stephen Colebourne said the following on 10/07/09 18:10:
BTW, I don't accept the argument that one and only one way to do 
something is part of the JDK. 


While the JDK is far from a model example of providing "one way" to do 
something, that doesn't mean we should gratuitously add superfluous and 
redundant functionality. Type.valueOf is an established pattern for 
converting types.


The JDK is already severely bloated - new APIs should pay their own way.

David

Re: What methods should go into a java.util.Objects class in JDK 7?

[Stephen Colebourne]

Paul Benedict wrote:

If you want Objects.toString() to provide value, consider mimicking
the functionality from Apache Commons:

http://commons.apache.org/lang/api-2.4/org/apache/commons/lang/ObjectUtils.html

My biggest complaint about String.valueOf(Object) is that it will
actually return "null" for null objects. I can't stand that. If I have
no data, I don't want any printable data back. While my preference
might be too narrow for the JDK, the second overloaded version of
ObjectUtils#toString(String, String) seems like a winner to me. Allow
a default String to be provided when it is null:

public static String toString(Object o, String defaultStr) {
return (o != null) ? : String.valueOf(o) : defaultStr;
}


I agree that this variant should be on Objects. To me, that strongly 
implies that the variant without the second argument should also be 
there (and yes, I'd prefer it to return "" instead of "null" for null).


BTW, I don't accept the argument that one and only one way to do 
something is part of the JDK. In key places there are multiple options. 
NIO Path vs File and Calendar vs Date are examples. (Most code is 
written using IDEs these days, so having a predictable place to start 
from for autocomplete is important. Hence having equals/hashCode/compare 
but not toString would be very unintuitive to the Objects API).


Stephen

Re: What methods should go into a java.util.Objects class in JDK 7?

[Paul Benedict]

Thanks Dave. You are exactly right. That implementation is better.

On Tue, Oct 6, 2009 at 11:56 PM, David Holmes - Sun Microsystems
 wrote:
> Paul,
>
> Paul Benedict said the following on 10/07/09 14:44:
>>
>> If you want Objects.toString() to provide value, consider mimicking
>> the functionality from Apache Commons:
>>
>>
>> http://commons.apache.org/lang/api-2.4/org/apache/commons/lang/ObjectUtils.html
>>
>> My biggest complaint about String.valueOf(Object) is that it will
>> actually return "null" for null objects. I can't stand that. If I have
>> no data, I don't want any printable data back. While my preference
>> might be too narrow for the JDK, the second overloaded version of
>> ObjectUtils#toString(String, String) seems like a winner to me. Allow
>> a default String to be provided when it is null:
>
> I can see this might be useful ...
>
>> public static String toString(Object o, String defaultStr) {
>>    return (o != null) ? String.valueOf(o) : defaultStr;
>> }
>
> but the implementation would just need to be:
>
>      return o != null ? o.toString() : defaultStr;
>
> Cheers,
> David

Re: What methods should go into a java.util.Objects class in JDK 7?

[David Holmes - Sun Microsystems]

Paul,

Paul Benedict said the following on 10/07/09 14:44:

If you want Objects.toString() to provide value, consider mimicking
the functionality from Apache Commons:

http://commons.apache.org/lang/api-2.4/org/apache/commons/lang/ObjectUtils.html

My biggest complaint about String.valueOf(Object) is that it will
actually return "null" for null objects. I can't stand that. If I have
no data, I don't want any printable data back. While my preference
might be too narrow for the JDK, the second overloaded version of
ObjectUtils#toString(String, String) seems like a winner to me. Allow
a default String to be provided when it is null:


I can see this might be useful ...


public static String toString(Object o, String defaultStr) {
return (o != null) ? : String.valueOf(o) : defaultStr;
}


but the implementation would just need to be:

  return o != null ? o.toString() : defaultStr;

Cheers,
David


Paul

Re: What methods should go into a java.util.Objects class in JDK 7?

[Martin Buchholz]

I also vote against Objects.toString().
Foo.valueOf might not be the best name,
(I'll resist the urge to suggest a better one)
but it is an entrenched convention,
and so cannot be considered a wart to be fixed.

Martin

On Tue, Oct 6, 2009 at 20:14, David Holmes - Sun Microsystems
 wrote:
> Joe,
>
> Joe Darcy said the following on 10/07/09 09:43:
>>
>> David Holmes - Sun Microsystems wrote:
>>>
>>> I thought the point that Jason Mehrens was making was that this:
>>>
>>> +    public static String toString(Object o) {
>>> +        String.valueOf(o); hat Jason Mehrens was making was that this:
>>>
>>> +    public static String toString(Object o) {
>>> +        String.valueOf(o);
>>> +    }
>>>
>>> is actually pointless. Why introduce
>>> +    }
>>>
>>> is actually pointless. Why introduce such redundancy when people can just
>>> use String.valueOf directly ?
>>
>> Because, IMO, String.valueOf is obscure and hard to find and from its name
>> it is not clear it does null-safe toString on the argument.  For example, I
>> didn't know about String.valueOf.  It is much clearer what Objects.toString
>> is intended to do.
>
> It is no more obscure or hard to find than any method one is unaware of. But
> if you look at any of a number of introductory Java texts - such as The Java
> Programming Language for example - you will find that valueOf is given good
> coverage along with the other members of the String class. Further, as David
> Lloyd points out, there is a strong convention that Type.valueOf(x) converts
> x to Type - so the Java programmer should be quite familiar with this
> concept.
>
> I agree the null behaviour is not evident from the name, but nor is it
> evident from the name toString either - in both cases you must initially
> check the specification of the method to know what it does.
>
>>> This doesn't provide any benefit.
>>
>> I think having the new method be commonly called would be a benefit :-)
>
> No more so than having String.valueOf commonly called.
>
>> I don't think having a one-line forwarding method in Objects is that
>> harmful.
>
> It is redundant and adds no value. It creates potential confusion because
> people will wonder why on earth you have two methods that do the exact same
> thing. (And it's a PITA for authors because it is yet another additional API
> they have to mention. ;-) )
>
> Just my opinion of course.
>
> David
> -
>>>
>>> PS. It should be "return String.valueOf(o);" of course.
>>
>> Fixed.
>>
>> Thanks,
>>
>> -Joe
>>
>>>
>>> David Holmes
>>>
>>> Joe Darcy said the following on 10/07/09 08:50:

 Joe Darcy wrote:
>
> Joe Darcy wrote:
>>
>> Joe Darcy wrote:
>>>
>>> Stephen Colebourne wrote:

 Joe Darcy wrote:
>
> What other utility methods would have broad enough use and
> applicability to go into a common java.util class?

 Joe,
 You've asked for a call for ideas, but not given any indication of
 process. Are you going to evaluate everything that comes in and pick 
 the
 best a la Coin? Or allow anyone to send in patches?
>>>
>>> Those options are not mutually exclusive; patches are welcome subject
>>> to the usual terms and conditions.
>>>
 Who decides what is in and what is out?
>>>
>>> This is a little side project of mine and I wanted to get some
>>> feedback before preparing a formal change for review, possibly including
>>> patches from others.
>>>
>>> -Joe
>>
>> I'm getting caught up after the JVM Languages Summit and will post
>> some java.util.Objects code for review in the near future.
>>
>> -Joe
>
> Below is a patch implementing the methods I think should go into
> java.util.Objects as a first cut:
>
> * null safe two-argument equals method
> * null safe hashCode(Object) returning 0 for null
> * null safe toString(Object), returning "null" for a null argument
> * null tolerating compare method; tests if both arguments are == and if
> not calls compare
>
> The need for the last of these in Objects isn't quite as clear.
>
> Var-arg-ifying some of the existing methods in Arrays,
> (hashCode(Object[]), deepHashCode(Object[]) and toString(Object[])), is
> probably worthwhile but can be done separately.
>
> I wouldn't oppose a toDebugString(Object) method going into the
> platform somewhere, but I don't think it necessarily belongs in Objects.
>
> Further below is the code for an annotation processor which finds
> candidate equals methods to be replaced with Objects.equals.  It found 
> over
> half a dozen good candidates in the jdk repository.  To run the annotation
> processor, first compile the class and then run it with javac similar to
> this:
>
> javac -proc:only -processor EqualsFinder -processorpath  processor> sources
>
> -Joe
>

 Updated p

Re: What methods should go into a java.util.Objects class in JDK 7?

[David Holmes - Sun Microsystems]

Joe,

Joe Darcy said the following on 10/07/09 09:43:

David Holmes - Sun Microsystems wrote:

I thought the point that Jason Mehrens was making was that this:

+public static String toString(Object o) {
+String.valueOf(o); hat Jason Mehrens was making was that this:

+public static String toString(Object o) {
+String.valueOf(o);
+}

is actually pointless. Why introduce
+}

is actually pointless. Why introduce such redundancy when people can 
just use String.valueOf directly ? 


Because, IMO, String.valueOf is obscure and hard to find and from its 
name it is not clear it does null-safe toString on the argument.  For 
example, I didn't know about String.valueOf.  It is much clearer what 
Objects.toString is intended to do.


It is no more obscure or hard to find than any method one is unaware of. 
But if you look at any of a number of introductory Java texts - such as 
The Java Programming Language for example - you will find that valueOf 
is given good coverage along with the other members of the String class. 
Further, as David Lloyd points out, there is a strong convention that 
Type.valueOf(x) converts x to Type - so the Java programmer should be 
quite familiar with this concept.


I agree the null behaviour is not evident from the name, but nor is it 
evident from the name toString either - in both cases you must initially 
check the specification of the method to know what it does.



This doesn't provide any benefit.


I think having the new method be commonly called would be a benefit :-)


No more so than having String.valueOf commonly called.

I don't think having a one-line forwarding method in Objects is that 
harmful.


It is redundant and adds no value. It creates potential confusion 
because people will wonder why on earth you have two methods that do the 
exact same thing. (And it's a PITA for authors because it is yet another 
additional API they have to mention. ;-) )


Just my opinion of course.

David
-


PS. It should be "return String.valueOf(o);" of course.


Fixed.

Thanks,

-Joe



David Holmes

Joe Darcy said the following on 10/07/09 08:50:

Joe Darcy wrote:

Joe Darcy wrote:

Joe Darcy wrote:

Stephen Colebourne wrote:

Joe Darcy wrote:
What other utility methods would have broad enough use and 
applicability to go into a common java.util class?


Joe,
You've asked for a call for ideas, but not given any indication 
of process. Are you going to evaluate everything that comes in 
and pick the best a la Coin? Or allow anyone to send in patches? 


Those options are not mutually exclusive; patches are welcome 
subject to the usual terms and conditions.



Who decides what is in and what is out?


This is a little side project of mine and I wanted to get some 
feedback before preparing a formal change for review, possibly 
including patches from others.


-Joe


I'm getting caught up after the JVM Languages Summit and will post 
some java.util.Objects code for review in the near future.


-Joe


Below is a patch implementing the methods I think should go into 
java.util.Objects as a first cut:


* null safe two-argument equals method
* null safe hashCode(Object) returning 0 for null
* null safe toString(Object), returning "null" for a null argument
* null tolerating compare method; tests if both arguments are == and 
if not calls compare


The need for the last of these in Objects isn't quite as clear.

Var-arg-ifying some of the existing methods in Arrays, 
(hashCode(Object[]), deepHashCode(Object[]) and toString(Object[])), 
is probably worthwhile but can be done separately.


I wouldn't oppose a toDebugString(Object) method going into the 
platform somewhere, but I don't think it necessarily belongs in 
Objects.


Further below is the code for an annotation processor which finds 
candidate equals methods to be replaced with Objects.equals.  It 
found over half a dozen good candidates in the jdk repository.  To 
run the annotation processor, first compile the class and then run 
it with javac similar to this:


javac -proc:only -processor EqualsFinder -processorpath processor> sources


-Joe



Updated patch of java.util.Objects with some spec clarifications 
suggested by Alan Bateman and the use of and reference to 
String.valueOf(Object) observed by Jason Mehrens.


-Joe


--- /dev/null2009-08-12 17:12:33.0 -0700
+++ new/src/share/classes/java/util/Objects.java2009-10-06 
15:47:16.0 -0700

@@ -0,0 +1,100 @@
+/*
+ * Copyright 2009 Sun Microsystems, Inc.  All Rights Reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.  Sun designates this
+ * particular file as subject to the "Classpath" exception as provided
+ * by Sun in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in 

Re: What methods should go into a java.util.Objects class in JDK 7?

[David M. Lloyd]

On 10/06/2009 06:43 PM, Joe Darcy wrote:

David Holmes - Sun Microsystems wrote:

Hi Joe,

I thought the point that Jason Mehrens was making was that this:

+ public static String toString(Object o) {
+ String.valueOf(o); hat Jason Mehrens was making was that this:

+ public static String toString(Object o) {
+ String.valueOf(o);
+ }

is actually pointless. Why introduce
+ }

is actually pointless. Why introduce such redundancy when people can
just use String.valueOf directly ?


Because, IMO, String.valueOf is obscure and hard to find and from its
name it is not clear it does null-safe toString on the argument. For
example, I didn't know about String.valueOf. It is much clearer what
Objects.toString is intended to do.


I for one never thought of it as obscure.  Isn't this one of the static 
methods one must know before taking the SCJP exam?  I'm sure it was one of 
the first methods I learned, back in the day.



This doesn't provide any benefit.


I think having the new method be commonly called would be a benefit :-)

I don't think having a one-line forwarding method in Objects is that
harmful.


Redundancy can be harmful in fact.  Now you've got two ways to do the exact 
same thing; it just makes it a little harder for people to develop and 
adhere to coding standards, to give one example.


- DML

Re: What methods should go into a java.util.Objects class in JDK 7?

[Joe Darcy]

David Holmes - Sun Microsystems wrote:

Hi Joe,

I thought the point that Jason Mehrens was making was that this:

+public static String toString(Object o) {
+String.valueOf(o); hat Jason Mehrens was making was that this:

+public static String toString(Object o) {
+String.valueOf(o);
+}

is actually pointless. Why introduce
+}

is actually pointless. Why introduce such redundancy when people can 
just use String.valueOf directly ? 


Because, IMO, String.valueOf is obscure and hard to find and from its 
name it is not clear it does null-safe toString on the argument.  For 
example, I didn't know about String.valueOf.  It is much clearer what 
Objects.toString is intended to do.



This doesn't provide any benefit.


I think having the new method be commonly called would be a benefit :-)

I don't think having a one-line forwarding method in Objects is that 
harmful.




PS. It should be "return String.valueOf(o);" of course.


Fixed.

Thanks,

-Joe



David Holmes

Joe Darcy said the following on 10/07/09 08:50:

Joe Darcy wrote:

Joe Darcy wrote:

Joe Darcy wrote:

Stephen Colebourne wrote:

Joe Darcy wrote:
What other utility methods would have broad enough use and 
applicability to go into a common java.util class?


Joe,
You've asked for a call for ideas, but not given any indication 
of process. Are you going to evaluate everything that comes in 
and pick the best a la Coin? Or allow anyone to send in patches? 


Those options are not mutually exclusive; patches are welcome 
subject to the usual terms and conditions.



Who decides what is in and what is out?


This is a little side project of mine and I wanted to get some 
feedback before preparing a formal change for review, possibly 
including patches from others.


-Joe


I'm getting caught up after the JVM Languages Summit and will post 
some java.util.Objects code for review in the near future.


-Joe


Below is a patch implementing the methods I think should go into 
java.util.Objects as a first cut:


* null safe two-argument equals method
* null safe hashCode(Object) returning 0 for null
* null safe toString(Object), returning "null" for a null argument
* null tolerating compare method; tests if both arguments are == and 
if not calls compare


The need for the last of these in Objects isn't quite as clear.

Var-arg-ifying some of the existing methods in Arrays, 
(hashCode(Object[]), deepHashCode(Object[]) and toString(Object[])), 
is probably worthwhile but can be done separately.


I wouldn't oppose a toDebugString(Object) method going into the 
platform somewhere, but I don't think it necessarily belongs in 
Objects.


Further below is the code for an annotation processor which finds 
candidate equals methods to be replaced with Objects.equals.  It 
found over half a dozen good candidates in the jdk repository.  To 
run the annotation processor, first compile the class and then run 
it with javac similar to this:


javac -proc:only -processor EqualsFinder -processorpath processor> sources


-Joe



Updated patch of java.util.Objects with some spec clarifications 
suggested by Alan Bateman and the use of and reference to 
String.valueOf(Object) observed by Jason Mehrens.


-Joe


--- /dev/null2009-08-12 17:12:33.0 -0700
+++ new/src/share/classes/java/util/Objects.java2009-10-06 
15:47:16.0 -0700

@@ -0,0 +1,100 @@
+/*
+ * Copyright 2009 Sun Microsystems, Inc.  All Rights Reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.  Sun designates this
+ * particular file as subject to the "Classpath" exception as provided
+ * by Sun in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but 
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of 
MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public 
License
+ * version 2 for more details (a copy is included in the LICENSE 
file that

+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License 
version
+ * 2 along with this work; if not, write to the Free Software 
Foundation,

+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa 
Clara,
+ * CA 95054 USA or visit www.sun.com if you need additional 
information or

+ * have any questions.
+ */
+
+package java.util;
+
+/**
+ * This class consists of {...@code static} utility methods for operating
+ * on objects.
+ *
+ * @since 1.7
+ */
+public class Objects {
+private Objects() {
+throw new AssertionError("No java.util.Objects instances for 
you!");

+}
+
+/**
+ * Returns {...@code true} if the arguments are equal to each other
+

Re: What methods should go into a java.util.Objects class in JDK 7?

[David Holmes - Sun Microsystems]

Hi Joe,

I thought the point that Jason Mehrens was making was that this:

+public static String toString(Object o) {
+String.valueOf(o);
+}

is actually pointless. Why introduce such redundancy when people can 
just use String.valueOf directly ? This doesn't provide any benefit.


PS. It should be "return String.valueOf(o);" of course.

David Holmes

Joe Darcy said the following on 10/07/09 08:50:

Joe Darcy wrote:

Joe Darcy wrote:

Joe Darcy wrote:

Stephen Colebourne wrote:

Joe Darcy wrote:
What other utility methods would have broad enough use and 
applicability to go into a common java.util class?


Joe,
You've asked for a call for ideas, but not given any indication of 
process. Are you going to evaluate everything that comes in and 
pick the best a la Coin? Or allow anyone to send in patches? 


Those options are not mutually exclusive; patches are welcome 
subject to the usual terms and conditions.



Who decides what is in and what is out?


This is a little side project of mine and I wanted to get some 
feedback before preparing a formal change for review, possibly 
including patches from others.


-Joe


I'm getting caught up after the JVM Languages Summit and will post 
some java.util.Objects code for review in the near future.


-Joe


Below is a patch implementing the methods I think should go into 
java.util.Objects as a first cut:


* null safe two-argument equals method
* null safe hashCode(Object) returning 0 for null
* null safe toString(Object), returning "null" for a null argument
* null tolerating compare method; tests if both arguments are == and 
if not calls compare


The need for the last of these in Objects isn't quite as clear.

Var-arg-ifying some of the existing methods in Arrays, 
(hashCode(Object[]), deepHashCode(Object[]) and toString(Object[])), 
is probably worthwhile but can be done separately.


I wouldn't oppose a toDebugString(Object) method going into the 
platform somewhere, but I don't think it necessarily belongs in Objects.


Further below is the code for an annotation processor which finds 
candidate equals methods to be replaced with Objects.equals.  It found 
over half a dozen good candidates in the jdk repository.  To run the 
annotation processor, first compile the class and then run it with 
javac similar to this:


javac -proc:only -processor EqualsFinder -processorpath processor> sources


-Joe



Updated patch of java.util.Objects with some spec clarifications 
suggested by Alan Bateman and the use of and reference to 
String.valueOf(Object) observed by Jason Mehrens.


-Joe


--- /dev/null2009-08-12 17:12:33.0 -0700
+++ new/src/share/classes/java/util/Objects.java2009-10-06 
15:47:16.0 -0700

@@ -0,0 +1,100 @@
+/*
+ * Copyright 2009 Sun Microsystems, Inc.  All Rights Reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.  Sun designates this
+ * particular file as subject to the "Classpath" exception as provided
+ * by Sun in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but 
WITHOUT

+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License 
version

+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa 
Clara,

+ * CA 95054 USA or visit www.sun.com if you need additional information or
+ * have any questions.
+ */
+
+package java.util;
+
+/**
+ * This class consists of {...@code static} utility methods for operating
+ * on objects.
+ *
+ * @since 1.7
+ */
+public class Objects {
+private Objects() {
+throw new AssertionError("No java.util.Objects instances for 
you!");

+}
+
+/**
+ * Returns {...@code true} if the arguments are equal to each other
+ * and {...@code false} otherwise.
+ * Consequently, if both arguments are {...@code null}, {...@code true}
+ * is returned and if exactly one argument is {...@code null}, {...@code
+ * false} is returned.  Otherwise, equality is determined by using
+ * the {...@link Object#equals equals} method of the first
+ * argument.
+ *
+ * @return {...@code true} if the arguments are equal to each other
+ * and {...@code false} otherwise
+ * @see Object#equals(Object)
+ */
+public static boolean equals(Object a, Object b) {
+return (a == b) || (a != null && a.equals(b));
+}
+
+/**
+ 

Re: What methods should go into a java.util.Objects class in JDK 7?

[Joe Darcy]

Joe Darcy wrote:

Joe Darcy wrote:

Joe Darcy wrote:

Stephen Colebourne wrote:

Joe Darcy wrote:
What other utility methods would have broad enough use and 
applicability to go into a common java.util class?


Joe,
You've asked for a call for ideas, but not given any indication of 
process. Are you going to evaluate everything that comes in and 
pick the best a la Coin? Or allow anyone to send in patches? 


Those options are not mutually exclusive; patches are welcome 
subject to the usual terms and conditions.



Who decides what is in and what is out?


This is a little side project of mine and I wanted to get some 
feedback before preparing a formal change for review, possibly 
including patches from others.


-Joe


I'm getting caught up after the JVM Languages Summit and will post 
some java.util.Objects code for review in the near future.


-Joe


Below is a patch implementing the methods I think should go into 
java.util.Objects as a first cut:


* null safe two-argument equals method
* null safe hashCode(Object) returning 0 for null
* null safe toString(Object), returning "null" for a null argument
* null tolerating compare method; tests if both arguments are == and 
if not calls compare


The need for the last of these in Objects isn't quite as clear.

Var-arg-ifying some of the existing methods in Arrays, 
(hashCode(Object[]), deepHashCode(Object[]) and toString(Object[])), 
is probably worthwhile but can be done separately.


I wouldn't oppose a toDebugString(Object) method going into the 
platform somewhere, but I don't think it necessarily belongs in Objects.


Further below is the code for an annotation processor which finds 
candidate equals methods to be replaced with Objects.equals.  It found 
over half a dozen good candidates in the jdk repository.  To run the 
annotation processor, first compile the class and then run it with 
javac similar to this:


javac -proc:only -processor EqualsFinder -processorpath processor> sources


-Joe



Updated patch of java.util.Objects with some spec clarifications 
suggested by Alan Bateman and the use of and reference to 
String.valueOf(Object) observed by Jason Mehrens.


-Joe


--- /dev/null2009-08-12 17:12:33.0 -0700
+++ new/src/share/classes/java/util/Objects.java2009-10-06 
15:47:16.0 -0700

@@ -0,0 +1,100 @@
+/*
+ * Copyright 2009 Sun Microsystems, Inc.  All Rights Reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.  Sun designates this
+ * particular file as subject to the "Classpath" exception as provided
+ * by Sun in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License 
version

+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
+ * CA 95054 USA or visit www.sun.com if you need additional information or
+ * have any questions.
+ */
+
+package java.util;
+
+/**
+ * This class consists of {...@code static} utility methods for operating
+ * on objects.
+ *
+ * @since 1.7
+ */
+public class Objects {
+private Objects() {
+throw new AssertionError("No java.util.Objects instances for 
you!");

+}
+
+/**
+ * Returns {...@code true} if the arguments are equal to each other
+ * and {...@code false} otherwise.
+ * Consequently, if both arguments are {...@code null}, {...@code true}
+ * is returned and if exactly one argument is {...@code null}, {...@code
+ * false} is returned.  Otherwise, equality is determined by using
+ * the {...@link Object#equals equals} method of the first
+ * argument.
+ *
+ * @return {...@code true} if the arguments are equal to each other
+ * and {...@code false} otherwise
+ * @see Object#equals(Object)
+ */
+public static boolean equals(Object a, Object b) {
+return (a == b) || (a != null && a.equals(b));
+}
+
+/**
+ * Returns the hash code of a no...@code null} argument and 0 for
+ * a {...@code null} argument.
+ *
+ * @return the hash code of a no...@code null} argument and 0 for
+ * a {...@code null} argument
+ * @see Object#hashCode
+ */
+public static int hashCode(Object o) {
+return o != null ? o.hashCode() : 0;
+}
+
+/**
+ * Returns the result of calling {...@code toString} for 

RE: What methods should go into a java.util.Objects class in JDK 7?

[Jason Mehrens]

> I think a better name would be "defaultToString" since it is the default 
> toString from Object. However, I haven't ever heard anyone else request 
> easier access to the default toString before so I'm not convinced this 
> should go into Objects.
> 
> -Joe

 

One use case is implementing toString for identity maps and collections.  The 
current IdentityHashMap is immune to poison objects except for its toString 
implementation. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6579224

 

Another point of confusion is that the toString does not match what is going on 
in equals.  Take the following code:

 

 public static void main(String[] args) {
Map dis = 
new IdentityHashMap(one());
Map dat = 
new IdentityHashMap(one());

System.out.println(dis.equals(dat));
System.out.println(dis.toString().equals(dat.toString()));
  }

  private static Map one() {
Integer kv = new Integer(256);
return Collections.singletonMap(kv, kv);
  }

 

 

It prints false and then true.  If defaultToString was used on the key/value 
pairs it would print false and then false making it clear why the two maps are 
not equal.  Something to consider if a new reference map or identity map is 
added to the JDK (jsr166/extra166y).

 

Jason


 
  
_
Hotmail: Free, trusted and rich email service.
http://clk.atdmt.com/GBL/go/171222984/direct/01/

Re: What methods should go into a java.util.Objects class in JDK 7?

[Joe Darcy]

Jason Mehrens wrote:

> By toIdentityString, do you mean the String that would be returned by
> toString if toString is not overridden?
>
> -Joe

Yep.  As in:
 
return o != null ? o.getClass().getName() +'@' +  
Integer.toHexString(System.identityHashCode(o)) : "null";
 
I suppose the name should be identityToString to match 
System.identityHashCode???
 
Jason


I think a better name would be "defaultToString" since it is the default 
toString from Object.  However, I haven't ever heard anyone else request 
easier access to the default toString before so I'm not convinced this 
should go into Objects.


-Joe

RE: What methods should go into a java.util.Objects class in JDK 7?

[Jason Mehrens]

> By toIdentityString, do you mean the String that would be returned by 
> toString if toString is not overridden?
> 
> -Joe


Yep.  As in:

 

return o != null ? o.getClass().getName() +'@'+  
Integer.toHexString(System.identityHashCode(o)) : "null";

 

I suppose the name should be identityToString to match 
System.identityHashCode???

 

Jason
  
_
Insert movie times and more without leaving Hotmail®.
http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd_062009

Re: What methods should go into a java.util.Objects class in JDK 7?

[Joseph D. Darcy]

Jason Mehrens wrote:

Joe,

 > * null safe toString(Object), returning "null" for a null argument
 
Doesn't String.valueOf do the same thing?
http://java.sun.com/javase/6/docs/api/java/lang/String.html#valueOf(java.lang.Object 
)


Indeed it does!  I'll replace the implementation with a call to 
String.valueOf and update the javadoc accordingly.  Thanks for spotting 
this.


What about a toIdentityString(Object) instead?  Some of the nice 
properties of an identity string is that it is safe to


By toIdentityString, do you mean the String that would be returned by 
toString if toString is not overridden?


-Joe

call from multiple threads even on objects that are not thread safe 
(JComponent), won't deadlock if toString is synchronized (observed in 
logging), and won't build run away strings (nCopies(Integer.MAX_VALUE, 
"lookout").toString()).
 
Jason



Hotmail® has ever-growing storage! Don’t worry about storage limits. 
Check it out. 

RE: What methods should go into a java.util.Objects class in JDK 7?

[Schulz, Stefan]

> Joe Darcy wrote:
> * null safe two-argument equals method
> 
> +public static boolean equals(Object a, Object b) {
> +return (a == b) || (a != null && a.equals(b));
> +}

While I agree this being helpful, as I earlier stated, it would be nice to have 
a (additional?) method that takes arrays into account as well, as equals() only 
does an identity check on arrays. In the current situation, one has to check 
for arrays before using either equals() or Arrays.deepEquals(), which makes 
Object.equals() pointless as identity and null-check are already done.

Thanks,
Stefan

RE: What methods should go into a java.util.Objects class in JDK 7?

[Jason Mehrens]

Joe,


 > * null safe toString(Object), returning "null" for a null argument

 

Doesn't String.valueOf do the same thing?
http://java.sun.com/javase/6/docs/api/java/lang/String.html#valueOf(java.lang.Object)

 

What about a toIdentityString(Object) instead?  Some of the nice properties of 
an identity string is that it is safe to call from multiple threads even on 
objects that are not thread safe (JComponent), won't deadlock if toString is 
synchronized (observed in logging), and won't build run away strings 
(nCopies(Integer.MAX_VALUE, "lookout").toString()).

 

Jason
  
_
Hotmail® has ever-growing storage! Don’t worry about storage limits.
http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage_062009

Re: What methods should go into a java.util.Objects class in JDK 7?

[Ulf Zibis]

Am 02.10.2009 06:23, Joe Darcy schrieb:


I wouldn't oppose a toDebugString(Object) method going into the 
platform somewhere, but I don't think it necessarily belongs in Objects.


I suggest new class java.util.Debug to contain this and many other 
thinkable helper methods useful for developers.




Further below is the code for an annotation processor which finds 
candidate equals methods to be replaced with Objects.equals.  It found 
over half a dozen good candidates in the jdk repository.  To run the 
annotation processor, first compile the class and then run it with 
javac similar to this:


javac -proc:only -processor EqualsFinder -processorpath processor> sources




That's very cool.

-Ulf

Re: What methods should go into a java.util.Objects class in JDK 7?

[Joe Darcy]

Joe Darcy wrote:

Joe Darcy wrote:

Stephen Colebourne wrote:

Joe Darcy wrote:
What other utility methods would have broad enough use and 
applicability to go into a common java.util class?


Joe,
You've asked for a call for ideas, but not given any indication of 
process. Are you going to evaluate everything that comes in and pick 
the best a la Coin? Or allow anyone to send in patches? 


Those options are not mutually exclusive; patches are welcome subject 
to the usual terms and conditions.



Who decides what is in and what is out?


This is a little side project of mine and I wanted to get some 
feedback before preparing a formal change for review, possibly 
including patches from others.


-Joe


I'm getting caught up after the JVM Languages Summit and will post 
some java.util.Objects code for review in the near future.


-Joe


Below is a patch implementing the methods I think should go into 
java.util.Objects as a first cut:


* null safe two-argument equals method
* null safe hashCode(Object) returning 0 for null
* null safe toString(Object), returning "null" for a null argument
* null tolerating compare method; tests if both arguments are == and if 
not calls compare


The need for the last of these in Objects isn't quite as clear.

Var-arg-ifying some of the existing methods in Arrays, 
(hashCode(Object[]), deepHashCode(Object[]) and toString(Object[])), is 
probably worthwhile but can be done separately.


I wouldn't oppose a toDebugString(Object) method going into the platform 
somewhere, but I don't think it necessarily belongs in Objects.


Further below is the code for an annotation processor which finds 
candidate equals methods to be replaced with Objects.equals.  It found 
over half a dozen good candidates in the jdk repository.  To run the 
annotation processor, first compile the class and then run it with javac 
similar to this:


javac -proc:only -processor EqualsFinder -processorpath processor> sources


-Joe

--- old/make/java/java/FILES_java.gmk2009-10-01 21:04:12.0 -0700
+++ new/make/java/java/FILES_java.gmk2009-10-01 21:04:12.0 -0700
@@ -258,6 +258,7 @@
java/util/ServiceConfigurationError.java \
java/util/Timer.java \
java/util/TimerTask.java \
+java/util/Objects.java \
java/util/UUID.java \
java/util/concurrent/AbstractExecutorService.java \
java/util/concurrent/ArrayBlockingQueue.java \
--- /dev/null2009-08-12 17:12:33.0 -0700
+++ new/src/share/classes/java/util/Objects.java2009-10-01 
21:04:13.0 -0700

@@ -0,0 +1,96 @@
+/*
+ * Copyright 2009 Sun Microsystems, Inc.  All Rights Reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.  Sun designates this
+ * particular file as subject to the "Classpath" exception as provided
+ * by Sun in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License 
version

+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
+ * CA 95054 USA or visit www.sun.com if you need additional information or
+ * have any questions.
+ */
+
+package java.util;
+
+/**
+ * This class consists of {...@code static} utility methods for operating
+ * on objects.
+ */
+public class Objects {
+private Objects() {
+throw new AssertionError("No java.util.Objects instances for 
you!");

+}
+
+/**
+ * Returns {...@code true} if the arguments are equal to each other
+ * and {...@code false} otherwise.
+ * Consequently, if both arguments are {...@code null} {...@code true}
+ * is returned and if exactly one argument is {...@code null} {...@code
+ * false} is returned.  Otherwise, equality is determined by using
+ * the {...@link Object#equals equals} method of the first
+ * argument.
+ *
+ * @return {...@code true} if the arguments are equal to each other
+ * and {...@code false} otherwise
+ * @see Object#equals(Object)
+ * @since 1.7
+ */
+public static boolean equals(Object a, Object b) {
+return (a == b) || (a != null && a.equals(b));
+}
+
+/**
+ * Returns the hash code of a no...@code null} argument and 0 for
+ * a {...@code null} argument.
+ *
+ * @return the hash code of a no...@code null} argument and 0 for
+ * 

Re: What methods should go into a java.util.Objects class in JDK 7?

[Joe Darcy]

Joe Darcy wrote:

Stephen Colebourne wrote:

Joe Darcy wrote:
What other utility methods would have broad enough use and 
applicability to go into a common java.util class?


Joe,
You've asked for a call for ideas, but not given any indication of 
process. Are you going to evaluate everything that comes in and pick 
the best a la Coin? Or allow anyone to send in patches? 


Those options are not mutually exclusive; patches are welcome subject 
to the usual terms and conditions.



Who decides what is in and what is out?


This is a little side project of mine and I wanted to get some 
feedback before preparing a formal change for review, possibly 
including patches from others.


-Joe


I'm getting caught up after the JVM Languages Summit and will post some 
java.util.Objects code for review in the near future.


-Joe

Re: What methods should go into a java.util.Objects class in JDK 7?

[Alan Bateman]

Joel Kamentz wrote:

:
}

static void close(InputStream s) {
if (s == null) return;
try { s.close(); }
catch (IOException e) {}
}

... repeat for other stream types as necessary, like ZipFile, 
RandomAccessFile, etc. because no common inheritance
  
Just on this one, maybe you are looking for java.io.Closeable? ZipFile 
was updated to implement it a while back. Then again, perhaps Closeable 
is too general because you wouldn't want to do this with output or other 
writable streams (because of possible data loss if the close needs to 
flush buffered bytes and it fails).




:

Attempt to convert an URL to a local file, taking into account that it 
might be wrappered by jar:, that File.toURL doesn't process %20 and the like, 
etc.
  

File.toURL is deprecated. You might want to look at File.toURI.



Delete files or sub-trees, catching exceptions and instead just return 
success / failure.
  
This one comes up a lot and has been addressed in the file system API 
work in jdk7. So if you have a File f you can replace f.delete() with 
f.toPath().delete() and it will do what you want.


Recursive delete is relatively easy too, using Files.walkFileTree. 
There's an example in the javadoc that does this (look in 
java.nio.file.FileVisitor).



Copy an InputStream to an OutputStream with supplied byte buffer (or 
allocate one internally).  General file (or stream or ?) copying utility 
methods might be useful.
  
File copy is supported in the file system API. Look at Path.copyTo. It 
has options to indicate if the target file should be replaced, if file 
attributes should be copied, etc.


In the nio repository there are prototype java.io.Inputs and 
java.io.Outputs classes that define static methods for useful/common 
tasks like reading all bytes or lines from a file or input stream. There 
is also a method to copy all bytes from an input stream to an output 
stream. It's on my list to finish this off and get them into jdk7.


-Alan.

Re: What methods should go into a java.util.Objects class in JDK 7?

[David M. Lloyd]

On 09/16/2009 10:20 AM, Joel Kamentz wrote:

It's more for I/O, not general Object, but some methods which I almost ALWAYS 
use in a project are null-safe canonicalization and null-safe close methods.


Yeah I think that these would belong in an I/O package.  That said...


static File canonical(File f) {
if (f == null) return null;
try { return f.getCanonicalFile(); }
catch (IOException e) { return f.getAbsoluteFile(); }
}


No comment, other than to check out the NIO list archives and/or the 
current source tree which may already allow you to do this.



static void close(Reader s) {
if (s == null) return;
try { s.close(); }
catch (IOException e) {}
}


These would be better written as a single "close(Closeable c)".  Also, 
swallowing the exception is the wrong thing to do; at the very least it 
should be logged.



... repeat for other stream types as necessary, like ZipFile, 
RandomAccessFile, etc. because no common inheritance


These *should* all be fixed now to implement Closeable IIRC.


Delete files or sub-trees, catching exceptions and instead just return 
success / failure.

Copy an InputStream to an OutputStream with supplied byte buffer (or 
allocate one internally).  General file (or stream or ?) copying utility 
methods might be useful.


Definitely in the I/O realm, ask Alan on the NIO list.  The delete thing 
might already be done :)


- DML

RE: What methods should go into a java.util.Objects class in JDK 7?

[Joel Kamentz]

It's more for I/O, not general Object, but some methods which I almost ALWAYS 
use in a project are null-safe canonicalization and null-safe close methods.

static File canonical(File f) {
if (f == null) return null;
try { return f.getCanonicalFile(); }
catch (IOException e) { return f.getAbsoluteFile(); }
}

static void close(Reader s) {
if (s == null) return;
try { s.close(); }
catch (IOException e) {}
}

static void close(Writer s) {
if (s == null) return;
try { s.close(); }
catch (IOException e) {}
}

static void close(InputStream s) {
if (s == null) return;
try { s.close(); }
catch (IOException e) {}
}

... repeat for other stream types as necessary, like ZipFile, 
RandomAccessFile, etc. because no common inheritance

In some projects I've changed the above to instead have the pattern of

static IOException close(InputStream s) {
if (s != null) {
try { s.close(); }
catch (IOException e) { return e; }
}
return null;
}


IMO, these are quite general in use as one should always clean up and close 
after I/O, but if the rest of it succeeded, one rarely cares if the close 
method hiccups:

InputStream s = null;
try {
s = new FileInputStream(...);
...
} catch (IOException e) {
// if handling instead of throwing to caller
} finally { close(s); }



I also think join methods would be useful for strings / collections of strings 
or similar.


Other things I often do are:

Attempt to convert an URL to a local file, taking into account that it 
might be wrappered by jar:, that File.toURL doesn't process %20 and the like, 
etc.

Delete files or sub-trees, catching exceptions and instead just return 
success / failure.

Copy an InputStream to an OutputStream with supplied byte buffer (or 
allocate one internally).  General file (or stream or ?) copying utility 
methods might be useful.

Sometimes I want strings sorted case-insensitively, but without losing 
case (or during equals comparison).


Joel



-Original Message-
From: core-libs-dev-boun...@openjdk.java.net 
[mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf Of Ryan Slobojan
Sent: Friday, September 11, 2009 10:39 AM
To: core-libs-dev@openjdk.java.net
Subject: Re: What methods should go into a java.util.Objects class in JDK 7?

> Hello.
>
> For JDK 7, I think it is high-time the platform included a class like
> java.util.Objects to hold commonly-written utility methods.  For
> example, a two-argument static equals method that returned true if
> both
> arguments are null, returns false is one argument is null, and
> otherwise
> returns the result of calling arg1.equals(arg2)  (6797535 "Add shared
> two argument static equals method to the platform").
>
> A static hashCode method returning 0 for null and the value of
> arg.hashCode() has also been suggested.
>
> A set of
>
> static int compareTo(int, int)
> static int compareTo(long, long)
> 
>
> methods probably belongs somewhere in the platform too.
>
> What other utility methods would have broad enough use and
> applicability
> to go into a common java.util class?
>
> -Joe
Hi,

As a note, I've just put up an article about this on InfoQ soliciting
feedback from the wider Java community:

http://www.infoq.com/news/2009/09/jdk7-java-utils-object

Thanks,

Ryan Slobojan

Re: What methods should go into a java.util.Objects class in JDK 7?

[Stephen Colebourne]

2009/9/15 Martin Buchholz :
> This test is particularly uninteresting.  I'll commit soon even if I
> don't get any review comments.

 * Returns a hash code for this {...@code Byte}; equal to the result
 * of invoking {...@code intValue()}.

Doesn't this mean that the added part about intValue() will appear in
the summary text for the method in Javadoc? I'd consider the 'how the
method operates' to be detail, not summary, so would prefer:

 * Returns a hash code for this {...@code Byte}.
 * The hash code is equal to the result of invoking {...@code intValue()}.

Stephen

Re: What methods should go into a java.util.Objects class in JDK 7?

[Martin Buchholz]

> Martin,
>
> Just to be clear, I approve this change of tightening the hashCode
> specifications for Byte, Short, and Character going back into JDK 7.

I added a test case, as I half-promised,

http://cr.openjdk.java.net/~martin/webrevs/openjdk7/hashCode-spec/

This test is particularly uninteresting.  I'll commit soon even if I
don't get any review comments.

Martin

Re: What methods should go into a java.util.Objects class in JDK 7?

[Martin Buchholz]

I added a test case, as I half-promised,

http://cr.openjdk.java.net/~martin/webrevs/openjdk7/compare/

This test is particularly uninteresting.  I'll commit soon even if I
don't get any review comments.

Martin


On Fri, Sep 11, 2009 at 13:07, Joseph D. Darcy wrote:
> Joe Darcy wrote:

>
> The paperwork has been handled; I approve your set of compare methods going
> back.
>
> Thanks,
>
> -Joe
>

Re: What methods should go into a java.util.Objects class in JDK 7?

[Goktug Gokdogan]

Similarly, I've previously written reflection-based #clone, #equals, and
#fillRandomData methods working on POJOs. They were useful especially in
testing the data binding codes, ie.  X original = new X();,
  fillRandomData(original);
  mapper.toGUI( clone(original) ); //Clone object so original data can not
be modified
  X rv = new X();
  mapper.fromGUI(rv);
  assertTrue( equals(original, rv) );

But I can not imagine much use in a production code. If other use cases can
be suggested, we could consider putting into Objects class.


On Thu, Sep 10, 2009 at 2:25 AM, Kevin Bourrillion wrote:

> -1 on reflection-based stuff in the Objects class.
>
> equal() and hashCode() are the only two things we saw fit to include in our
> Objects class, and actually, our hashCode() is identical to
> Arrays.hashCode() (but is varargs).
>
>
> http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/base/Objects.html
>
> Please do add the compare() methods to all the rest of the wrapper types;
> we would use those a lot.
>
> When it comes to cloning, I tried very hard once to provide something
> useful -- a "clone any object without knowing its concrete type" method --
> and it was a disaster.  A total mess of reflection, and no one wanted to use
> it anyway.  Cloning in Java is discredited.
>
> So I'm left with only equal() for your new Objects class.  By the way, the
> best implementation is a == b || (a != null && a.equals(b)).
>
>
>
>
> On Wed, Sep 9, 2009 at 2:22 PM, Andrew John Hughes <
> gnu_and...@member.fsf.org> wrote:
>
>> 2009/9/9 Joe Darcy :
>> > Hello.
>> >
>> > For JDK 7, I think it is high-time the platform included a class like
>> > java.util.Objects to hold commonly-written utility methods.  For
>> example, a
>> > two-argument static equals method that returned true if both arguments
>> are
>> > null, returns false is one argument is null, and otherwise returns the
>> > result of calling arg1.equals(arg2)  (6797535 "Add shared two argument
>> > static equals method to the platform").
>> >
>> > A static hashCode method returning 0 for null and the value of
>> > arg.hashCode() has also been suggested.
>> >
>> > A set of
>> >
>> >   static int compareTo(int, int)
>> >   static int compareTo(long, long)
>> >   
>> >
>> > methods probably belongs somewhere in the platform too.
>> >
>> > What other utility methods would have broad enough use and applicability
>> to
>> > go into a common java.util class?
>> >
>> > -Joe
>> >
>>
>> Given you've listed utility methods for two Object methods, equals and
>> hashCode, toString seems an obvious one to handle as well:
>>
>> public static String toString(Object o)
>>  throws IllegalAccessException
>> {
>>  Class c = o.getClass();
>>  StringBuilder b = new StringBuilder(c.getName());
>>  b.append("[");
>>  for (Field f : c.getDeclaredFields())
>>  {
>>f.setAccessible(true);
>>b.append(f.getName() + "=" + f.get());
>>b.append(",");
>>  }
>>  b.replace(b.length() - 1, b.length(), "]");
>>  return b.toString();
>> }
>>
>> Maybe there's also a useful utility implementation of clone too, but I
>> can't think of one offhand.
>> --
>> Andrew :-)
>>
>> Free Java Software Engineer
>> Red Hat, Inc. (http://www.redhat.com)
>>
>> Support Free Java!
>> Contribute to GNU Classpath and the OpenJDK
>> http://www.gnu.org/software/classpath
>> http://openjdk.java.net
>>
>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
>>
>
>
>
> --
> Kevin Bourrillion @ Google
> internal:  http://go/javalibraries
> google-collections.googlecode.com
> google-guice.googlecode.com
>
>

Re: What methods should go into a java.util.Objects class in JDK 7?

[Joe Darcy]

Stephen Colebourne wrote:

Joe Darcy wrote:
What other utility methods would have broad enough use and 
applicability to go into a common java.util class?


Joe,
You've asked for a call for ideas, but not given any indication of 
process. Are you going to evaluate everything that comes in and pick 
the best a la Coin? Or allow anyone to send in patches? 


Those options are not mutually exclusive; patches are welcome subject to 
the usual terms and conditions.



Who decides what is in and what is out?


This is a little side project of mine and I wanted to get some feedback 
before preparing a formal change for review, possibly including patches 
from others.


-Joe

Re: What methods should go into a java.util.Objects class in JDK 7?

[Joseph D. Darcy]

Joe Darcy wrote:

Martin Buchholz wrote:

On Wed, Sep 9, 2009 at 17:34, Joe Darcy wrote:
 

Martin Buchholz wrote:
   

Google would like to contribute implementations of the methods below.
Here's a webrev:

http://cr.openjdk.java.net/~martin/webrevs/openjdk7/compare/

  

Wherever these compare methods go, into the N wrapper classes or into
java.util.Compare,



Given the precedent of Double.compare(double,double) and
Float.compare(float,float), I think the compare methods need
to go into the primitive wrapper classes.

 I think the instance method compareTo should be rewritten
 

in terms of the new static compare.  In particular,

422 public int compareTo(Short anotherShort) {
423 return this.value - anotherShort.value;
424 }

should get replaced with

422 public int compareTo(Short anotherShort) {
423 return compare(this.value, anotherShort.value);
424 }



As you wish.

Webrev updated.
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/compare/
  


I approve these changes in an engineering sense; they are a fix for bug

6582946 Add suite of compare(T, T) methods for ints, longs etc


This consolidates the comparison logic in a single method per type and
reuses the existing implementation tests.




 
(Later in JDK 7, a set of "unsignedCompare" methods are possible 
additions

to the platform too.)

   
We have tests (not yet included) but they would need to be 
jtreg-ified.

Is there any junit support yet for jtreg?

  

No.

Once the home of the new methods is determined, I'll file a ccc 
request so

these changes can go back after any additional testing is settled.



There's not a whole lot of testing work here, but we will provide it if
it CCC is approved.

  

I've created a ccc for this and will let you know when it is approved.

-Joe



Martin,

The paperwork has been handled; I approve your set of compare methods 
going back.


Thanks,

-Joe

Re: What methods should go into a java.util.Objects class in JDK 7?

[Joseph D. Darcy]

Joe Darcy wrote:

Martin Buchholz wrote:

On Thu, Sep 10, 2009 at 16:48, Joe Darcy wrote:

Martin Buchholz wrote:

On Thu, Sep 10, 2009 at 15:48, Joe Darcy wrote:


On 09/09/09 08:01 PM, Joe Darcy wrote:
I noticed that the Character class should be similarly tightened:


Right you are.  Webrev regenerated.

Martin

One typo inherited from my earlier suggestion (mea culpa!): as the 
Character

class is not a java.lang.Number, it does not have an intValue method.
 Character does have a charValue method and referring to that method 
in the

specification of hashCode should suffice.

I approve this change going back with the correction to the 
Character class.


Oops!  so many little mistakes. Webrev regenerated.


Looks good.

-Joe



Martin,

Just to be clear, I approve this change of tightening the hashCode 
specifications for Byte, Short, and Character going back into JDK 7.


Thanks,

-Joe

Re: What methods should go into a java.util.Objects class in JDK 7?

[Ryan Slobojan]

Hello.

For JDK 7, I think it is high-time the platform included a class like
java.util.Objects to hold commonly-written utility methods.  For
example, a two-argument static equals method that returned true if  
both
arguments are null, returns false is one argument is null, and  
otherwise

returns the result of calling arg1.equals(arg2)  (6797535 "Add shared
two argument static equals method to the platform").

A static hashCode method returning 0 for null and the value of
arg.hashCode() has also been suggested.

A set of

static int compareTo(int, int)
static int compareTo(long, long)


methods probably belongs somewhere in the platform too.

What other utility methods would have broad enough use and  
applicability

to go into a common java.util class?

-Joe

Hi,

As a note, I've just put up an article about this on InfoQ soliciting  
feedback from the wider Java community:


http://www.infoq.com/news/2009/09/jdk7-java-utils-object

Thanks,

Ryan Slobojan

Re: What methods should go into a java.util.Objects class in JDK 7?

[David Holmes - Sun Microsystems]

Ulf Zibis said the following on 09/11/09 17:00:

Am 11.09.2009 01:56, Martin Buchholz schrieb:

On Thu, Sep 10, 2009 at 16:48, Joe Darcy wrote:
 
I approve this change going back with the correction to the Character 
class.



Oops!  so many little mistakes. Webrev regenerated.
  


Is that webrev public anywhere ?


All Martin's webrevs are public:

http://cr.openjdk.java.net/~martin/webrevs/openjdk7/

This one was:

http://cr.openjdk.java.net/~martin/webrevs/openjdk7/hashCode

-David


(Hopefully you consider my "cosmetics" and some of my changes from [1] 
some day)


-Ulf

[1] https://bugs.openjdk.java.net/show_bug.cgi?id=100104

Re: What methods should go into a java.util.Objects class in JDK 7?

[Ulf Zibis]

Am 11.09.2009 01:56, Martin Buchholz schrieb:

On Thu, Sep 10, 2009 at 16:48, Joe Darcy wrote:
  
I approve this change going back with the correction to the Character 
class.




Oops!  so many little mistakes. Webrev regenerated.
  


Is that webrev public anywhere ?

(Hopefully you consider my "cosmetics" and some of my changes from [1] 
some day)


-Ulf

[1] https://bugs.openjdk.java.net/show_bug.cgi?id=100104

Re: What methods should go into a java.util.Objects class in JDK 7?

[Joe Darcy]

Martin Buchholz wrote:

On Thu, Sep 10, 2009 at 16:48, Joe Darcy wrote:

Martin Buchholz wrote:

On Thu, Sep 10, 2009 at 15:48, Joe Darcy wrote:


On 09/09/09 08:01 PM, Joe Darcy wrote:
I noticed that the Character class should be similarly tightened:


Right you are.  Webrev regenerated.

Martin


One typo inherited from my earlier suggestion (mea culpa!): as the Character
class is not a java.lang.Number, it does not have an intValue method.
 Character does have a charValue method and referring to that method in the
specification of hashCode should suffice.

I approve this change going back with the correction to the Character class.


Oops!  so many little mistakes. Webrev regenerated.


Looks good.

-Joe

Re: What methods should go into a java.util.Objects class in JDK 7?

[Stephen Colebourne]

Joe Darcy wrote:
What other utility methods would have broad enough use and applicability 
to go into a common java.util class?


Joe,
You've asked for a call for ideas, but not given any indication of 
process. Are you going to evaluate everything that comes in and pick the 
best a la Coin? Or allow anyone to send in patches? Who decides what is 
in and what is out?


Since its obviously not going to be decided by a Java SE 7 JSR, it would 
be useful to know the answers, before we all waste lots of time on 
discussions about methods that might or might not be used.


Stephen

Re: What methods should go into a java.util.Objects class in JDK 7?

[Martin Buchholz]

On Thu, Sep 10, 2009 at 16:48, Joe Darcy wrote:
> Martin Buchholz wrote:
>>
>> On Thu, Sep 10, 2009 at 15:48, Joe Darcy wrote:
>>
>>>
>>> On 09/09/09 08:01 PM, Joe Darcy wrote:
>>> I noticed that the Character class should be similarly tightened:
>>>
>>
>> Right you are.  Webrev regenerated.
>>
>> Martin
>>
>
> One typo inherited from my earlier suggestion (mea culpa!): as the Character
> class is not a java.lang.Number, it does not have an intValue method.
>  Character does have a charValue method and referring to that method in the
> specification of hashCode should suffice.
>
> I approve this change going back with the correction to the Character class.

Oops!  so many little mistakes. Webrev regenerated.

Martin

Re: What methods should go into a java.util.Objects class in JDK 7?

[Joe Darcy]

Martin Buchholz wrote:

On Thu, Sep 10, 2009 at 15:48, Joe Darcy wrote:
  

On 09/09/09 08:01 PM, Joe Darcy wrote:
I noticed that the Character class should be similarly tightened:



Right you are.  Webrev regenerated.

Martin
  


One typo inherited from my earlier suggestion (mea culpa!): as the 
Character class is not a java.lang.Number, it does not have an intValue 
method.  Character does have a charValue method and referring to that 
method in the specification of hashCode should suffice.


I approve this change going back with the correction to the Character class.

Thanks,

-Joe

Re: What methods should go into a java.util.Objects class in JDK 7?

[Martin Buchholz]

On Thu, Sep 10, 2009 at 15:48, Joe Darcy wrote:
> On 09/09/09 08:01 PM, Joe Darcy wrote:
> I noticed that the Character class should be similarly tightened:

Right you are.  Webrev regenerated.

Martin

Re: What methods should go into a java.util.Objects class in JDK 7?

[Joe Darcy]

On 09/09/09 08:01 PM, Joe Darcy wrote:

Martin Buchholz wrote:

On Wed, Sep 9, 2009 at 17:40, Joe Darcy wrote:
 

PS This talk of hashing remind me of a small spec cleanup:
4245470 algorithm of java.lang.Byte.hashCode() is not specified
http://bugs.sun.com/view_bug.do?bug_id=4245470




http://cr.openjdk.java.net/~martin/webrevs/openjdk7/hashCode-spec/

Martin
  


I'll work on the archeology to verify this behavior has been 
consistent over time and thus is reasonable to tighten the spec in 
these cases.


-Joe


Martin,

I noticed that the Character class should be similarly tightened:

/**
* Returns a hash code for this {...@code Character}; equal to the result
* of invoking {...@code intValue()}.
*
* @return a hash code value for this {...@code Character}
*/
   public int hashCode()

I've done some checking and all of the following Sun JDKs implement the 
"intValue" hashCode for Byte, Character, and Short:


1.1
1.2
1.3.0
1.3.1
1,4.0
1.4.1
1.4.2
1.5
1.6

so I think a change to all three wrapper classes is safe to go back from 
a behavioral compatibility perspective :-)


-Joe

Re: What methods should go into a java.util.Objects class in JDK 7?

[Rémi Forax]

Le 10/09/2009 04:11, Martin Buchholz a écrit :

On Wed, Sep 9, 2009 at 17:54, Rémi Forax  wrote:
   

Le 10/09/2009 02:15, Martin Buchholz a écrit :
 

Here's a bunch of static hashCode methods for primitives:

http://cr.openjdk.java.net/~martin/webrevs/openjdk7/hashCode/

This doesn't include a

public static int hashCode(object x) { return x == null ? 0 :
x.hashCode(); }

that I think was also being asked for, and which might be a candidate
for Objects.

Martin

   

Martin,
You forget java.lang.Boolean in your patch set :)
 

Rémi, merci beaucoup.
Les Booleans, je les avaient oubliée.

Mes patchs pour les classes wrapper,
tous les deux, maintenant incluent Boolean.

http://cr.openjdk.java.net/~martin/webrevs/openjdk7/hashCode/
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/compare/

Martin
   


Wow, you're able to write in French.
From now onwards, I will write my email to you in French :)

Rémi

   

Rémi

 

Re: What methods should go into a java.util.Objects class in JDK 7?

[Schulz, Stefan]

> So I'm left with only equal() for your new Objects class.  By the way, 
> the best implementation is a == b || (a != null && a.equals(b)).

I disagree, as this one does not handle arrays properly.
I'd either like equal to handle deep equality on arrays or have a deepEqual 
utility method that takes arbitrary objects.

Cheers,
Stefan

Re: What methods should go into a java.util.Objects class in JDK 7?

[Joseph D. Darcy]

Mike Morris wrote:

Joe Darcy wrote:

For JDK 7, I think it is high-time the platform included a class like 
java.util.Objects to hold commonly-written utility methods.  For 

...
What other utility methods would have broad enough use and 
applicability to go into a common java.util class?


Ah! Let's just go back to coding in C, then. I cannot see any 
justification for everything and the kitchen-sink being glommed into 
the Java APIs. If people want these sort of static methods, they're 
pretty-much all available in other libraries (Apache Commons, etc.)


The methods being discussed are generaly short and while easy to write, 
all of them aren't so easy to write that they cannot have bugs.  To me, 
the existence of these methods in multiple other libraries argues for 
putting robust version of them in the JDK since it is not worthwhile 
adding a library dependency just to get a static two argument equals method.


-Joe

Re: What methods should go into a java.util.Objects class in JDK 7?

[Andrew John Hughes]

2009/9/10 Ulf Zibis :
> Am 10.09.2009 01:54, Stephen Colebourne schrieb:
>>
>> There is also a case for methods to convert arrays of wrappers to
>> arrays of primitives.
>>
>
> +1
> - I guess, you mean also vice versa
> - Maybe would become superfluous, if HotSpot internally would compile to
> primitive arrays. (just a raw thought)
>

Except that what's being proposed here results in a spec. change and
will be available regardless of VM.  We shouldn't go on relying on
features of certain VMs.
There are other VMs than HotSpot you know! :)

> 19) re-usability of java.nio.Buffer (saves multiple instantiation):
> - X-Buffer#clear(x[] buf); clears all pointers
> - X-Buffer#reset(x[] buf); only resets pos to mark (maybe limit to array
> size), allows to process different data in same/similar/synchronous manner.
>
> -Ulf
>
>
>
>
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

Re: What methods should go into a java.util.Objects class in JDK 7?

[Andrew John Hughes]

2009/9/10 Ulf Zibis :
> Am 10.09.2009 02:04, Rémi Forax schrieb:
>>
>> Le 10/09/2009 01:43, Andrew John Hughes a écrit :  I agree about the
>> debugging purpose, that why I don't agree
>> with Kevin when he said that java.util.Objects should not use
>> reflection.
>>
>> Perhaps the method can be renamed to: toDebugString.
>>
>> Rémi
>> PS: the code above also forget inherited fields.
>>
> Maybe another class: java.util.Debug / DebugHelpers / DebugUtils
>
> I guess, there are many ideas around to fill such a class with useful
> things.
>
>
> -Ulf
>
>
>

Yeah you are probably right, my suggestion seems to come from a
different avenue than the others here.
It's probably because personally I've never used library method to do
such simple null checks; it might have fixed a few bugs for me along
the road, but I just prefer to check such things locally than add in
the overhead of a method call.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

Re: What methods should go into a java.util.Objects class in JDK 7?

[Ulf Zibis]

Am 10.09.2009 05:45, Reinier Zwitserloot schrieb:


A trick I'm reverting to rather a lot of late is to find my own jar 
file by getting a URL to my own class file as a resource, resolved 
against my own class, and then parsing this URL for the jar bit of it. 
(MyClassName.class.getResource("MyClassName.class")). There are a 
bunch of caveats here, mostly revolving around the notion that you may 
not have been loaded as a jar file, but as a directory, or via the 
network, or from a database, or who knows how? - but that's what 
returning "null" is for, surely. Something to consider, though I'm not 
entirely convinced this hack should be made legitimate by turning it 
into a library method. I doubt it's a good fit for Objects, in any case.


I guess you mean:
MyClassName.class.getResource("MyClassSimpleName.class")

I would like File(URI uri) to accept jar URI's, so it would be possible 
to get a nio channel access to a jared resource.


Or even better:
MyClassName.class.getResourceAsChannel("MyResourceName"))

-Ulf

Re: What methods should go into a java.util.Objects class in JDK 7?

[Ulf Zibis]

Am 10.09.2009 02:15, Martin Buchholz schrieb:

Here's a bunch of static hashCode methods for primitives:

http://cr.openjdk.java.net/~martin/webrevs/openjdk7/hashCode/
  


Can't this be solved by extending auto-boxing capabilities? :
   long l = 1234567890;
   int hash = l.hashCode();

-Ulf

Re: What methods should go into a java.util.Objects class in JDK 7?

[Ulf Zibis]

Am 10.09.2009 02:04, Martin Buchholz schrieb:

Is there any junit support yet for jtreg?
  


+1 to have this.

-Ulf

Re: What methods should go into a java.util.Objects class in JDK 7?

[Ulf Zibis]

Am 10.09.2009 01:54, Stephen Colebourne schrieb:


There is also a case for methods to convert arrays of wrappers to
arrays of primitives.
  


+1
- I guess, you mean also vice versa
- Maybe would become superfluous, if HotSpot internally would compile to 
primitive arrays. (just a raw thought)


19) re-usability of java.nio.Buffer (saves multiple instantiation):
- X-Buffer#clear(x[] buf); clears all pointers
- X-Buffer#reset(x[] buf); only resets pos to mark (maybe limit to array 
size), allows to process different data in same/similar/synchronous manner.


-Ulf

Re: What methods should go into a java.util.Objects class in JDK 7?

[Ulf Zibis]

Am 10.09.2009 02:04, Rémi Forax schrieb:
Le 10/09/2009 01:43, Andrew John Hughes a écrit :  
I agree about the debugging purpose, that why I don't agree

with Kevin when he said that java.util.Objects should not use
reflection.

Perhaps the method can be renamed to: toDebugString.

Rémi
PS: the code above also forget inherited fields.


Maybe another class: java.util.Debug / DebugHelpers / DebugUtils

I guess, there are many ideas around to fill such a class with useful 
things.



-Ulf

Re: What methods should go into a java.util.Objects class in JDK 7?

[Mike Morris]

Joe Darcy wrote:

For JDK 7, I think it is high-time the platform included a class like 
java.util.Objects to hold commonly-written utility methods.  For 

...
What other utility methods would have broad enough use and applicability 
to go into a common java.util class?


Ah! Let's just go back to coding in C, then. I cannot see any 
justification for everything and the kitchen-sink being glommed into the 
Java APIs. If people want these sort of static methods, they're 
pretty-much all available in other libraries (Apache Commons, etc.)


Must they /really/ be added to the morass that the Java APIs have become?

(Sorry: As a non-contributor I probably don't have the mana to make such 
a comment, but this proposal really punches a lot of my buttons.)


--
mike morris :: mikro2nd (at) gmail (dot) com

http://mikro2nd.net/
http://mikro2nd.net/blog/planb/
http://mikro2nd.net/blog/mike/

This email is [X]bloggable [ ]ask-first [ ]private

Re: What methods should go into a java.util.Objects class in JDK 7?

[Reinier Zwitserloot]

Late to the thread, so many one-liners to various ideas uttered on the  
list:


--

This is great stuff folks. As long as I get my String.join (or  
Collections.join, or Arrays.join, or Whatever.join, as long as there's  
a join!), of course :)


--

The compareTo methods for Integer/Short/Byte/Long (Character?) should  
clearly go in the respective wrapper classes for consistency's sake,  
but there's nothing in the way of ALSO making a utilities class of  
sorts that contains all the primitive compareTo methods as well, if  
that seems useful.


--

A trick I'm reverting to rather a lot of late is to find my own jar  
file by getting a URL to my own class file as a resource, resolved  
against my own class, and then parsing this URL for the jar bit of it.  
(MyClassName.class.getResource("MyClassName.class")). There are a  
bunch of caveats here, mostly revolving around the notion that you may  
not have been loaded as a jar file, but as a directory, or via the  
network, or from a database, or who knows how? - but that's what  
returning "null" is for, surely. Something to consider, though I'm not  
entirely convinced this hack should be made legitimate by turning it  
into a library method. I doubt it's a good fit for Objects, in any case.


--

Whatever hashCode() implementation is decided on, it should probably  
mirror the way IDEs generate it when you ask them to. Specifically:


Use deepHashCode for object arrays. Yes, this means you'll get  
StackOverflows if an array contains itself. This is either (A) the  
correct action, or (B) ArrayList is broken, as it has the same  
behaviour.


Split up longs via XOR, and doubles via toLongBits -> XOR. There's  
loads of alternative algorithms that purport to be more efficient, but  
without specific domain knowledge, xor is hard to beat.


Project Lombok sticks to this plan, which is mostly derived from  
Effective Java, IIRC. Same goes for equals and toString.


--

How does Joe Average Java Programmer tell the difference between  
Objects.equals(), which simply adds null friendliness, and a  
reflection-based pseudo-automagical hashCode builder?


--

Changing Arrays.deepEquals and friends to varargs has the same problem  
as Arrays.asList for 'list literals': What do list literals and null- 
friendly equals/hashCode/toString implements have to do with arrays?  
Nothing. There's a reason google went out of their way to dress up  
"ImmutableList.of(a, b, c);" as a library, after all. Even without the  
Collections.unmodifiableList() wrapper call, Arrays.asList() is  
unwieldly and a pretty bad implementation leakage - you're trying to  
build an immutable list; the fact that you're doing so by varargsing  
your arguments into an array and turning THAT into a list is not  
something you should be confronted with when reading code. I'd much  
prefer a solution that did not involve java.util.Arrays.


--

toString() is not supposed to be something you ever rely upon, and I  
furthermore have a rather hard time imagining anybody can possibly be  
relying on the random-esque default toString() implementation, which  
combines a memory pointer with a class name. So, would it be an option  
to change toString()'s implementation to do the sane thing?  
Arrays.toString (deepToString? That can cause StackOverflows...) for  
arrays, and some reflection-based magic otherwise? Changing equals()  
and hashCode() is not so simply modified without causing serious  
backwards compatibility issues, unfortunately.



 --Reinier Zwitserloot

Re: What methods should go into a java.util.Objects class in JDK 7?

[Joe Darcy]

Martin Buchholz wrote:

On Wed, Sep 9, 2009 at 17:40, Joe Darcy wrote:
  

PS This talk of hashing remind me of a small spec cleanup:
4245470 algorithm of java.lang.Byte.hashCode() is not specified
http://bugs.sun.com/view_bug.do?bug_id=4245470




http://cr.openjdk.java.net/~martin/webrevs/openjdk7/hashCode-spec/

Martin
  


I'll work on the archeology to verify this behavior has been consistent 
over time and thus is reasonable to tighten the spec in these cases.


-Joe

Re: What methods should go into a java.util.Objects class in JDK 7?

[Martin Buchholz]

On Wed, Sep 9, 2009 at 17:40, Joe Darcy wrote:
>
> PS This talk of hashing remind me of a small spec cleanup:
> 4245470 algorithm of java.lang.Byte.hashCode() is not specified
> http://bugs.sun.com/view_bug.do?bug_id=4245470
>

http://cr.openjdk.java.net/~martin/webrevs/openjdk7/hashCode-spec/

Martin