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

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: 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: 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: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Looks fine. I think it is always important note when a change may result in different results for some inputs. I will reiterate for the record what's mentioned in the bug: However, one caveat is that this may affect the results of some calculations. For example, some range of numbers that

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

I suppose that there will be some numerical inconsistencies between the two versions. Brian On Sep 22, 2014, at 2:24 PM, Mike Duigou mike.dui...@oracle.com wrote: Looks fine. I think it is always important note when a change may result in different results for some inputs. I

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Looks fine to me! Mike On Sep 22 2014, at 15:34 , Brian Burkhalter brian.burkhal...@oracle.com wrote: Hi Aleksey, On Sep 22, 2014, at 2:43 PM, Aleksey Shipilev aleksey.shipi...@oracle.com wrote: Hm, and this compiler transformation works in strictfp context? I hope compilers do the

Re: Impact of code difference in Collection#contains() worth improving?

Hi Fabian; This has been an excellent discussion and thank you for starting it! Even if there is disagreement on various aspects I don't believe that anyone is upset or angry. Mike On Aug 30 2014, at 10:04 , Fabian Lange lange.fab...@gmail.com wrote: Hello dear list, it was not my

Re: Impact of code difference in Collection#contains() worth improving?

Looks fine (bug updated with noreg-perf). I do think we should consider promoting a copy of this method to AbstractList as it generally allows for a much better implementation than AbstractCollection's contains(). Mike On Aug 29 2014, at 14:56 , Martin Buchholz marti...@google.com wrote:

Re: A List from Iterator

We considered having Enumeration extend Iterator and provide next() and hasNext() defaults which called the Enumeration methods but found, unfortuantely that there were several Enumeration implementations that already had next(). If we were to provide a Collections util it would to wrap

Re: Impact of code difference in Collection#contains() worth improving?

Hi Fabian; The correct mailing list for this discussion would be core-libs-dev@openjdk.java.net The difference between these two implementations is probably of not much consequence though it seems that one or the other could be promoted to AbstractList. This implementation would be marginally

Re: RFR: 8055949: ByteArrayOutputStream capacity should be maximal array size permitted by VM

This looks fine to me as well. I am fine with the @ignore as I don't suspect anyone would be able to sneak in a change which removed the @ignore without anyone noticing and the comment for why it is marked @ignore seems adequate. Mike On Aug 25 2014, at 13:28 , Alan Bateman

Re: new StringBuilder(char)

On Aug 16 2014, at 16:24 , Ulf Zibis ulf.zi...@cosoco.de wrote: Additionally nice to have: (initial capacity with initial char(s)) StringBuilder(int,char) This one is unlikely. StringBuilder(int,CharSequence) I don't see much advantage to this API. If it enabled a significant

Re: new StringBuilder(char)

On Aug 15 2014, at 22:38 , Jeremy Manson jeremyman...@google.com wrote: No love from core-libs-dev? Pavel has been looking into this and doing corpus and historical bug checks. It seems possible that we might consider fixing it as it does seem to be an ongoing source of errors. Mike It's

Re: RFR(S): 8055032: Improve numerical parsing in java.net and sun.net

On Aug 14 2014, at 06:39 , Alan Bateman alan.bate...@oracle.com wrote: On 14/08/2014 14:23, Claes Redestad wrote: How about methods only taking beginIndex? Integer.parseInt(x: 1000, 3, 10)? I guess these could to be dropped to avoid ambiguity and instead allow for variations where radix

Re: RFR [9] 8053938: Collections.checkedList(empty list).replaceAll((UnaryOperator)null) doesn't throw NPE after JDK-8047795

This looks fine. On Jul 30 2014, at 08:45 , Chris Hegarty chris.hega...@oracle.com wrote: A trivial one-liner for a missing null check for the given operator after the changes for 8047795, which now always passes a non-null operator to the underlying list.replaceAll. The original test

RFR: 8048209 : (s) Collections.synchronizedNavigableSet().tailSet(Object, boolean) synchronizes on wrong object

