Re: RFR 8164691 Stream specification clarifications for iterate and collect

Hi Paul, Overall looks good. A couple minor wording comments. For the 3-arg collectors, the combiner arg is defined as * @param combiner an associative, *href="package-summary.html#NonInterference">non-interfering, *stateless *f

RFR 8164691 Stream specification clarifications for iterate and collect

Hi, Please review some minor tweaks to the stream specification: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8164691-stream-iterate-collect-spec-updates/webrev/index.html The first

Proposal for adding O_DIRECT support into JDK 9

Dear All, This is a proposal for adding O_DIRECT support into JDK 9 for reading/writing from/to a file on Linux platform. O_DIRECT is a file-open flag to pass to OPEN (2). It tries to minimize cache effects of the I/O to and from this file. File I/O is done directly to/from user-space buffers.

Re: RFR: 8163232: CatalogResolver to extend XMLResolver and LSResourceResolver

Thanks Lance! Best, Joe On 8/26/16, 12:41 PM, Lance Andersen wrote: +1 On Aug 26, 2016, at 1:06 PM, Joe Wang > wrote: Hi, Please review a consolidation of resolver support to CatalogResolver. The purpose is to simplify the interface and usage scenarios so that

Re: RFR: 8163232: CatalogResolver to extend XMLResolver and LSResourceResolver

+1 > On Aug 26, 2016, at 1:06 PM, Joe Wang wrote: > > Hi, > > Please review a consolidation of resolver support to CatalogResolver. The > purpose is to simplify the interface and usage scenarios so that the one > CatalogResolver is usable for all JDK XML processors. As with the existing > res

Re: RFR: 8163232: CatalogResolver to extend XMLResolver and LSResourceResolver

Thanks Daniel! Best, Joe On 8/26/16, 12:01 PM, Daniel Fuchs wrote: Hi Joe, Looks good to me! -- daniel On 26/08/16 18:06, Joe Wang wrote: Hi, Please review a consolidation of resolver support to CatalogResolver. The purpose is to simplify the interface and usage scenarios so that the one C

Fwd: RFR 8163798: Add a versionedStream method to JarFile

Sorry, forget to Cc core-libs on my response to Peter’s questions > Begin forwarded message: > > From: Steve Drach > Subject: Re: RFR 8163798: Add a versionedStream method to JarFile > Date: August 26, 2016 at 9:44:39 AM PDT > To: Peter Levart > > Hi Peter, > >> Javadoc for the new method men

Re: RFR: 8163232: CatalogResolver to extend XMLResolver and LSResourceResolver

Hi Joe, Looks good to me! -- daniel On 26/08/16 18:06, Joe Wang wrote: Hi, Please review a consolidation of resolver support to CatalogResolver. The purpose is to simplify the interface and usage scenarios so that the one CatalogResolver is usable for all JDK XML processors. As with the exist

Re: RFR JDK-8066577: Cleanup and make better use of the stream API in the jrtfs code

> On 26 Aug 2016, at 09:48, Xueming Shen wrote: > > Hi, > > This is a aged rfe from Paul's code review comments for the old code. base. > The > implementation has been changed lots since. Some has gone, some has been > updated > accordingly. Just went through the list and here is the change

Re: RFR: 8164859 Fix module dependences in java/text tests

Looks good to me. Naoto On 8/26/16 7:59 AM, Alexandre (Shura) Iline wrote: Hi. Please review this simple fix: http://cr.openjdk.java.net/~shurailine/8164859/webrev.00/ This fix is only adding @modules with either java.desktop or jdk.localedata to number of tests - no other changes. Shura

RFR: 8163232: CatalogResolver to extend XMLResolver and LSResourceResolver

Hi, Please review a consolidation of resolver support to CatalogResolver. The purpose is to simplify the interface and usage scenarios so that the one CatalogResolver is usable for all JDK XML processors. As with the existing resolver interfaces, the change makes it no distinction between sys

RFR JDK-8066577: Cleanup and make better use of the stream API in the jrtfs code

Hi, This is a aged rfe from Paul's code review comments for the old code. base. The implementation has been changed lots since. Some has gone, some has been updated accordingly. Just went through the list and here is the change set for some minor issues still present. issue: https://bugs.op

Re: RFR: 8164866: tools/jlink/plugins/GenerateJLIClassesPluginTest.java can't compile after JDK-8163371

