July 2011 - core-libs-dev

hg: jdk8/tl: 5 new changesets
by lana.steuck＠oracle.com 15 Jul '11

15 Jul '11

Changeset: 8da980eedab6 Author: jeff Date: 2011-06-22 10:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8da980eedab6 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: d91364304d7c Author: lana Date: 2011-06-22 12:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d91364304d7c Merge Changeset: ee67ee3bd597 Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ee67ee3bd597 Added tag jdk7-b147 for changeset d91364304d7c ! .hgtags Changeset: 04734fe746f0 Author: schien Date: 2011-06-27 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/04734fe746f0 Merge Changeset: 05e24d6ed56d Author: lana Date: 2011-07-14 18:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/05e24d6ed56d Merge

1 0

hg: jdk8/tl/corba: 4 new changesets
by lana.steuck＠oracle.com 15 Jul '11

15 Jul '11

Changeset: bba0e37d7006 Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/bba0e37d7006 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: 73323cb33962 Author: lana Date: 2011-06-22 12:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/73323cb33962 Merge Changeset: 960011ba4bf2 Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/960011ba4bf2 Added tag jdk7-b147 for changeset 73323cb33962 ! .hgtags Changeset: 97014e43181f Author: schien Date: 2011-06-27 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/97014e43181f Merge

1 0

AbstractCollection.removeAll(Collection) and AbstractSet.removeAll(Collection)
by Jeff Hain 13 Jul '11

13 Jul '11

Hello. I have some remarks about the methods named in the subject (JDK 6u26, JDK 7b147). 1) AbstractCollection.removeAll(Collection) This method could return immediately if the specified collection is empty, not to iterate uselessly over all "this", or if "this" is empty, not to create an iterator for nothing.public boolean removeAll(Collection<?> c) { boolean modified = false; if (size() > c.size()) { for (Iterator<?> i = c.iterator(); i.hasNext(); ) modified |= remove(i.next()); } else { for (Iterator<?> i = iterator(); i.hasNext(); ) { if (c.contains(i.next())) { i.remove(); modified = true; } } } return modified; } # Alternative implementation (not tested):public boolean removeAll(Collection<?> c) { // Quick check on emptinesses, to make later treatments simpler. if (isEmpty() || c.isEmpty()) { return false; } boolean modified = false; final int n1 = size(); final int n2 = c.size(); // If the "c" is not a set, we are pessimistic about its "contains" method complexity. final int cContainsAssumedComplexity = (c instanceof Set<?>) ? 1 : n2; // If we iterate over "this", assumed complexity is O(n2). // If we iterate over "c", assumed complexity is O(n1 * cContainsAssumedComplexity). // Cast to long to avoid overflow. if (n2 < n1 * (long)cContainsAssumedComplexity) { for (Iterator<?> i = c.iterator(); i.hasNext(); ) { if (remove(i.next())) { modified = true; if (isEmpty()) { break; } } } } else { for (Iterator<?> i = iterator(); i.hasNext(); ) { if (c.contains(i.next())) { i.remove(); modified = true; } } } return modified; } I also thought about returning as soon as as many elements as the specified collection contains have been removed, but it would not behave properly with collections containing more than Integer.MAX_VALUE elements, or with some overriden equals methods etc. 2) AbstractSet.removeAll(Collection) Let n1 be the size of "this", and n2 the size of the specified collection. This method is in O(n1*n2) if the specified collection has a contains(Object) method in O(n2) (as an ArrayList does), and n1 <= n2. I think a better implementation could be done by taking care of the "setness" of the specified collection, and taking care of collections sizes differently. Also: - when iterating on the specified collection, the method could return as soon as "this" is empty, not to continue useless iterations. - when iterating on "this", the method could return if the specified collection is empty, not to iterate over all "this" uselessly. # Current implementation: Regards, Jeff

3 2

hg: jdk8/tl/jdk: 7057320: test/java/util/concurrent/Executors/AutoShutdown.java failing intermittently
by chris.hegarty＠oracle.com 13 Jul '11

13 Jul '11

Changeset: db419c454f92 Author: dl Date: 2011-07-13 12:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/db419c454f92 7057320: test/java/util/concurrent/Executors/AutoShutdown.java failing intermittently Summary: Add retry/timeout for checking activeCount Reviewed-by: chegar ! test/java/util/concurrent/Executors/AutoShutdown.java

1 0

Possible JDK 7 issue
by Stephen Colebourne 13 Jul '11

13 Jul '11

This message is forwarded from Apache Commons, where a question was raised as to whether the change in behaviour of year formatting in JDK 7 was deliberate: Stephen ---------- Forwarded message ---------- From: Jörg Schaible <joerg.schaible(a)gmx.de> Date: 12 July 2011 18:56 Subject: Re: [lang] RC4 heads up To: dev(a)commons.apache.org 1/ FastDateFormat The date format "yyyy yyy yy y" is formatted with JDK 7 as "2003 2003 03 2003" instead of "2003 03 03 03". So, should FastDateFormat follow the JDK in any case and adjust its result according the runtime? Interestingly Javadoc states already for Java 6: "For formatting, if the number of pattern letters is 2, the year is truncated to 2 digits; otherwise it is interpreted as a number."

1 0