Hello all; This change fixes an issue with the instance returned by Collections.synchronizedNavigableSet().tailSet(Object,boolean) which synchronizes on wrong object, itself rather than the same mutex as it's source. jbsbug: https://bugs.openjdk.java.net/browse/JDK-8048209 webrev:

Re: RFR: 8048209 : (s) Collections.synchronizedNavigableSet().tailSet(Object, boolean) synchronizes on wrong object

no relation. Mike -Chris. On 24 Jul 2014, at 08:12, Mike Duigou mike.dui...@oracle.com wrote: Hello all; This change fixes an issue with the instance returned by Collections.synchronizedNavigableSet().tailSet(Object,boolean) which synchronizes on wrong object, itself rather than

RFR: 6721085 : (xxs) Fix broken link to Collections Framework Tutorial

Hello all; This is a tiny fix to the java.util package documentation to update the URL of the Collections tutorial. The entire change is below. I have also checked for other references to http://www.java.sun.com/docs/books/tutorial/; in the jdk repo. This was the only instance.

Re: Map.compute() confusing Javadoc

Hi Roman; Somewhat unfortunately, just return null is what the default and all conforming implementations do of compute do when presented with a Map containing a mapping to null and a mapping function returning null. The specification of the new Java 8 Map methods does not always handle maps

Re: RFR (S): 8050114: Expose Integer/Long formatUnsigned methods internally

Looks good. I will complete some additional testing and push this changeset for you. On Jul 18 2014, at 14:14 , Claes Redestad claes.redes...@oracle.com wrote: Hi, Mike Duigou suggested some simplifications to the formatUnsigned methods. Shows a slight speed-upon some micros as well

Re: RFR (S): 8050114: Expose Integer/Long formatUnsigned methods internally

Redestad wrote: Hi, Mike Duigou suggested some simplifications to the formatUnsigned methods. Shows a slight speed-upon some micros as well: http://cr.openjdk.java.net/~redestad/8050114/webrev.2/ /Claes On 2014-07-13 00:26, Claes Redestad wrote: Hi, please review this patch

RFR: 8051057: (s) Optimize StringCharBuffer.toString(int, int)

Hello all; While investigating another issue I ran across some code in java.nio.StringCharBuffer.toString(int, int) which might be possible to improve. Currently the implementation calls toString() on the source CharSequence and then uses String.substring to create the desired range. For the

FYC: 7197183 : Provide CharSequence.subSequenceView which allows for sub-sequence views of character sequences.

Hello all; In Java 7u6 there was a significant change in the implementation of java.lang.String (JDK-6924259). This was done to reduce the size of String instances and it has been generally regarded as a positive change. As with almost any significant change to a class as core to Java as

Re: RFR(XS): 8050825: Support running regression tests using jtreg_tests+TESTDIRS from top level

This looks like a nice improvement and provides a good way to execute specific sub-sets that are smaller than the TEST.groups definitions. I'd like to hook it up to the top level make as an alternative to the current recipe. make test TEST=jdk_core Perhaps adjust the top level make test

Re: RFR(XS): 8050825: Support running regression tests using jtreg_tests+TESTDIRS from top level

I will probably try to fix that eventually. I had some shell code which re-resolved a path relative to another path. In particular, for top level make execution the ../ portion would be incorrect. Anyway, this seems good enough for now. We can make it more flexible later. Mike On Jul 15

Re: RFR [9] 8041972: Add improved parse/format methods for Long/Integer

Some comments: - The NumberFormatException.forInputString for some CharSequence is probably misleading since it doesn't consider the begin-end range which was in effect for the parsing. Rather than extracting the substring just for the error message perhaps include the index at which the error

Re: RFR (XS): 8050105: test sun/rmi/rmic/minimizeWrapperInstances/run.sh fails

Looks fine. On Jul 11 2014, at 18:11 , Stuart Marks stuart.ma...@oracle.com wrote: Hi all, Please review this small patch to fix one of the old RMI tests that has started failing. This simply removes a couple test cases that use the (hidden, unsupported) -Xnew option of rmic, which

