RFR: 8165723: JarFile::isMultiRelease() method returns false when it should return true

Hi, JDK-8152733 introduced a corner-case where isMultiRelease returns false when it should return true due to an erroneously hand-crafted Boyer-Moore search. Webrev: http://cr.openjdk.java.net/~redestad/8165723/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8165723 Testing: created a

Re: [9] RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base

Thanks. Created an issue for the follow-on issue: https://bugs.openjdk.java.net/browse/JDK-8165804 Naoto On 9/9/16 3:34 PM, Mandy Chung wrote: On Sep 9, 2016, at 2:58 PM, Naoto Sato wrote: While at it, I noticed two build issues and updated the webrev. They are not

RFR: 8163798: Create a JarFile versionedStream method

Hi, Please review this changeset that adds a VersionedStream class to the jdk.internal.util.jar package. Some may recall that I submitted a similar RFR a few weeks ago; this is a redesign from that one. We decided not to make a public JarFile::versionedStream method at this time. Once we

Re: [9] RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base

> On Sep 9, 2016, at 2:58 PM, Naoto Sato wrote: > > While at it, I noticed two build issues and updated the webrev. They are not > directly related to the split package issue per se, but related to Thai > breakiterator: > > 1) BreakIteratorRules_th.class slipped into

Re: [9] RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base

While at it, I noticed two build issues and updated the webrev. They are not directly related to the split package issue per se, but related to Thai breakiterator: 1) BreakIteratorRules_th.class slipped into the product image, which shouldn't. 2) Removed BreakIteratorRulesProvider.java

Re: RFR(XS): 8165393: bad merge in java/lang/ref/package-info.java

> On Sep 9, 2016, at 4:27 PM, Roger Riggs wrote: > > Hi Kim, > > Looks good, thanks for the correction. Thanks. > > Roger > > > On 9/9/2016 4:23 PM, Kim Barrett wrote: >> Please review this fix of a merge error in the package-info for >> java.lang.ref. >> >> This

Re: RFR(XS): 8165393: bad merge in java/lang/ref/package-info.java

Hi Kim, Looks good, thanks for the correction. Roger On 9/9/2016 4:23 PM, Kim Barrett wrote: Please review this fix of a merge error in the package-info for java.lang.ref. This is a doc-only change; per the RDP1 process the CR has been labeled "noreg-doc". CR:

Re: RFR 8165726: fix for 8165595 revealed a bug in pack200 tool's handling of main class attribute of module-info classes

On 09/09/2016 19:15, Kumar Srinivasan wrote: Looks good, thanks for taking care of it. We need to double check these again, I will take a closer look later. It's a CONSTANT_Class_info so I think it's right. It would be good to check the others as it's easy to get these wrong, maybe additional

RFR(XS): 8165393: bad merge in java/lang/ref/package-info.java

Please review this fix of a merge error in the package-info for java.lang.ref. This is a doc-only change; per the RDP1 process the CR has been labeled "noreg-doc". CR: https://bugs.openjdk.java.net/browse/JDK-8165393 Webrev: http://cr.openjdk.java.net/~kbarrett/8165393/webrev/

Re: RFR(s): 4285505: deprecate java.lang.Compiler

Hi Roger, Thanks for mentioning bug JDK-8041676. As far as I understand, the java.compiler property is intended to be set by the user in order to tell the JVM which JIT compiler to use. This is hinted at in the text I'm removing from the java.lang.Compiler spec in this changeset. The

Re: RFR 8165726: fix for 8165595 revealed a bug in pack200 tool's handling of main class attribute of module-info classes

Looks good, thanks for taking care of it. We need to double check these again, I will take a closer look later. Kumar On 9/9/2016 9:36 AM, Sundararajan Athijegannathan wrote: Please review http://cr.openjdk.java.net/~sundar/8165726/webrev.01/ for

RFR 8165726: fix for 8165595 revealed a bug in pack200 tool's handling of main class attribute of module-info classes

Please review http://cr.openjdk.java.net/~sundar/8165726/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8165726 Thanks, -Sundar

Re: [9] RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base

The build tool is getting the output directory as a parameter and that also need to be tweaked. That output directory path is specified in the makefile which I wanted to avoid. Naoto On 9/8/16 4:31 PM, Masayoshi Okutsu wrote: Is it just a matter of an extra step, new File(path).getName()?

Re: [8u-dev] Request for Review and Approval to backport: 8165243: Base64.Encoder.wrap(os).write(byte[], int, int) with incorrect arguments should not produce output

Thank you very much Seán! On 09.09.2016 18:50, Seán Coffey wrote: Looks fine Ivan. Reviewed. Approved for jdk8u-dev. Regards, Sean. On 09/09/16 16:43, Ivan Gerasimov wrote: Hello! I'd like to backport this fix to jdk8u. The unshuffled fix applies almost clearly: I only had to slightly

