Re: RFR: 8166365: Small immutable collections should provide optimized implementations when possible

On 2017-01-11 23:38, Stuart Marks wrote: All done: http://cr.openjdk.java.net/~redestad/8166365/webrev.02/ Looks great! If all you do is restore private fields in Map1, no need for another webrev. Done, and pushed. Thanks! /Claes

Re: [9] RFR: 8171139: Simplify ResourceBundle.CacheKey and ClassLoader may not be needed

Hi Naoto, If I'm not mistaken, CacheKey is not subclassed anywhere, so it could be final. I'm wondering whether it would be a better idea to implement CacheKey.clone() with a private (copy?) constructor. It would make it possible to make most fields final: I believe it would be beneficial to have

RFR: 8037325: Class.getConstructor() performance regression

Hi, please review this fix to various performance regressions observed as the security model has evolved over the years. Bug: https://bugs.openjdk.java.net/browse/JDK-8037325 Webrev: http://cr.openjdk.java.net/~redestad/8037325/webrev.01 - For cases where a SecurityManager is not installed, thi

RFR: 8172720: Collections.SingletonList::hashCode not spec-compliant

Hi, there was an issue with my patch for JDK-8037325 where the hashCode implemented for Collections.SingletonList was not compliant with specification, which breaks certain tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8172720 Trivial fix: diff -r 59e5101730c8 src/java.base/share/classe

Re: RFR: 8172720: Collections.SingletonList::hashCode not spec-compliant

> On 12 Jan 2017, at 15:42, Claes Redestad wrote: > > Hi, > > there was an issue with my patch for JDK-8037325 where the > hashCode implemented for Collections.SingletonList was not > compliant with specification, which breaks certain tests. > > Bug: https://bugs.openjdk.java.net/browse/JDK-81

Re: RFR: 8172720: Collections.SingletonList::hashCode not spec-compliant

Thanks Chris! /Claes On 2017-01-12 17:03, Chris Hegarty wrote: On 12 Jan 2017, at 15:42, Claes Redestad wrote: Hi, there was an issue with my patch for JDK-8037325 where the hashCode implemented for Collections.SingletonList was not compliant with specification, which breaks certain tests.

Re: JDK 9 RFR of JDK-8156595: java/io/pathNames/GeneralWin32.java fail intermittently on windows-x64

> On 11 Jan 2017, at 23:07, Amy Lu wrote: > > On 1/12/17 11:14 AM, Hamlin Li wrote: >> Need to update the year in copyright, it's new year 2017, I guess lot of us >> do not notice it. > Thank you. Fixed :-) > Looks ok (although i must admit to not fully understanding all the idiosyncrasies o

Re: JDK 9 RFR of JDK-8146668: Replace custom check/range functionality with check index/range methods in java.util.Objects

HI Amy, Overall this looks very good, well done. At this point we are down to two things: 1) should we preserve exception messages? 2) due diligence on the performance. On 1) my preference is that uniform (and informative) messages are better for IndexOutOfBounds and subtypes, and defining

Re: RFR of JDK-8030950: TEST_BUG: java/rmi/registry/classPathCodebase/ClassPathCodebase.java failing intermittently

Hi Hamlin, ClassPathCodebase: - line 51: The comment says seconds but it is really milliseconds. security.policy: - line 21: "this its" -> "its" - line 26: Is the relative path in the File permission correct; Is there a ${test.xxx} path to refer to that file. registry.security.policy:

Re: RFR of JDK-8030950: TEST_BUG: java/rmi/registry/classPathCodebase/ClassPathCodebase.java failing intermittently

Hi Roger, Thank you for reviewing. Please check comments inline. On 2017/1/12 9:05, Roger Riggs wrote: Hi Hamlin, ClassPathCodebase: - line 51: The comment says seconds but it is really milliseconds. Yes, the comment little bit confusing, modified as "dozens of seconds", as it will wait for

Re: JDK 9 RFR of JDK-8146668: Replace custom check/range functionality with check index/range methods in java.util.Objects

We recently modernized all the *MicroBenchmark.java in java/util EXCEPT for RangeCheckMicroBenchmark. RangeCheckMicroBenchmark is old and crufty, but may still give us useful numbers. The range checking code in ArrayList was carefully written many years ago to make the hotspot of that time happy; I

Backport of JEP 254 (Compact Strings) to OpenJDK 8

I am interested in OpenJDK 8 builds with JEP 254 (Compact Strings) support backported from OpenJDK 9. I like the compact strings work that is being done in JDK 9, but I am interested in a OpenJDK 8 build with backported JEP 254 support since I am working with Java applications that might not wor

Re: Backport of JEP 254 (Compact Strings) to OpenJDK 8

On 01/12/2017 08:11 PM, John Platts wrote: > I am interested in OpenJDK 8 builds with JEP 254 (Compact Strings) support > backported from OpenJDK 9. I like the compact strings work that is being done > in JDK 9, but I am interested in a OpenJDK 8 build with backported JEP 254 > support since I am w

Re: [9] RFR: 8171139: Simplify ResourceBundle.CacheKey and ClassLoader may not be needed

Thank you, Mandy and Daniel for your comments. I incorporated your suggestions and updated the fix as follows: http://cr.openjdk.java.net/~naoto/8171139/webrev.02/ http://cr.openjdk.java.net/~naoto/8171140/webrev.00/ Please review. Naoto On 1/11/17 5:45 PM, Naoto Sato wrote: Decided to incl

Re: RFR: 8172720: Collections.SingletonList::hashCode not spec-compliant