Re: RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size

Looks pretty good. I like the additional comments as well. Could you document the return conditions of resize()? A since we're there already suggestion for readObject: if (size 0) throw new InvalidObjectException(Illegal mappings count: + size); Mike On Jul 8 2014, at 13:07 , Martin

RFR: 8048207 : (xs) Collections.checkedQueue offer() calls add() on wrapped queue

Hello all; This changeset corrects an issue with the Collections.checkedQueue() utility method added in Java 8. The wrapper implementation incorrectly calls add() on the wrapped queue rather than offer(). I improved the existing unit test to include this condition (and converted it to

Re: RFR: 8047795: Collections.checkedList checking bypassed by List.replaceAll

On Jun 25 2014, at 01:30 , Paul Sandoz paul.san...@oracle.com wrote: On Jun 24, 2014, at 8:25 PM, Mike Duigou mike.dui...@oracle.com wrote: On Jun 24 2014, at 01:18 , Paul Sandoz paul.san...@oracle.com wrote: Additionally the javadoc is updated to inform users that a ClassCastException

Re: RFR: 8047795: Collections.checkedList checking bypassed by List.replaceAll

probably add @SuppressWarnings(unchecked”) to typeCheck(Object). Done. -Chris. On 24 Jun 2014, at 01:42, Mike Duigou mike.dui...@oracle.com wrote: Hello all; This changeset corrects a reported problem with the lists returned by Collections.checkedList(). Since Java 8 the replaceAll

RFR: 8047795: Collections.checkedList checking bypassed by List.replaceAll

Hello all; This changeset corrects a reported problem with the lists returned by Collections.checkedList(). Since Java 8 the replaceAll() method on checked lists has erroneously allowed the operator providing replacements to provide illegal replacement values which are then stored, unchecked

Re: RFR [9] 8046902: Remove sun.misc.Timer

Remove it before someone starts to use it! Mike On Jun 16 2014, at 08:05 , Chris Hegarty chris.hega...@oracle.com wrote: The type sun.misc.Timer has long since been replaced by the standard java.util.Timer. As an unneeded part of sun.misc, sun.misc.Timer should be removed from the

RFR: 8046085: (s) inserting null key into HashMap treebin fails

Hello all; This changeset corrects a problem inserting a null key into a HashMap that is using TreeBins. The root cause of the failure was diagnosed by Paul Sandoz and confirmed by Alan Bateman, Doug Lea and myself. I've prepared the changeset and a minimal test which reproduces the failure.

Re: RFR: 8044740: Convert all JDK versions used in @since tag to 1.n[.n] in jdk repo

You will need to include awt-dev and security-dev since this patch touches those areas as well. Other impacted groups I missed? I would like to see this all go back in one changeset to dev repo though as it would be a lot cleaner that way. I am concerned a bit that if we retain standard names

Re: RFR 8043772: Typos in Double/Int/LongSummaryStatistics.java

Looks fine to me. Mike You are using an old version of webrev :-) wget http://hg.openjdk.java.net/code-tools/webrev/raw-file/tip/webrev.ksh On May 22 2014, at 08:36 , Ivan Gerasimov ivan.gerasi...@oracle.com wrote: Hello! Some functions were renamed with the fix for JDK-8015318. A few

Re: RFR JDK-7153400: ThreadPoolExecutor's setCorePoolSize method allows corePoolSize maxPoolSize

Hi Pavel; The change and test looks good. Will the test be upstreamed or will Doug be adding a similar test in his upstream? Mike On May 14 2014, at 08:29 , Pavel Rappo pavel.ra...@oracle.com wrote: Hi everyone, could you please review my change for JDK-7153400?

Re: JDK-8042355 stream with sorted() causes downstream ops not to be lazy

Looks good to me. On May 5 2014, at 06:16 , Paul Sandoz paul.san...@oracle.com wrote: Hi, https://bugs.openjdk.java.net/browse/JDK-8042355 http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8042355-sorted-short-circuit/webrev/ This is an optimization to ensure that sorted() in sequential

