Re: Are the faster versions of HashMap and BigInteger going into jdk7?

Ismael Juma wrote: [... HashMaps...] From the email you mention: "I'm not convinced that they are enough better to commit." To me that sounds like it's not going in at all. Although at the end of that mail (http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-July/002168.html) I m

Re: Sponsoring getting 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 7

FYI, While I certainly love my "Joiner" baby, and while y'all have blanket permission to make use of any of our code you want, I think it's entirely appropriate for the JDK to just hit the 80% case with a static method directly on String. (And yes, the fact that split() is an instance method is a

Re: nonNull and similar methods [was Re: First round of java.util.Objects for code review (bug 6797535)]

On Wed, Oct 14, 2009 at 3:38 AM, Stephen Colebourne wrote: While I agree that the nonNull methods below are useful and should be in the > JDK, I question whether they should be on j.u.Objects. > > I believe that there is a whole category of methods to pre-validate the > arguments of a method, such

Re: Are the faster versions of HashMap and BigInteger going into jdk7?

Hi Paulo, Paulo Levi writes: > http://www.mail-archive.com/core-libs-dev-0nJqbsLSQw0FDOXUYO6UHQ public.gmane.org/msg02147.html >From the email you mention: "I'm not convinced that they are enough better to commit." To me that sounds like it's not going in at all. Ismael

Re: Code review request for 6891113: More methods for java.util.Objects: deepEquals, hash, toString with default

Joe Darcy wrote: Neal Gafter wrote: There should be a shortcut in Arrays.deepEquals0 when e1==e2. That shortcut is in Objects.deepEquals(Object a, Object b) and Arrays.deepEquals on lines 3947 and 3948. The nested call in deepEquals0 is to deepEquals rather than deepEquals0 so the shortcut

hg: jdk7/tl/jdk: 6891113: More methods for java.util.Objects: deepEquals, hash, toString with default

Changeset: 80102c165e09 Author:darcy Date: 2009-10-23 11:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/80102c165e09 6891113: More methods for java.util.Objects: deepEquals, hash, toString with default Reviewed-by: alanb, gafter ! src/share/classes/java/util/Arrays.java

Re: Sponsoring getting 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 7

Yes, to my aesthetics the static call join(" ", "A", "call", "to"); is more sensible looking than " ".join("A", "call", "to"); Especially when a call like " ".join("Foo") will not have " " in the returned String. However, the platform would certainly be improved with any version o

Re: Are the faster versions of HashMap and BigInteger going into jdk7?

I don't think it's the same. 6622432 appears to be programming optimizations for the existing BigInteger. Alan Eliasen version is one that uses lower complexity algorithms for the larger numbers. If hashmap is replaced by a more efficient version, that would be probably a massive win in some real

Re: Are the faster versions of HashMap and BigInteger going into jdk7?

2009/10/23 Paulo Levi : > Yes. Different implementations with better performance. > > http://gcc.gnu.org/ml/java/2009-06/msg00019.html > 6622432 is the one of the ones I just pointed to i.e. it's in JDK7. If Alan has a further patch and hasn't even submitted it for inclusion, it's obviously not in

Re: Sponsoring getting 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 7

Am 23.10.2009 17:51, Mark Reinhold schrieb: Date: Fri, 23 Oct 2009 10:10:35 +0200 From: Rémi Forax Le 23/10/2009 03:53, Joe Darcy a écrit : Following up on this, what is the exact revised proposal? In java.lang.String: public static String join(String separator, Iterable ob

Re: Are the faster versions of HashMap and BigInteger going into jdk7?

Yes. Different implementations with better performance. http://gcc.gnu.org/ml/java/2009-06/msg00019.html http://www.mail-archive.com/core-libs-dev@openjdk.java.net/msg02147.html

Re: Sponsoring getting 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 7

Hi, >From the peanut gallery, it seems to me that there is a genuine reason to leave join as a static method (if we're not going after the google-collections approach of a Joiner class

Re: Sponsoring getting 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 7

> Date: Fri, 23 Oct 2009 10:10:35 +0200 > From: Rémi Forax > Le 23/10/2009 03:53, Joe Darcy a écrit : >> Following up on this, what is the exact revised proposal? >> >> In java.lang.String: >> >>public static String join(String separator, Iterable objects); >>public static String join(S

Re: Are the faster versions of HashMap and BigInteger going into jdk7?

2009/10/23 Paulo Levi : > Just a question. > The only relevant changes I see are: changeset: 1246:8d2efec31d78 user:xlu date:Sun May 24 16:29:57 2009 -0700 summary: 6622432: RFE: Performance improvements to java.math.BigDecimal http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/8

Are the faster versions of HashMap and BigInteger going into jdk7?

Just a question.

Re: Sponsoring getting 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 7

Le 23/10/2009 03:53, Joe Darcy a écrit : Joe Darcy wrote: Rémi Forax wrote: Le 14/10/2009 01:32, Joseph D. Darcy a écrit : Hello. Following up from threads earlier this year, http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001061.html http://mail.openjdk.java.net/piperma