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 compl

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 themselves. http:

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 object-bearing methods. Why not put the method on Compa

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 implementatio

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 t

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 http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/

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

est webrev: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Hashtable.8068427/webrev.03/ >>> >>> Is this ok now? >>> >>> Regards, Peter >>> >>> >>>> On 01/09/2015 11:16 AM, Peter Levart wrote: >>>

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 il

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 wrote: > Hi Aleksey, > > On Sep 22, 2014, at 2:43 PM, Aleksey Shipilev > wrote: > >> Hm, and this compiler transformation works in strictfp context? I hope >> compilers do the constant folding in strictfp/fdlibm mode… > > Y

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

etween however I suppose that there > will be some numerical inconsistencies between the two versions. > > Brian > > On Sep 22, 2014, at 2:24 PM, Mike Duigou wrote: > >> Looks fine. >> >> I think it is always important note when a change may result in diffe

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 u

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 wrote: > Just think - one whole

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 wrote: > Hello dear list, > > it was not my intention to steal precio

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 Enumera

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 wrote: > On 25/08

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

On Aug 14 2014, at 06:39 , Alan Bateman 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 can be left >

Re: new StringBuilder(char)

On Aug 15 2014, at 22:38 , Jeremy Manson 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 backwards-incompatibl

Re: new StringBuilder(char)

On Aug 16 2014, at 16:24 , Ulf Zibis 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 optimization then it might

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 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 has been updated in i

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

on. Mike > > -Chris. > > On 24 Jul 2014, at 08:12, Mike Duigou wrote: > >> Hello all; >> >> This change fixes an issue with the instance returned by >> Collections.synchronizedNavigableSet().tailSet(Object,boolean) which >> synchronizes on w

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: http://cr.ope

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. https://bugs.

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

uld save one comparison. > > Sincerely yours, > Ivan > > On 19.07.2014 1:14, Claes Redestad 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

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

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 String

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 20

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 targ

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

Looks fine. On Jul 11 2014, at 18:11 , Stuart Marks 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 relies on support for ol

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: [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 B

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 TestNG).

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

On Jun 25 2014, at 01:30 , Paul Sandoz wrote: > On Jun 24, 2014, at 8:25 PM, Mike Duigou wrote: >> >> On Jun 24 2014, at 01:18 , Paul Sandoz wrote: >>>> Additionally the javadoc is updated to inform users that a >>>> ClassCastException may result if t

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

On Jun 24 2014, at 01:18 , Paul Sandoz wrote: >> Additionally the javadoc is updated to inform users that a >> ClassCastException may result if the proposed replacement is unacceptable. >> > > No users will see the JavaDoc on Collections.CheckedList since it is package > private, plus i think

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