Re: RFR [8040806]: BitSet.toString() can throw IndexOutOfBoundsException

The fix looks good though I wonder if the conditional checks can be optimized a bit. I am concerned that the suggested iteration method provided in the nextSetBit() javadoc induces the same failure we just corrected. Perhaps we should revise that advice? Mike On May 5 2014, at 09:56 , Ivan

Re: RFR [8040806]: BitSet.toString() can throw IndexOutOfBoundsException

On May 5 2014, at 11:54 , Ivan Gerasimov ivan.gerasi...@oracle.com wrote: Thank you Mike! On 05.05.2014 21:37, Mike Duigou wrote: The fix looks good though I wonder if the conditional checks can be optimized a bit. Hm. I don't see lots of room for optimization here without revising

Re: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour

, which is a data race +public boolean addAll(int index, Collection? extends E c) { if (index 0 || index elementCount) throw new ArrayIndexOutOfBoundsException(index); On Wed, Apr 16, 2014 at 10:30 AM, Mike Duigou mike.dui...@oracle.com wrote: Yes. This has

Re: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty

. Thank you. http://cr.openjdk.java.net/~mduigou/JDK-8035584/2/webrev/ Mike On Tue, Mar 11, 2014 at 5:20 PM, Mike Duigou mike.dui...@oracle.com wrote: I've actually always used scp. :-) Since I accepted all of your changes as suggested and had no other

Re: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty

)))}, Corrected. Thank you. http://cr.openjdk.java.net/~mduigou/JDK-8035584/2/webrev/ Mike On Tue, Mar 11, 2014 at 5:20 PM, Mike Duigou mike.dui...@oracle.com wrote: I've actually always used scp. :-) Since I accepted all of your changes as suggested

RFR: 8035584 : (s) ArrayList(c) should avoid inflation if c is empty

Hello all; Revisiting this issue again at long last I have updated the proposed changeset based upon Jason Mehren's most recent feedback. http://cr.openjdk.java.net/~mduigou/JDK-8035584/4/webrev/ This version reverts the prior changes to toArray(). Mike

pre-RFR : 8022854: (s) System.setProperties(null) causes implementation private properties to reappear

At long last I got back to this issue and discovered that there are some lurking issues with property reinitialization. I've created a couple of bugs for some of the shortcomings I discovered. None of these are caused by this changeset. I would like to hold off completing this issue until we

Re: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour

Yes. This has been corrected. Mike On Apr 16 2014, at 08:19 , Martin Desruisseaux martin.desruisse...@geomatys.fr wrote: Hello all Le 15/04/14 18:14, Mike Duigou a écrit : I have updated the webrev with what I hope is the final form: http://cr.openjdk.java.net/~mduigou/JDK-8020860/1

Re: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour

On Apr 14 2014, at 18:25 , Martin Buchholz marti...@google.com wrote: I'll retreat to being neutral on the overall idea. In general, it *is* a best software engineering practice to do all the reading and computing before doing all the writing at the end. You'll break anyone who does the

RFR: 8035284: (xs) Remove redundant null initialization

Hello all; This is a simple cleanup changeset that removes redundant initialization of fields to null from a number of collection classes. These field initializations may seem cheap but they do have a cost: - For volatile fields there is a measurable cost on some benchmarks for these extra

Re: RFR: 8035284: (xs) Remove redundant null initialization

at 12:22 PM, Mike Duigou mike.dui...@oracle.com wrote: Hello all; This is a simple cleanup changeset that removes redundant initialization of fields to null from a number of collection classes. These field initializations may seem cheap but they do have a cost: - For volatile fields

Re: RFR: 8035284: (xs) Remove redundant null initialization

documentation value (suggesting that the constructor will not assign a value; null is a valid value). How about fixing javac instead? On Fri, Apr 11, 2014 at 12:22 PM, Mike Duigou mike.dui...@oracle.com wrote: Hello all; This is a simple cleanup changeset that removes redundant

Re: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1)