Thanks Sundar and Vladimir for reviewing quicker than I was able to correct myself! :-) /Claes On 2016-08-26 18:09, Claes Redestad wrote: On 2016-08-26 18:07, Claes Redestad wrote: Hi, JDK-8163371 forgot about the associated test. Changed it as necessary as some of the options are no long

http://cr.openjdk.java.net/~redestad/8164866/webrev.01/

Hi, JDK-8163371 forgot about the associated test. Changed it as necessary as some of the options are no longer implemented as of the latest changes: Bug: https://bugs.openjdk.java.net/browse/JDK-8164866 Webrev: http://cr.openjdk.java.net/~redestad/8164866/webrev.01/ Thanks! /Claes

RFR: 8164866: tools/jlink/plugins/GenerateJLIClassesPluginTest.java can't compile after JDK-8163371

On 2016-08-26 18:07, Claes Redestad wrote: Hi, JDK-8163371 forgot about the associated test. Changed it as necessary as some of the options are no longer implemented as of the latest changes: Bug: https://bugs.openjdk.java.net/browse/JDK-8164866 Webrev: http://cr.openjdk.java.net/~redestad

Re: http://cr.openjdk.java.net/~redestad/8164866/webrev.01/

+1 -Sundar On 8/26/2016 9:37 PM, Claes Redestad wrote: > Hi, > > JDK-8163371 forgot about the associated test. Changed it as necessary > as some of the options are no longer implemented as of the latest > changes: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164866 > Webrev: http://cr.openj

Re: http://cr.openjdk.java.net/~redestad/8164866/webrev.01/

Reviewed. Best regards, Vladimir Ivanov On 8/26/16 7:07 PM, Claes Redestad wrote: Hi, JDK-8163371 forgot about the associated test. Changed it as necessary as some of the options are no longer implemented as of the latest changes: Bug: https://bugs.openjdk.java.net/browse/JDK-8164866 Webrev:

RFR: 8164859 Fix module dependences in java/text tests

Hi. Please review this simple fix: http://cr.openjdk.java.net/~shurailine/8164859/webrev.00/ This fix is only adding @modules with either java.desktop or jdk.localedata to number of tests - no other changes. Shura

Re: RFR: 8163371: Enable tracing which JLI classes can be pre-generated

On 2016-08-26 15:40, Vladimir Ivanov wrote: Reviewed. Thanks for reviewing! /Claes Best regards, Vladimir Ivanov On 8/26/16 4:26 PM, Claes Redestad wrote: Hi, please review this change which adds a means to trace what LFs and BMH classes we try to resolve at runtime (and whether we fail

Re: RFR: 8163371: Enable tracing which JLI classes can be pre-generated

Reviewed. Best regards, Vladimir Ivanov On 8/26/16 4:26 PM, Claes Redestad wrote: Hi, please review this change which adds a means to trace what LFs and BMH classes we try to resolve at runtime (and whether we failed or succeeded), along with an update to the --generate-jli-classes plugin to t

RFR: 8163371: Enable tracing which JLI classes can be pre-generated

Hi, please review this change which adds a means to trace what LFs and BMH classes we try to resolve at runtime (and whether we failed or succeeded), along with an update to the --generate-jli-classes plugin to take as it's input a file containing the output of such tracing. Bug: https://bugs.op

Re: RFR 8163798: Add a versionedStream method to JarFile

On 26/08/2016 00:30, Steve Drach wrote: Hi, Please review this changeset that adds a versionedStream method to JarFile. webrev: http://cr.openjdk.java.net/~sdrach/8163798/webrev.00/ issue: https://bugs.openjdk.java.net/browse/JDK-8163798

Re: RFR (S): JDK-8164086: Checked JNI pending exception check should be cleared when returning to Java frame

Hi David, Updated webrev: http://cr.openjdk.java.net/~dsimms/8164086/webrev2/ On 26/08/16 02:27, David Holmes wrote: Hi David, I'm missing some pieces of this puzzle I'm afraid. On 25/08/2016 8:05 PM, David Simms wrote: Updated the webrev here: http://cr.openjdk.java.net/~dsimms/8164086/web

Re: RFR 8163798: Add a versionedStream method to JarFile

Hi Steve, Here are my observations. I haven't followed the development of multi-release jar files very closely, so I might be missing some quirks, but I speak here from the knowledge I get from the javadocs... Javadoc for the new method mentions public and non-public classes: "@{code JarEntr