Re: [8u-dev] Request for Review and Approval to backport: 8165243: Base64.Encoder.wrap(os).write(byte[], int, int) with incorrect arguments should not produce output

Looks fine Ivan. Reviewed. Approved for jdk8u-dev. Regards, Sean. On 09/09/16 16:43, Ivan Gerasimov wrote: Hello! I'd like to backport this fix to jdk8u. The unshuffled fix applies almost clearly: I only had to slightly modify the regression test. Bug:

[8u-dev] Request for Review and Approval to backport: 8165243: Base64.Encoder.wrap(os).write(byte[], int, int) with incorrect arguments should not produce output

Hello! I'd like to backport this fix to jdk8u. The unshuffled fix applies almost clearly: I only had to slightly modify the regression test. Bug: https://bugs.openjdk.java.net/browse/JDK-8165243 Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a81f30fb7d8c Jdk9 review:

Re: RFR 9: 8155760 Implement Serialization Filtering

Hi Andrej, Thanks for the review and comments.. On 9/9/2016 2:32 AM, Andrej Golovnin wrote: Hi Roger, src/java.base/share/classes/java/io/ObjectInputStream.java 259 private static class Logging { The class can be final. But there is no advantage or limitation since it is an private

Re: [9] RFR: 8165605: Thai resources in jdk.localedata cause split package issue with java.base

Build change looks ok. /Erik On 2016-09-08 17:37, Naoto Sato wrote: Updated the webrev wrt the latter comment: http://cr.openjdk.java.net/~naoto/8165605/webrev.02/ Naoto On 9/7/16 6:37 PM, Mandy Chung wrote: On Sep 7, 2016, at 6:29 PM, Naoto Sato wrote: Hi

Re: RFR(s): 4285505: deprecate java.lang.Compiler

Hi Stuart, Related to java.lang.Complier there is the System property "java.compiler" [1]. Is there some notation needed on the property or will it just go poof when the compiler is removed? Thanks, Roger [1] JDK-8041676 java.compiler

Re: Review Request: JDK-8165346 j.l.ClassLoader.getDefinedPackage(String) throws NPE

On 08/09/2016 23:02, Mandy Chung wrote: Spec bug: missing @throws NPE if the specified name is null in the relevant getPackage methods: ClassLoader.getDefinedPackage, ClassLoader::getPackage, Package::getPackage Webrev at:

Re: RFR 8165634: Support multiple --add-module options on the command line

Thanks Lois, for the review. Harold On 9/8/2016 1:12 PM, Lois Foltan wrote: On 9/8/2016 9:23 AM, harold seigel wrote: Hi, Please review this fix for JDK-8165634. The fix changes the --add-modules option from being a 'last one wins' option to a cumulative one. With this change, if

Re: RFR 8165634: Support multiple --add-module options on the command line

Hi Gerard, Thanks for the review! Please see comments inline. Harold On 9/8/2016 12:24 PM, Gerard Ziemski wrote: hi Harold, The changes look fine. I have a couple of questions though: #1 Would the "test/runtime/modules/ModuleOptionsTest.java” be more robust if we included a case with a

Re: RFR(s): 4285505: deprecate java.lang.Compiler

On 08/09/16 17:08, Krystal Mok wrote: > Thanks for your reply. It's good to know at least the known use cases > from IBM have indeed been discussed. > > On Thu, Sep 8, 2016 at 9:01 AM, Tim Ellison > wrote: > > On 07/09/16 23:45, Krystal

Re: RFR: 8165492: Reduce number of lambda forms generated by MethodHandleInlineCopyStrategy

On 2016-09-09 12:35, Vladimir Ivanov wrote: Looks good. As others, I prefer InternalError over IllegalStateException when buffer size mismatch. Done: http://cr.openjdk.java.net/~redestad/8165492/webrev.02/ Gave it an extra round of testing since if there was a bug somewhere it might have

Re: RFR: 8165492: Reduce number of lambda forms generated by MethodHandleInlineCopyStrategy

Webrev: http://cr.openjdk.java.net/~redestad/8165492/webrev.01/ Looks good. As others, I prefer InternalError over IllegalStateException when buffer size mismatch. Best regards, Vladimir Ivanov Testing: RBT, no regressions observed on microbenchmarks[1], while recuperating ~25-30% of

Re: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream

Hi Patrick, looks good for me. Thanks! Best regards, Andrej Golovnin

Re: RFR 9: 8155760 Implement Serialization Filtering

Hi Roger, src/java.base/share/classes/java/io/ObjectInputStream.java 259 private static class Logging { The class can be final. 1265 ? Logger.Level.DEBUG There is one space too much before "Logger". 2611 /** total bytes read from the stream */