Tr : AbstractCollection.removeAll(Collection) and AbstractSet.removeAll(Collection)
by Jeff Hain 13 Jul '11

13 Jul '11

Sorry, all paragraphs were in disorder ; looks like my mail app is not wysiwyg at all. I hope this time content doesn't get messed up, else I'll just give up. ----- Message transféré ---- De : Jeff Hain <jeffhain(a)rocketmail.com> À : core-libs-dev(a)openjdk.java.net Envoyé le : Mer 13 juillet 2011, 1h 13min 51s Objet : AbstractCollection.removeAll(Collection) and AbstractSet.removeAll(Collection) Hello. I have some remarks about the methods named in the subject (JDK 6u26, JDK 7b147). 1) AbstractCollection.removeAll(Collection) This method could return immediately if the specified collection is empty, not to iterate uselessly over all "this", or if "this" is empty, not to create an iterator for nothing. I also thought about returning as soon as as many elements as the specified collection contains have been removed, but it would not behave properly with collections containing more than Integer.MAX_VALUE elements, or with some overriden equals methods etc. 2) AbstractSet.removeAll(Collection) Let n1 be the size of "this", and n2 the size of the specified collection. This method is in O(n1*n2) if the specified collection has a contains(Object) method in O(n2) (as an ArrayList does), and n1 <= n2. I think a better implementation could be done by taking care of the "setness" of the specified collection, and taking care of collections sizes differently. Also: - when iterating on the specified collection, the method could return as soon as "this" is empty, not to continue useless iterations. - when iterating on "this", the method could return if the specified collection is empty, not to iterate over all "this" uselessly. # Current implementation: public boolean removeAll(Collection<?> c) { boolean modified = false; if (size() > c.size()) { for (Iterator<?> i = c.iterator(); i.hasNext(); ) modified |= remove(i.next()); } else { for (Iterator<?> i = iterator(); i.hasNext(); ) { if (c.contains(i.next())) { i.remove(); modified = true; } } } return modified; } # Alternative implementation (not tested): public boolean removeAll(Collection<?> c) { // Quick check on emptinesses, to make later treatments simpler. if (isEmpty() || c.isEmpty()) { return false; } boolean modified = false; final int n1 = size(); final int n2 = c.size(); // If the "c" is not a set, we are pessimistic about its "contains" method complexity. final int cContainsAssumedComplexity = (c instanceof Set<?>) ? 1 : n2; // If we iterate over "this", assumed complexity is O(n2). // If we iterate over "c", assumed complexity is O(n1 * cContainsAssumedComplexity). // Cast to long to avoid overflow. if (n2 < n1 * (long)cContainsAssumedComplexity) { for (Iterator<?> i = c.iterator(); i.hasNext(); ) { if (remove(i.next())) { modified = true; if (isEmpty()) { break; } } } } else { for (Iterator<?> i = iterator(); i.hasNext(); ) { if (c.contains(i.next())) { i.remove(); modified = true; } } } return modified; } Regards, Jeff

1 0

hg: jdk8/tl/jdk: 7022407: Spinning CPU in LocaleObjectCache.get()
by naoto.sato＠oracle.com 12 Jul '11

12 Jul '11

Changeset: 42fe05e54e69 Author: naoto Date: 2011-07-12 10:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/42fe05e54e69 7022407: Spinning CPU in LocaleObjectCache.get() Reviewed-by: okutsu ! src/share/classes/sun/util/locale/LocaleObjectCache.java

1 0

hg: jdk8/tl/jdk: 7058828: test/java/util/concurrent/Phaser/Arrive.java fails intermittently
by chris.hegarty＠oracle.com 12 Jul '11

12 Jul '11

Changeset: 549b7c3f0bdc Author: dl Date: 2011-07-12 15:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/549b7c3f0bdc 7058828: test/java/util/concurrent/Phaser/Arrive.java fails intermittently Reviewed-by: chegar ! test/java/util/concurrent/Phaser/Arrive.java

1 0

Byte.parseByte throws NumberFormatException for value "95", radix: 16
by Janda Martin 12 Jul '11

12 Jul '11

I have question about parsing hex string. Java 6u25 When I call Byte.parseByte("95", 16) I get. java.lang.NumberFormatException: Value out of range. Value:"95" Radix:16 at java.lang.Byte.parseByte(Byte.java:153) 95 hex is 149 dec, Integer value '149' can be cast to valid byte value -107 Is the exception correct? Thank you very much for answer Martin JANDA jandam(a)crcdata.cz Code from Byte.java public static byte parseByte(String s, int radix) throws NumberFormatException { int i = Integer.parseInt(s, radix); if (i < MIN_VALUE || i > MAX_VALUE) throw new NumberFormatException( "Value out of range. Value:\"" + s + "\" Radix:" + radix); return (byte)i; }

3 3

hg: jdk8/tl/jdk: 7012364: test/java/util/Locale/LocaleCategory.sh fails on Cygwin
by yuka.kamiya＠oracle.com 11 Jul '11

11 Jul '11

Changeset: 5adf431673ac Author: peytoia Date: 2011-07-12 07:32 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5adf431673ac 7012364: test/java/util/Locale/LocaleCategory.sh fails on Cygwin Reviewed-by: okutsu ! test/java/util/Locale/LocaleCategory.sh

1 0