Re: hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String

[I trimmed the distribution list] On Jun 3 2012, at 13:44 , Peter Levart wrote: On Thursday, May 31, 2012 03:22:35 AM mike.dui...@oracle.com wrote: Changeset: 2c773daa825d Author:mduigou Date: 2012-05-17 10:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c773daa825d

Re: [doc]Small modification on the WeakHashMap doc

The change looks good to me. On Jun 3 2012, at 20:05 , David Holmes wrote: On 4/06/2012 11:55 AM, Charles Lee wrote: Thanks David. Do I need another review? Yes. Someone from TL - Mike or Alan most likely. David On 06/03/2012 06:15 AM, David Holmes wrote: Hi Charles, I have no

Request for Reviews 71739187173919: Small follow-ons to alternative hashing

Two small issues related to the larger alternative string hashing changes (CR#7126277) from last week. One issue is for JDK 7 and the other is for JDK 8. Both are quite small. For the JDK 7 issue, as documented in the review request, the default threshold for the alternative hashing in that

Review Request 7174736 : JCK test api/java_util/HashMap/index_EntrySet failing

Hello all; Alan Bateman tracked down a regression introduced by the Alternative HashMap changes which was caught by the JCK tests. The fix is a one liner: diff --git a/src/share/classes/java/util/HashMap.java b/src/share/classes/java/util/HashMap.java ---

hg: jdk8/tl/jdk: 7174736: JCK test api/java_util/HashMap/index_EntrySet failing

Changeset: fc0e508b713f Author:mduigou Date: 2012-06-07 01:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc0e508b713f 7174736: JCK test api/java_util/HashMap/index_EntrySet failing Summary: Corrects a problem with HashMap.removeEntry() that caused a JCK test to fail

hg: jdk8/tl/jdk: 7173919: Minor optimization of hashing methods

Changeset: 505455116320 Author:mduigou Date: 2012-06-13 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/505455116320 7173919: Minor optimization of hashing methods Summary: several minor optimizations to hashing methods used by hash map classes Reviewed-by: dholmes !

Request for Review 7175758 : Improvements to Collisions.java regression test

Hello all; This review is for test changes only. CR#7174736 (http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc0e508b713f) corrected a problem uncovered by a JCK test. A regression test was not included in that changeset. This patch adds a regression test for the root cause of CR#7174736 as well as

Re: hg: jdk8/tl/jdk: 7173919: Minor optimization of hashing methods

On Jun 14 2012, at 09:29 , Ulf Zibis wrote: Hi Mike, I like the 1-liner ... :-) int h = hashSeed ^ k.hashCode(); ... but I'm still missing a little comment, what this xor with a hashSeed serves for. Such as brief, as the next following 3 lines about preventing from

hg: jdk8/tl/jdk: 7175758: Improve unit test of Map iterators and Iterator.remove()

Changeset: e60cedd3a4aa Author:mduigou Date: 2012-06-15 13:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e60cedd3a4aa 7175758: Improve unit test of Map iterators and Iterator.remove() Summary: Adds additional tests of Map iterators and Iterator.remove() Reviewed-by:

Re: Review Request: CR 7100996 - (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads

Great addition! I believe you should be using {@code} rather than code tags. I would say constructors rather than create. I would add the word operation after the first instance of create/append/insert I would change This could be done to This could be satisfied Mike On Jun 21 2012, at

Re: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X

On Jun 22 2012, at 10:01 , Xueming Shen wrote: Hi Here is the proposed change to support Unicode nfd/nfc and case insensitive file path on MacOSX file system. 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X 7168427:

Re: String.subSequence and CR#6924259: Remove offset and count fields from java.lang.String

As usual, an excellent idea Jason. I'll probably run an internal test/benchmark with both this and the CharSequence inner class implementation to see what breaks and where there are performance differences between the two. I was planning to also test a version of the CharSequence implementation

Re: String.subSequence and CR#6924259: Remove offset and count fields from java.lang.String

classes - for allowing CharSequence input? Probably. Martin Le 23/06/12 00:15, Mike Duigou a écrit : I've made a test implementation of subSequence() utilizing an inner class with offset and count fields to try to understand all the parts that would be impacted. My observations

Re: RFR: JDK-8068427 Hashtable deserialization reconstitutes table with wrong capacity

/ Is this ok now? Regards, Peter On 01/09/2015 11:16 AM, Peter Levart wrote: On 01/05/2015 05:52 PM, Mike Duigou wrote: Well spotted Peter. The change looks good though I wonder if it should be: int length = (int)((elements + elements / 20) / loadFactor) + 3; FYI, regarding Daniel's

Re: RFR: JDK-8068427 Hashtable deserialization reconstitutes table with wrong capacity

Well spotted Peter. The change looks good though I wonder if it should be: int length = (int)((elements + elements / 20) / loadFactor) + 3; FYI, regarding Daniel's suggestion: When similar invariant checks were added to the HashMap deserialization method we found code which relied upon the

Re: RFR 8141409 Arrays.equals accepting a Comparator

Date: Wed, 4 Nov 2015 15:32:25 +0100 From: Paul Sandoz To: core-libs-dev Subject: RFR 8141409 Arrays.equals accepting a Comparator Please review: In addition i added an Objects.compare method, which simplifies the implementations of some

CopyOnWriteArrayNavigableSet discussion on concurrency-interest

Hello all; For those that don't regularly read the JSR-166 concurrency-interest list (http://cs.oswego.edu/mailman/listinfo/concurrency-interest) I wanted to make note of a discussion there that some reading here may be interested in. I have recently proposed a new NavigableSet

Re: Array equality, comparison and mismatch

On 22 Sep 2015, at 18:30, Paul Sandoz wrote: Hi, Please review the following which adds methods to Arrays for performing equality, comparison and mismatch: https://bugs.openjdk.java.net/browse/JDK-8033148

Re: Array equality, comparison and mismatch

- I apologize if this was discussed earlier in the thread but why is the comparison of floats and doubles done by first == operator of the int bits and only then the compare method ? I was being consistent with the test used for the existing equals methods of float[] and double[]. Note that

RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use > alternative to finalization (Roger Riggs)

Hi Roger; This looks like an interesting proposal and would be a good replacement for alternative solutions. I am curious why the thread is run at max priority. Also, why not set priority and daemon status in the factory? You should clear the Thread intrerruption if you are going to ignore

Re: JDK 9 RFR of JDK-8149896: Remove unnecessary values in FloatConsts and DoubleConsts

From: joe darcy Hello, The the FloatConsts and DoubleConsts classes, while moved to an internal package recently (JDK-8145990), contain constants now available via the public API. All such uses of the redundant values should be removed as well as the redundant constants

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

I don't believe that I would use the proposed enhancement to the for statement. For me there is cognitive load reduction in using a symmetrical method for all iterations even if they end up being a little more complicated for individual cases. Usually, for me, I use streams. Even the more

<    4   5   6   7   8   9