On Apr 10 2014, at 03:21 , Chris Hegarty chris.hega...@oracle.com wrote: On 10 Apr 2014, at 11:03, Ulf Zibis ulf.zi...@cosoco.de wrote: Hi Chris, Am 10.04.2014 11:04, schrieb Chris Hegarty: Trivially, you could ( but of not have to ) use java.nio.charset.StandardCharsets.ISO_8859_1 to

Re: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1)

Shouldn't we be using the platform default character set rather than iso8859-1? This change will change the charset used for all platforms not using iso885901 as their default. It is certainly odd that sun.misc.CharacterEncoder(byte) and sun.misc.CharacterDecoder(String) are not symmetrical

Re: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1)

one keep it symmetrical without forcing a particular encoding? Brian On Apr 10, 2014, at 10:54 AM, Mike Duigou mike.dui...@oracle.com wrote: Shouldn't we be using the platform default character set rather than iso8859-1? This change will change the charset used for all platforms

Re: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1)

On Apr 10 2014, at 11:08 , Chris Hegarty chris.hega...@oracle.com wrote: On 10 Apr 2014, at 18:40, Mike Duigou mike.dui...@oracle.com wrote: On Apr 10 2014, at 03:21 , Chris Hegarty chris.hega...@oracle.com wrote: On 10 Apr 2014, at 11:03, Ulf Zibis ulf.zi...@cosoco.de wrote: Hi

Re: UUID.compareTo broken?

, Paul Sandoz paul.san...@oracle.com wrote: On Apr 7, 2014, at 7:23 PM, Mike Duigou mike.dui...@oracle.com wrote: I also note that UUID does not currently support version 5, SHA-1, which it should. I am hoping to do other performance work on UUID within the scope of Java 9. Adding

Re: UUID.compareTo broken?

On Apr 8 2014, at 01:03 , Paul Sandoz paul.san...@oracle.com wrote: On Apr 7, 2014, at 7:23 PM, Mike Duigou mike.dui...@oracle.com wrote: The issue is that the comparison is done upon the signed most significant and least significant long values. At minimum UUIDs should be compared

Re: UUID.compareTo broken?

The issue is that the comparison is done upon the signed most significant and least significant long values. At minimum UUIDs should be compared as if they were 128-bit unsigned values. Beyond that, version (which is a type not a version) 1 and 2 UUIDs (time based and DCE), should have a more

8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour

Hello all; Recently HotSpot gained additional support for transactional memory, https://bugs.openjdk.java.net/browse/JDK-8031320. This patch is a libraries followon to that change. RTM and other transactional memory implementations benefit from clustering writes towards the end of the

Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal

On Mar 24 2014, at 12:25 , Martin Buchholz marti...@google.com wrote: On Mon, Mar 24, 2014 at 11:25 AM, Peter Levart peter.lev...@gmail.com wrote: On 03/24/2014 06:52 PM, Martin Buchholz wrote: On Wed, Mar 12, 2014 at 1:45 AM, Peter Levart peter.lev...@gmail.com wrote: What

Re: AWT Dev [9] Review request: new macro for conversion to jboolean

called JNU_CHECK_NULL to reduce collision chances and to make it clearer where it comes from .. -phil. On 3/19/2014 12:49 PM, Mike Duigou wrote: Definitely a useful macro. I too would prefer a name like TO_JBOOLEAN since it reveals the result type. Also all uppercase to identify

Re: AWT Dev [9] Review request: new macro for conversion to jboolean

Definitely a useful macro. I too would prefer a name like TO_JBOOLEAN since it reveals the result type. Also all uppercase to identify it as a macro. If we are paranoid and want to reduce the chance of a name collision then JNU_TO_JBOOLEAN perhaps. I would also define the macro as: #define

Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal

I On Mar 19 2014, at 15:01 , Brian Burkhalter brian.burkhal...@oracle.com wrote: On Mar 14, 2014, at 7:17 AM, Brian Burkhalter brian.burkhal...@oracle.com wrote: On Mar 14, 2014, at 3:39 AM, Peter Levart wrote: But in general it would be better to just use ThreadLocalRandom.current()