u should probably add @SuppressWarnings("unchecked”) to > typeCheck(Object). Done. > > -Chris. > > On 24 Jun 2014, at 01:42, Mike Duigou wrote: > >> Hello all; >> >> This changeset corrects a reported problem with the lists returned by >> Collec

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 in

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 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 platform. This is part of 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. j

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 f

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 wrote: > Hello! > > Some functions were renamed with the fix for JDK-8015318. > A few of them kept their old

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 wrote: > Hi everyone, > > could you please review my change for JDK-7153400? > > http://cr.openjdk.java.net/~chegar/715340

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

On May 5 2014, at 11:54 , Ivan Gerasimov 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 wit

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 Ge

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 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 pipelines does >

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

ata > race > +public boolean addAll(int index, Collection c) { > if (index < 0 || index > elementCount) > throw new ArrayIndexOutOfBoundsException(index); > > > > On Wed, Apr 16, 2014 at 10:30 AM, Mike Duigou wrote: > Yes. This has been

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 dec

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

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

seems like insane > > churn to replace the arrays that frequently. > > > There are more   changes that need to be reverted. > > > Else looks good. > > > - * More formally, returns the lowest index i such that > > > - * > > > (o==null ? get(i)==nul

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

ems like insane > > churn to replace the arrays that frequently. > > > There are more   changes that need to be reverted. > > > Else looks good. > > > - * More formally, returns the lowest index i such that > > > - * > > > (o==null ? get(i)==null : o.equa

Re: JDK 9 RFR of 8027595: Enable BigInteger overflow tests in JTREG

Seems reasonable. Though it's sad to not be able to turn the tests on when they could be run. I have heard that jtreg will be sprouting a new capability which would allow this. Mike On Apr 18 2014, at 10:23 , Brian Burkhalter wrote: > > On Apr 16, 2014, at 6:42 PM, Brian Burkhalter > wrot

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 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-80208

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

On Apr 14 2014, at 18:25 , Martin Buchholz 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 crazy thing o

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

p://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.143.8940&rep=rep1&type=pdf On Apr 4 2014, at 02:07 , Paul Sandoz wrote: > On Apr 4, 2014, at 1:42 AM, Mike Duigou wrote: >>> >>> I could live with that change in behaviour, but this change completely >>> b

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

I and others have tried to track down the compiler issue in which this change was made. If anyone can point us in the right direction it would be nice to reference that issue. Mike On Apr 11 2014, at 13:09 , Chris Hegarty wrote: > >> On 11 Apr 2014, at 21:04, Mike Duig

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

> > > On Fri, Apr 11, 2014 at 12:22 PM, Mike Duigou 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

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 ini

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

On Apr 10 2014, at 11:08 , Chris Hegarty wrote: > >> On 10 Apr 2014, at 18:40, Mike Duigou wrote: >> >> >>> On Apr 10 2014, at 03:21 , Chris Hegarty wrote: >>> >>>> On 10 Apr 2014, at 11:03, Ulf Zibis wrote: >>>> >&

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

> How can one keep it symmetrical without forcing a particular encoding? > > Brian > > On Apr 10, 2014, at 10:54 AM, Mike Duigou wrote: > >> Shouldn't we be using the platform default character set rather than >> iso8859-1? >> >> This change

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 but

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

On Apr 10 2014, at 03:21 , Chris Hegarty wrote: > On 10 Apr 2014, at 11:03, Ulf Zibis 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 avoid the cost of String to >

Re: UUID.compareTo broken?

On Apr 8 2014, at 01:03 , Paul Sandoz wrote: > > On Apr 7, 2014, at 7:23 PM, Mike Duigou 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?

wrote: > >> >> On Apr 7, 2014, at 7:23 PM, Mike Duigou 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 Jav

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

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

On Mar 25 2014, at 21:21 , David Holmes wrote: > Mike, > > On 26/03/2014 6:37 AM, Mike Duigou wrote: >> Hello all; >> >> Recently HotSpot gained additional support for transactional memory, >> <https://bugs.openjdk.java.net/browse/JDK-8031320>. This pa

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

Hello all; Recently HotSpot gained additional support for transactional memory, . This patch is a libraries followon to that change. RTM and other transactional memory implementations benefit from clustering writes towards the end of the transac

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

On Mar 24 2014, at 12:25 , Martin Buchholz wrote: > > > > On Mon, Mar 24, 2014 at 11:25 AM, Peter Levart wrote: > > On 03/24/2014 06:52 PM, Martin Buchholz wrote: >> >> >> >> On Wed, Mar 12, 2014 at 1:45 AM, Peter Levart wrote: >> >> What would the following cost? >> >> >> privat

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

e JNU_CHECK_NULL CHECK_NULL >>>> #define JNU_CHECK_NULL_RETURN CHECK_NULL_RETURN >>>> >>>> so we could migrate to these (clearer) ones >>>> >>>> -phil. >>>> >>>> On 3/19/2014 1:05 PM, Phil Race wrote: >&

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

I On Mar 19 2014, at 15:01 , Brian Burkhalter wrote: > > On Mar 14, 2014, at 7:17 AM, Brian Burkhalter > wrote: > >> On Mar 14, 2014, at 3:39 AM, Peter Levart wrote: >> >>> But in general it would be better to just use "ThreadLocalRandom.current()" >>> everywhere you use "rnd" variable. Thi

Re: [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 JNU

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

Looks good. On Mar 18 2014, at 11:37 , Ivan Gerasimov 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 incorporated the las

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

On Mar 14 2014, at 05:14 , Ivan Gerasimov 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 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 wrote: > Hi, > > This patch overrides some default methods with more optimal ones for the > Arrays.asList implementation: > > > http://cr.openjdk

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 wrote: > Hi, > > This patch overrides some default methods with more optimal ones for the > Arrays.asList implementation: > > > http://cr.openjdk

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

e formally, returns the lowest index i such that > > > - * > > > (o==null ? get(i)==null : o.equals(get(i))), > > > + * More formally, returns the lowest index {@code i} such that > > > + * {@code > > > (o==null ? get(i)==null : o.equals(get(i)))}, > >

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

ard minimize overhead > in the common case. In the above, we now have two branches in the common > case. Instead, > > if (initialCapacity > 0) this.elementData = new Object[initialCapacity]; > else if (initialCapacity == 0) this.elementData = EMPTY_ELEMENTDATA; > else

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

cr > no longer working"? > > > On Tue, Mar 11, 2014 at 4:34 PM, Mike Duigou wrote: > > On Feb 21 2014, at 14:56 , Martin Buchholz wrote: > >> You should do -> code conversion separately, and do it pervasively >> across the entire JDK. > > From y

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

{@code > (o==null ? get(i)==null : 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 wrote: > I've actually always used scp. :-) > > Since I accepted all o

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 additio

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

On Mar 11 2014, at 01:05 , Sergey Kuksenko 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. > String is immutable, BigD

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

On Mar 4 2014, at 07:13 , Peter Levart 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 > concurrent threads wil

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

On Mar 1 2014, at 06:07 , Yasumasa Suenaga 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 have clean

Re: Proposal: Make JNU_Throw* clear a pending exception

Or a suppressed exception. Mike On Feb 25 2014, at 06:14 , Roger Riggs 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 original issue, discar

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

24.02.2014 22:26, Mike Duigou wrote: >> On Feb 24 2014, at 06:37 , roger riggs 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. >>>

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 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 with the curren

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 be

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

This looks fine. On Feb 11 2014, at 15:42 , Phil Race 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 in order to ha

Re: Draft JEP on enhanced volatiles

On Feb 10 2014, at 04:33 , Doug Lea 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 likely to see a ro

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 me

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: Iterator iterator = iterator(); while(iterator.hasNext()) { if(c.contains(ite

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

On Jan 31 2014, at 15:09 , Jason Mehrens 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 toward a > resolution wo

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 wrote: > Forwarding to correct core-libs-dev list. > > -C

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

On Jan 31 2014, at 11:50 , Martin Buchholz 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 no clean way ou

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) which

Re: StringJoiner: detect or fix delimiter collision?

On Jan 26 2014, at 17:12 , Philip Hodges 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 I tried to use the

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

On Jan 20 2014, at 07:18 , Paul Sandoz wrote: > > On Jan 20, 2014, at 3:18 PM, Chris Hegarty 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 it treated as if it was an empty s

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 wrote: > > On Jan 10, 2014, at 2:42 PM, Paul Sandoz wrote: >> I have also removed the inconsistently applied synchronized block. Either we >> apply it consistently to reporting or not at all. It was

Re: Doc updates 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 wrote: > On Jan 10, 2014, at 3:01 PM, Alan Bateman wrote: >> The implementation changes look good. I agree that the javadoc needs >> changing as it's otherwise misleading as to what the implementation actually >> d

  1   2   3   4   5   6   7   8   9   10   >