Re: RFR: JDK-8066619: String(byte[],int,int,int) in String has been deprecated in Manifest and Attributes

Hi Roger, I guess I followed it up this time now. I guess my previous patches were actually based on 54aafb3ba9ab from September 25. And Eclipse never told me...In difference to the webrev one more line was intended to be removed: @SuppressWarnings("deprecation") at Manifest#read. New patch attache

8215441: Increase uniformity of the distribution of BigIntegers constructed by BigInteger(int, Random)

https://bugs.openjdk.java.net/browse/JDK-8215441 This issue was filed to cover improving the uniformity of randomly generated BigIntegers. It is not intended to resolve [1] which is deliberately left open. The proposed patch implements a modified version of the “workaround” suggested in [1]. T

Re: RFR: JDK-8215648: remove equals and hashCode implementations from j.l.i.VarHandle

Looks fine to me. Mandy On 12/19/18 1:27 PM, Vicente Romero wrote: Please review fix for [1] at [2]. The fx is basically removing the implementation of methods VarHandle::equals and VarHandle::hashCode to make var handles consistent with method handles which don't override the default impleme

Re: RFR - CSR JDK-8215490 Remove String::align

looks good, Vicente On 12/19/18 2:47 PM, Jim Laskey wrote: CSR: https://bugs.openjdk.java.net/browse/JDK-8215490 Thank you. Cheers, — Jim JBS: https://bugs.openjdk.java.net/browse/JDK-8215489

Re: jpackage EA Build 0

If the main jar is in a subfolder the .cfg file is written incorrectly leading to: Error: Could not find or load main class Caused by: java.lang.ClassNotFoundException: Which I only found by manually running: ./MyApp.app/Contents/MacOS/MyApp as double clicking doesn’t seem to show tha

Re: RFR: JDK-8215648: remove equals and hashCode implementations from j.l.i.VarHandle

Please review also the related CSR: https://bugs.openjdk.java.net/browse/JDK-8215649 Thanks, Vicente On 12/19/18 4:27 PM, Vicente Romero wrote: Please review fix for [1] at [2]. The fx is basically removing the implementation of methods VarHandle::equals and VarHandle::hashCode to make var ha

RFR: JDK-8215648: remove equals and hashCode implementations from j.l.i.VarHandle

Please review fix for [1] at [2]. The fx is basically removing the implementation of methods VarHandle::equals and VarHandle::hashCode to make var handles consistent with method handles which don't override the default implementation for these methods, Thanks, Vicente [1] https://bugs.openjdk

Re: Type variable information is not always maintained for anonymous classes

Hi, Coming back to the topic, I feel like I need some help. Below is a stack trace so things would be easier to explain: "main@1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at sun.reflect.generics.scope.ClassScope.computeEnclosingScope(ClassScope.java:51) at su

RFR - JDK-8215493 String::indent inconsistency with blank lines

Please review these changes for jdk 12. webrev: http://cr.openjdk.java.net/~jlaskey/8215493/webrev/index.html There is inconsistency with regards to blank lines and indentation. Adding indent space ignores blank lines, where subtra

RFR - CSR JDK-8215490 Remove String::align

CSR: https://bugs.openjdk.java.net/browse/JDK-8215490 Thank you. Cheers, — Jim JBS: https://bugs.openjdk.java.net/browse/JDK-8215489 webrev: http://cr.openjdk.java.net/~jlaskey/8215489/webre

Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

On 12/19/18 4:15 PM, Martin Buchholz wrote: On Wed, Dec 19, 2018 at 6:59 AM Roger Riggs wrote: Hi Martin, It is also useful and conventional to print the seed of the random so that if necessary it can be reproduced. For many years, we've been using ThreadLocalRandom for testing, and tha

Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

I was thinking about testing resizing with items in buckets. Test like this. Can you please include it to changeset? (I can see you have prepared full webrev from changeset, so I'm not posting new one.) @Test public void resizeInternalTableWithBucketsTest() { Map m = new HashMap

Re: [12] RFR for JDK-8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry

Thank you, Daniel, for your quick review. On 19/12/2018 15:05, Daniel D. Daugherty wrote: On 12/19/18 9:23 AM, Alexey Ivanov wrote: Any volunteers from core-libs and serviceability to review? How about former Serviceability Team members? :-) Alan B. and I both used to be on the Serviceability

Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

On Wed, Dec 19, 2018 at 7:01 AM Chris Hegarty wrote: > > Also, please add the jtreg key so that the test is identifiable as using > randomness: `@key randomness` . > Done, but I remain unconvinced of the value of doing so.

Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