Re: RFR [8014066] Mistake in documentation of ArrayList#removeRange

Looks good. On Mar 18 2014, at 11:37 , Ivan Gerasimov ivan.gerasi...@oracle.com wrote: Sorry, here's the link: http://cr.openjdk.java.net/~igerasim/8014066/4/webrev/ On 18.03.2014 22:28, Ivan Gerasimov wrote: Hello! Would you please take a look at the next iteration of webrev? I

Re: RFR 8037106: Optimize Arrays.asList(...).forEach

Looks good to me. There are some additional optimization opportunities but they can certainly wait. Mike On Mar 14 2014, at 05:04 , Paul Sandoz paul.san...@oracle.com wrote: Hi, This patch overrides some default methods with more optimal ones for the Arrays.asList implementation:

Re: RFR 8037106: Optimize Arrays.asList(...).forEach

Looks good to me. There are some additional optimization opportunities but they can certainly wait. Mike On Mar 14 2014, at 05:04 , Paul Sandoz paul.san...@oracle.com wrote: Hi, This patch overrides some default methods with more optimal ones for the Arrays.asList implementation:

Re: RFR [8014066] Mistake in documentation of ArrayList#removeRange

On Mar 14 2014, at 05:14 , Ivan Gerasimov ivan.gerasi...@oracle.com wrote: On 14.03.2014 16:02, David Holmes wrote: Ivan, On 14/03/2014 9:19 PM, Ivan Gerasimov wrote: Thanks Peter for the comments. On 14.03.2014 14:53, Peter Levart wrote: On 03/14/2014 08:05 AM, Ivan Gerasimov wrote:

Re: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty

. http://cr.openjdk.java.net/~mduigou/JDK-8035584/2/webrev/ Mike On Tue, Mar 11, 2014 at 5:20 PM, Mike Duigou mike.dui...@oracle.com wrote: I've actually always used scp. :-) Since I accepted all of your changes as suggested and had no other changes I

Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal

On Mar 11 2014, at 01:05 , Sergey Kuksenko sergey.kukse...@oracle.com wrote: Brian, Mike. Could you explain what is the problem with the old caching? Concern over heap pollution with extra string copies was the motivation to ensure that only a single cached instance was ever returned.

RFR: 8037097: (s) Improve diagnosability of test failures for java/util/Arrays/Correct.java

Hello all; The test java/util/Arrays/Correct.java (yeah, great name...) has failed intermittently in nightly testing. Unfortunately the currently committed version does not provide much information on the failure condition. This changeset is a renovation of the test to hopefully provide

Re: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty

(i)==nullnbsp;:nbsp;o.equals(get(i)))}, Corrected. Thank you. http://cr.openjdk.java.net/~mduigou/JDK-8035584/2/webrev/ Mike On Tue, Mar 11, 2014 at 5:20 PM, Mike Duigou mike.dui...@oracle.com wrote: I've actually always used scp. :-) Since I accepted all of your changes as suggested

Re: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty

no longer working? On Tue, Mar 11, 2014 at 4:34 PM, Mike Duigou mike.dui...@oracle.com wrote: On Feb 21 2014, at 14:56 , Martin Buchholz marti...@google.com wrote: You should do tt - code conversion separately, and do it pervasively across the entire JDK. From your lips to God's ears I

Re: RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty

branches in the common case. Instead, if (initialCapacity 0) this.elementData = new Object[initialCapacity]; else if (initialCapacity == 0) this.elementData = EMPTY_ELEMENTDATA; else barf Corrected. Thanks as always for the feedback. Mike On Fri, Feb 21, 2014 at 2:41 PM, Mike

Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal

On Mar 4 2014, at 07:13 , Peter Levart peter.lev...@gmail.com wrote: On 03/04/2014 01:14 AM, Brian Burkhalter wrote: - add AtomicReferenceFieldUpdater-type constant for stringCache initialization Hi Brian, By using volatile read and CAS, there's still a chance that multiple

