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
2009/11/16 David Holmes - Sun Microsystems david.hol...@sun.com:
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
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
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
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
Le 16/11/2009 00:48, Martin Buchholz a écrit :
On Sat, Nov 14, 2009 at 20:46, David Holmes - Sun Microsystems
david.hol...@sun.com 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:
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
*
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
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.
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
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
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
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.
+1
-Ulf
Am 16.09.2009 13:33, Stephen Colebourne schrieb:
2009/9/15 Martin Buchholz marti...@google.com:
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
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
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
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
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:
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
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
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
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).
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
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
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
On Fri, Oct 9, 2009 at 6:55 PM, Paul Benedict pbened...@apache.org 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
Thank you, Bob. I stand corrected.
On Fri, Oct 9, 2009 at 9:07 PM, Bob Lee crazy...@crazybob.org wrote:
On Fri, Oct 9, 2009 at 6:55 PM, Paul Benedict pbened...@apache.org wrote:
Understood, but the keyword (pun) here is effectively. Why let a
developer wait until runtime to find out his code
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
+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
+1 for me.
+1 also for having the overloaded version that can accept a fallback string.
Paul
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
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
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
Why would you choose to return null for any null object?
Because that is how the platform has always treated null in string
concatenation.
If you were defining new operations for String, StringBuilder, or
StringBuffer, I would agree with your choice. Since you are now
defining a global
Paul Benedict wrote:
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
: 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
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
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
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
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
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
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
*
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.
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) {
+
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
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
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
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
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
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
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() +'@' mailto:+...@%27+
Integer.toHexString(System.identityHashCode(o)) : null;
I suppose the
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
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
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
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
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
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
Joe Darcy wrote:
Martin Buchholz wrote:
On Thu, Sep 10, 2009 at 16:48, Joe Darcyjoe.da...@sun.com wrote:
Martin Buchholz wrote:
On Thu, Sep 10, 2009 at 15:48, Joe Darcyjoe.da...@sun.com wrote:
On 09/09/09 08:01 PM, Joe Darcy wrote:
I noticed that the Character class should be similarly
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
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
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)
Am 10.09.2009 02:04, Martin Buchholz schrieb:
Is there any junit support yet for jtreg?
+1 to have this.
-Ulf
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.
2009/9/10 Ulf Zibis ulf.zi...@gmx.de:
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
2009/9/10 Ulf Zibis ulf.zi...@gmx.de:
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
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!
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
On 09/09/09 08:01 PM, Joe Darcy wrote:
Martin Buchholz wrote:
On Wed, Sep 9, 2009 at 17:40, Joe Darcyjoe.da...@sun.com wrote:
PS This talk of hashing remind me of a small spec cleanup:
4245470 algorithm of java.lang.Byte.hashCode() is not specified
Martin Buchholz wrote:
On Thu, Sep 10, 2009 at 15:48, Joe Darcyjoe.da...@sun.com 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
On Thu, Sep 10, 2009 at 16:48, Joe Darcyjoe.da...@sun.com wrote:
Martin Buchholz wrote:
On Thu, Sep 10, 2009 at 15:48, Joe Darcyjoe.da...@sun.com 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
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
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
2009/9/9 Joe Darcy joe.da...@sun.com:
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
Le 09/09/2009 22:40, Joe Darcy a écrit :
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
-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).
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).
Le 09/09/2009 23:22, Andrew John Hughes a écrit :
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();
2009/9/10 Rémi Forax fo...@univ-mlv.fr:
Le 09/09/2009 23:22, Andrew John Hughes a écrit :
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
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
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, I think the instance method
Martin Buchholz wrote:
Here's a bunch of static hashCode methods for primitives:
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/hashCode/
Hmm, I'd be more inclined to group these methods into Objects as part of
a universal hash functionality.
This doesn't include a
public static
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
On Wed, Sep 9, 2009 at 17:34, Joe Darcyjoe.da...@sun.com 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
Martin Buchholz wrote:
On Wed, Sep 9, 2009 at 17:34, Joe Darcyjoe.da...@sun.com 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
84 matches
Mail list logo