On Wed, Dec 19, 2018 at 6:59 AM Roger Riggs wrote: > Hi Martin, > > It is also useful and conventional to print the seed of the random > so that if necessary it can be reproduced. > For many years, we've been using ThreadLocalRandom for testing, and that does not allow setting a seed. I remain

Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

> On 19 Dec 2018, at 15:01, Chris Hegarty wrote: > > Martin, > > Is it possible to use the the JDK’s test library jdk.test.lib.RandomFactory, > so that the initial seed is captured and rep*l*ayable. -Chris.

Re: [12] RFR for JDK-8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry

On 12/19/18 9:23 AM, Alexey Ivanov wrote: Any volunteers from core-libs and serviceability to review? How about former Serviceability Team members? :-) Alan B. and I both used to be on the Serviceability Team... And Alan B. is a current member of Core Libs... > webrev: http://cr.openjdk.java.n

Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

Martin, Is it possible to use the the JDK’s test library jdk.test.lib.RandomFactory, so that the initial seed is captured and repayable. Also, please add the jtreg key so that the test is identifiable as using randomness: `@key randomness` . -Chris. > On 19 Dec 2018, at 14:47, Martin Buchholz

Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

Hi Martin, It is also useful and conventional to print the seed of the random so that if necessary it can be reproduced. Roger On 12/19/2018 09:01 AM, Martin Buchholz wrote: On Tue, Dec 18, 2018 at 10:48 PM Michal Vala wrote: Randomized test is not deterministic now. Can we have also origi

enhanced for loop with multiple iteration variables

Has any consideration been given to supporting iterators that provide more than one iteration variable in the enhanced for loop? Obvious uses would be maps (keys and values) and lists (indexes and values). I have in mind keeping the syntactic sugar approach by using one or more extensions of th

Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

Let's add whitebox tests for initial capacity and LinkedHashMap, as with ConcurrentHashMap's whitebox tests. --- src/test/jtreg/util/HashMap/WhiteBoxResizeTest.java 18 Dec 2018 20:21:24 - 1.1 +++ src/test/jtreg/util/HashMap/WhiteBoxResizeTest.java 19 Dec 2018 14:35:50 - @@ -27,7 +27,11 @@

Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

On 12/19/18 3:01 PM, Martin Buchholz wrote: On Tue, Dec 18, 2018 at 10:48 PM Michal Vala wrote: Randomized test is not deterministic now. Can we have also original one? We may have an irreconcilable difference of testing philosophy. (yes, mainstream testing thought has embraced determi

Re: [12] RFR for JDK-8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry

Any volunteers from core-libs and serviceability to review? Regards, Alexey On 12/12/2018 16:43, Magnus Ihse Bursie wrote: On 2018-12-12 17:38, Alexey Ivanov wrote: Hi all, I have updated the summary of JDK-8214122 and the subject accordingly. Could you please review the following fix? htt

Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

On Tue, Dec 18, 2018 at 10:48 PM Michal Vala wrote: > Randomized test is not deterministic now. Can we have also original one? > We may have an irreconcilable difference of testing philosophy. (yes, mainstream testing thought has embraced determinism)

Re: Proposal: ArrayList constructor perforrmance improvement

Thanks as always to Jason, our master Historian. On Wed, Dec 19, 2018 at 2:14 AM Steve Groeger wrote: > > Yes, the intent was to leave the backing array the same size in order to > avoid to have the resize of it when a new element is added. > So, if someone wanted to reduce the size of the backi

Re: Proposal: ArrayList constructor perforrmance improvement

Jason & Stuart, Yes, the intent was to leave the backing array the same size in order to avoid to have the resize of it when a new element is added. So, if someone wanted to reduce the size of the backing array then they could use the ArrayList.trimToSize() method. However, if you are saying

RE: RFR (S): 8215472: Cleanups in implementation classes of jdk.zipfs and tests

Hi Sherman, thanks for the confirmation. Further refactoring regarding Deflator caching can be done with a separate issue. So, hearing no objections I'll push the patch once my testing is done. Best regards Christoph > -Original Message- > From: core-libs-dev On Behalf > Of Xueming Sh

Re: RFR: 8198526: getAnnotatedOwnerType does not handle static nested classes correctly

Hi Liam, This makes sense to me. Since nestingForType is used to navigate scoping/nesting in more cases than owner type and javac seem to be inconsistent with regards to locations (see [1] for example), will this break or fix something else? [1] https://bugs.openjdk.java.net/browse/JDK-8148504 c