Re: JDK-8036003: Add variable not to separate debug information.

On Mar 1 2014, at 06:07 , Yasumasa Suenaga y...@ysfactory.dip.jp wrote: Hi David, 1. Generating debug symbols in the binaries (via gcc -g or whatever) 2. Generating debuginfo files (zipped or not) (FDS) 3. Stripping debug symbols from the binaries (strip-policy) It may be that we don't

Re: AWT Dev Proposal: Make JNU_Throw* clear a pending exception

Or a suppressed exception. Mike On Feb 25 2014, at 06:14 , Roger Riggs roger.ri...@oracle.com wrote: In some cases, I would expect that the exception being overridden would/should become the 'cause' of the new exception so it is not cleared but chained. Does JNI support that? On the

Re: RFR [6853696] (ref) ReferenceQueue.remove(timeout) may return null even if timeout has not expired

! On 24.02.2014 22:26, Mike Duigou wrote: On Feb 24 2014, at 06:37 , roger riggs roger.ri...@oracle.com wrote: Hi Ivan, The code is correct as written but there might be some creep in the end time due to the sampling of System.nanoTime. I would be inclined to calculate the final time

Re: RFR [6853696] (ref) ReferenceQueue.remove(timeout) may return null even if timeout has not expired

On Feb 24 2014, at 06:37 , roger riggs roger.ri...@oracle.com wrote: Hi Ivan, The code is correct as written but there might be some creep in the end time due to the sampling of System.nanoTime. I would be inclined to calculate the final time of the timeout once and then compare simply

RFR: 8035584: (s) ArrayList(c) should avoid inflation if c is empty

Hello all; This changeset consists of two small performance improvements for ArrayList. Both are related to the lazy initialization introduced in JDK-8011200. The first change is in the ArrayList(int capacity) constructor and forces lazy initialization if the requested capacity is zero. It's

Re: RFR: (8031737) CHECK_NULL and CHECK_EXCEPTION macros cleanup

This looks fine. On Feb 11 2014, at 15:42 , Phil Race philip.r...@oracle.com wrote: Here's a JDk8u webrev : -http://cr.openjdk.java.net/~prr/8031737.8u/ -phil. On 2/11/14 2:28 PM, Phil Race wrote: So since hg export/import doesn't apply cleanly and the dependency chain seems, long and

Re: RFR(XS): 8033909: Objects.requireNonNull(T, Supplier) doesn't specify what happens if the passed supplier is null itself

I would prefer to leave the implementation as is and amend the documentation. The difference in behaviour between the overloads seems OK since it will still be valid for the Supplier to return null. The String overload reasonably allows null since the Throwable(String) constructor allows null

Re: Draft JEP on enhanced volatiles

On Feb 10 2014, at 04:33 , Doug Lea d...@cs.oswego.edu wrote: Among the constraints on solution is that several of these methods compile down to no-ops on many common platforms. This is interpreted as a benefit. However, if the are no-ops only for the most common platform (x86) then we are

Re: ArrayList.removeAll()/retainAll()

