Am 09.09.2009 03:52, Martin Buchholz schrieb:
I wish there had been more collaboration between the
jdk developers (including myself) and the icu
developers in the past. There has certainly been
a fair amount of duplication of effort in the
character encoding area.
Maybe it would be better t
Changeset: 8252729d51a3
Author:mullan
Date: 2009-09-09 09:54 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8252729d51a3
6745437: Add option to only check revocation of end-entity certificate in a
chain of certificates
6869739: Cannot check revocation of single certificate w
Martin, Brandon, Alan
I still believe the best choice at this moment is to be a little more
conservative, given the DOS.flush() has been
working in this behavior for decade. The proposed methods are good
enough to serve the functionality required,
I don't think it is worth breaking the compatib
I really don't understand this. I think just about everyone would
expect that flush on an output stream means send all the data I've
written. There are a large number of people who have stumbled on this
bug and several others, and the fact that it wasn't fixed when it was
discovered 10 years ago
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
return
Xueming Shen wrote:
Martin, Brandon, Alan
I still believe the best choice at this moment is to be a little more
conservative, given the DOS.flush() has been
working in this behavior for decade. The proposed methods are good
enough to serve the functionality required,
I don't think it is worth
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
I sometime too feels the same frustration when get kicked by the
compatibility, especially if you have to
back out hundreds of lines of code just because it is "incompatible". I
guess someone said it right a while
ago, the compatibility sucks, but yes, MOST end user/developer like it.
I disa
JDK has often chosen compatibility over doing something Right.
I think the risk of performance degradation due to frequent calls to
flush() is higher than one might think at first. Calls to flush may be
made on one's behalf by some middleware between the user
and the DOS. E.g. someone might wrap
Changeset: f1eb4c28b313
Author:lancea
Date: 2009-09-09 20:15 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f1eb4c28b313
6737212: Fixed javadoc warning messages in RowSet classes
Reviewed-by: darcy
! src/share/classes/com/sun/rowset/JdbcRowSetResourceBundle.java
! src/share/
Joe Darcy writes:
> 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.
Althou
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 o
-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/comm
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
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();
StringBuil
2009/9/10 Rémi Forax :
> 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
>> {
Le 10/09/2009 01:43, Andrew John Hughes a écrit :
2009/9/10 Rémi Forax:
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(Ob
2009/9/9 Joe Darcy :
> What other utility methods would have broad enough use and applicability to
> go into a common java.util class?
Well, my first selection is here
http://www.jroller.com/scolebourne/entry/jdk_7_method_suggestions
To keep the discussion here valid too, I'll paste it below:
Ste
Google would like to contribute implementations of the methods below.
Here's a webrev:
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/compare/
We have tests (not yet included) but they would need to be jtreg-ified.
Is there any junit support yet for jtreg?
Martin
On Wed, Sep 9, 2009 at 16:
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 co
It is believed that the java memory model allows Class.getName()
to return null.
This is one of those methods with an intentional data race.
Probably this has not been seen in practice because only
a perverse or adversarial runtime would load the "name" field
twice, out-of-order, as it seems to be
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 bei
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 cla
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, i
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
I've updated the hashCode patch to include Booleans
and similar refactoring as in compare.
We could do worse than to do hashCode in a totally
analogous fashion to compare, but I could also see
them incorporated into a static HashCodes class.
If you put one into Objects, then the primitive hashCode
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/
Mar
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/op
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/Lo
31 matches
Mail list logo