Whoops, we all missed this one. Thanks for the quick fix. On 1/12/17 8:07 AM, Claes Redestad wrote: Thanks Chris! /Claes On 2017-01-12 17:03, Chris Hegarty wrote: On 12 Jan 2017, at 15:42, Claes Redestad wrote: Hi, there was an issue with my patch for JDK-8037325 where the hashCode imple

Re: RFR: 8172720: Collections.SingletonList::hashCode not spec-compliant

Grumpy here would like to point out that in his preferred never-ever broken world, this would have quietly been fixed with only Claes and his friendly neighborhood release engineer (who might be a bot) noticiing. On Thu, Jan 12, 2017 at 11:28 AM, Stuart Marks wrote: > Whoops, we all missed this

Re: RFR: 8166365: Small immutable collections should provide optimized implementations when possible

On 1/11/17 2:30 PM, Louis Wasserman wrote: I haven't followed this much, but an observation: in Guava, we avoided creating lots of specialized implementations for small collections, because the JVM, at least at the time, had a sweet spot for bimorphic dispatch: method calls where the real imple

Re: [9] RFR: 8171139: Simplify ResourceBundle.CacheKey and ClassLoader may not be needed

Realized moduleRef & callerRef would never be null with this new version. Thus modified the patch as: http://cr.openjdk.java.net/~naoto/8171139/webrev.03/ Naoto On 1/12/17 11:16 AM, Naoto Sato wrote: Thank you, Mandy and Daniel for your comments. I incorporated your suggestions and updated th

Re: RFR: JDK-8172432,jar cleanup/update for module and mrm jar

> On Jan 10, 2017, at 10:00 PM, Xueming Shen wrote: > > > webrev has been updated to catch IMDE and fails the jar as other fatal error > handing. > > http://cr.openjdk.java.net/~sherman/8172432/webrev > > This version includes new fixes

Re: RFR: 8166365: Small immutable collections should provide optimized implementations when possible

Note that the bimorphic rule is per callsite, it's fine to have several implementations if for a specific method call there are only two possibles implementations. cheers, Rémi - Mail original - > De: "Stuart Marks" > À: "Louis Wasserman" > Cc: "core-libs-dev" > Envoyé: Jeudi 12 Janvi

RFR(xs): 8172221: Directorate of Time has been superseded

Hi all, Please review this small patch to Date.java to remove the reference to the USNO's Directorate of Time, and to make minor adjustments to the text and the links. Thanks. s'marks # HG changeset patch # User smarks # Date 1484261274 28800 # Thu Jan 12 14:47:54 2017 -0800 # Node I

Re: RFR: JDK-8172432,jar cleanup/update for module and mrm jar

On 01/12/2017 01:46 PM, Mandy Chung wrote: On Jan 10, 2017, at 10:00 PM, Xueming Shen mailto:xueming.s...@oracle.com>> wrote: webrev has been updated to catch IMDE and fails the jar as other fatal error handing. http://cr.openjdk.java.net/~sherman/8172432/webrev This version includes new

Re: RFR: JDK-8172432,jar cleanup/update for module and mrm jar

http://cr.openjdk.java.net/~sherman/8172432/webrev.01 Validator.java 159 if (entryName.endsWith(MODULE_INFO)) { Does this have the same issue as the isModuleInfoEntry method addresses (i.e. META-INF/versioned/n/module-info.class)? I’m

Re: RFR: JDK-8172432,jar cleanup/update for module and mrm jar

On 01/12/2017 03:44 PM, Mandy Chung wrote: http://cr.openjdk.java.net/~sherman/8172432/webrev.01 Validator.java 159 if (entryName.endsWith(MODULE_INFO)) { Does this have the same issue as the isModuleInfoEntry method addresses (i.e.

Re: RFR: JDK-8172432,jar cleanup/update for module and mrm jar

> On Jan 12, 2017, at 4:08 PM, Xueming Shen wrote: > > On 01/12/2017 03:44 PM, Mandy Chung wrote: >> >> http://cr.openjdk.java.net/~sherman/8172432/webrev.01 >> >> >> Validator.java >> 159 if (entryName.endsWith(MODULE_INFO)) { >>

RFR JDK-8172761,Test change in tools/jar/InputFilesTest.java for JDK-8172432 is missing

Hi Mandy, Please review the change to push the missing test case change back. issue: https://bugs.openjdk.java.net/browse/JDK-8172761 webrev: http://cr.openjdk.java.net/~sherman/8172761 Thanks! Sherman

Re: RFR JDK-8172761, Test change in tools/jar/InputFilesTest.java for JDK-8172432 is missing

+1 Mandy > On Jan 12, 2017, at 9:02 PM, Xueming Shen wrote: > > Hi Mandy, > > Please review the change to push the missing test case change back. > > issue: https://bugs.openjdk.java.net/browse/JDK-8172761 > webrev: http://cr.openjdk.java.net/~sherman/8172761 > > Thanks! > Sherman

RFR of JDK-7146543: TEST_BUG: java/rmi/registry/readTest/readTest.sh failing intermittently with port in use

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-7146543 webrev: http://cr.openjdk.java.net/~mli/7146543/webrev.00/ The patch rewrite the test in java, fixes the bug. Thank you -Hamlin

Re: RFR: 8055206: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default

> On Jan 9, 2017, at 11:25 AM, Sean Mullan wrote: > > Please review this JDK 9 change to make the > SecurityManager::checkPackageAccess and checkPackageDefinition > implementations restrict access to the same set of internal JDK packages as > the module system. > > This overall change will i