The condition that is causing the problem is not a collection containing null, which is allowed, but that the provided collection c is itself null. The problem was is a consequence of the following implementation: IteratorE iterator = iterator(); while(iterator.hasNext()) {

Re: RFR [9] 8011645: CopyOnWriteArrayList.COWSubList.subList does not validate range properly

On Jan 31 2014, at 11:50 , Martin Buchholz marti...@google.com wrote: Jason, Thanks for pointing that out. I'm sure I have seen those bugs before (when I owned them!) but had suppressed the memory. I'm currently the assignee for this bug. I probably didn't try fixing them because there is

Re: ObjectIn/OutputStream improvements

Seems like good changes. ObjectStreamClass.java:: - Why not have getClassSignature() return an interned string? (that's if interning is actually essential. Are we sure it's not just overhead?) On Jan 31 2014, at 10:46 , Chris Hegarty chris.hega...@oracle.com wrote: Forwarding to correct

Re: RFR [9] 8011645: CopyOnWriteArrayList.COWSubList.subList does not validate range properly

On Jan 31 2014, at 15:09 , Jason Mehrens jason_mehr...@hotmail.com wrote: Martin, Mike, Totally agree with everything that has been said on this. Leaving it 'unresolved' or 'closed as will not fix' won't bother me. Mike has it listed as a 'doc clarification only' so my suggestion

Re: StringJoiner: detect or fix delimiter collision?

On Jan 26 2014, at 17:12 , Philip Hodges philip.hod...@bluewin.ch wrote: Please please please drop StringJoiner from Java 1.8 before it is too late. It is well past too late. The API has been frozen since August for all but the most exceptional cases. At first I thought they were cool. Then

RFR: 8022854 : (s) Cleaner re-initialization of System properties

Hello all; This is a bit of cleanup I did back during Java 8 that got deferred due to it's late arrival during the development cycle. I've updated it for Java 9. http://cr.openjdk.java.net/~mduigou/JDK-8022854/0/webrev/ This change improves the implementation of System.setProperties(null)

Re: RFR: 8032190 It's unclear that flatMap will ensure each stream will be closed.

On Jan 20 2014, at 07:18 , Paul Sandoz paul.san...@oracle.com wrote: On Jan 20, 2014, at 3:18 PM, Chris Hegarty chris.hega...@oracle.com wrote: It is good to clarify that the streams are closed. I find the following updated wording a little odd, If a mapped stream is {@code null} then

Re: RFR 8029452: Fork/Join task ForEachOps.ForEachOrderedTask clarifications and minor improvements

Very helpful. Thank you for adding the comments. Mike On Jan 16 2014, at 03:26 , Paul Sandoz paul.san...@oracle.com wrote: On Jan 10, 2014, at 2:42 PM, Paul Sandoz paul.san...@oracle.com wrote: I have also removed the inconsistently applied synchronized block. Either we apply it

Re: Doc updates was Re: RFR 8030848: Collections.sort(List l, Comparator) should defer to List.sort(Comparator )

The docs changes look good to me. Mike On Jan 13 2014, at 05:39 , Paul Sandoz paul.san...@oracle.com wrote: On Jan 10, 2014, at 3:01 PM, Alan Bateman alan.bate...@oracle.com wrote: The implementation changes look good. I agree that the javadoc needs changing as it's otherwise misleading as

Re: RFR 8030848: Collections.sort(List l, Comparator) should defer to List.sort(Comparator )

The implementation looks good. I would move construction of the listIterator to before the toArray() for detection of concurrent modification (growing of the list). I believe we should fix this for 8 if possible. Mike On Jan 10 2014, at 03:21 , Paul Sandoz paul.san...@oracle.com wrote: Hi,

Re: RFR 8029452: Fork/Join task ForEachOps.ForEachOrderedTask clarifications and minor improvements

On Jan 10 2014, at 05:42 , Paul Sandoz paul.san...@oracle.com wrote: Hi, Some tweaks to the Stream forEachOrdered operation: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8029452-ForEachOrdered/webrev/ The first tweak is to size the CHM used in ForEachOrderedTask, this avoids

Re: RFR: JDK-8029007, Check src/share/native/sun/misc code for JNI pending exceptions

On Jan 10 2014, at 10:09 , Chris Hegarty chris.hega...@oracle.com wrote: On 10 Jan 2014, at 18:05, Dan Xu dan...@oracle.com wrote: Hi Roger, My macro is a little different from yours, which compares with -1 instead of NULL. I also see CHECK_EXCEPTION macro. Thanks for adding them, which

Re: JDK 9 RFR - 8031142 [was: Re: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc]

If you navigate through http://cr.openjdk.java.net/~chegar/8031142/specdiff/java/util/package-summary.html it shows just the relevant diffs. It appears that the specdiff was generated without an explicit --includes option which results in all the extra chaff. Mike On Jan 6 2014, at 09:05 ,

  1   2   3   4   5   6   7   8   9   >