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

+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 dependen

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

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

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

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 prefe

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

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

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

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 pre

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

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...

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

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?

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: /** * S

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

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 >> *

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

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 B

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

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

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

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 * @r

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

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 defaul

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

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 on

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

Ulf Zibis wrote: : In java.nio.file.Filesystem b72 I don't find information about sharing attributes. These are provider specific open options so they aren't in the javadoc. If you look at the dosSharingOptionTests in jdk/test/java/nio/Path/SBC.java you will see tests for these options. -Ala

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

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

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

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?

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

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

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.toUR

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

+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 intV

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

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.

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

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 ca

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

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

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

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 effectiv

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

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

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

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

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

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. Rai

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

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 t

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

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

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

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

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

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)

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

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 behavio

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

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?]

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

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

Joe, I understand your point, and that's why I countered with my String and StringBuilder points. Those two classes are used underneath the covers for inline concatenation, but, again, java.util.Objects has grander intentions than string concatenation. This class is for all objects, and however St

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

ors 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

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

Paul Benedict wrote: Why would you choose to return "null" for any null object? Because that is how the platform has always treated null in string concatenation. If you were defining new operations for String, StringBuilder, or StringBuffer, I would agree with your choice. Since yo

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

>> 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

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

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

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

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'

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

27;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

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

: 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 t

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

+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?]

+1 or drop Objects.toString(obj) completely. -Ulf Am 08.10.2009 12:47, Stephen Colebourne schrieb: A number of us are proposing that Objects.toString(obj) should return "" when the object is null. I'm strongly in favour of this, and it removes any discussion of duplicated API (as it does somet

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

A number of us are proposing that Objects.toString(obj) should return "" when the object is null. I'm strongly in favour of this, and it removes any discussion of duplicated API (as it does something different and more useful). In favour/against +1/-1 ? Stephen 2009/10/7 Joseph D. Darcy : > Davi

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

Joe, Here are a few more resources that you may want to investigate for java.util.Objects: * http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/base/Objects.html * http://static.springsource.org/spring/docs/3.0.0.M4/javadoc-api/org/springframework/util/ObjectUtils.html

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

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 w

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

> 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

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

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 t

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

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?

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 an

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

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

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

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

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

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)

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

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 c

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

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, >

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

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 stati

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

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

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

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.

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

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.

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

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 y

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

> 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 toSt

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

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

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

> 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 identityToStr

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

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

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

> 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 t

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

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 id

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

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.

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

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 evalua

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

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

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

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

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

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 canonic

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

: 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-argu

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

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() wil

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

> 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 uninterest

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

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 pap

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

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 dat

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

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

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

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 compa

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

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 reg

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 retur

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

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

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

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

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

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

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

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 al

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

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. >> >>

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

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!): a

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

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?

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:/

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

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

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

> 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 tak

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

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! L

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

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 > prim

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

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 re

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

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("MyCla

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

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?

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?

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)

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

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 co

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

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

  1   2   >