Re: RFR: JEP draft for Linux/s3990x port

Hi Vladimir, thanks for keeping us updated and hanks for setting the integrations date on the JEP. We think it is reasonable to do it before the JDK 10 forest will be forked as this will obviously save us a lot of work. The remaining shared changes are "8166561: [s390] Adaptions needed for s390

Re: RFR:JDK-8163330:HijrahDate aligned day of week incorrect

Thanks Roger, appreciate that. > On Oct 13, 2016, at 3:09 AM, Roger Riggs wrote: > > Hi, > > Looks ok. > > Typically, there is a space after the '//' comment characters, it makes it > easier to read. > Also, in this case, I don't think the comments help. "Monday" isn't > important to the te

Re: RFR: 8167237: Jar tool can not correctly find/process the --release option if it occurs before the file list

looks OK Steve > On Oct 12, 2016, at 8:10 PM, Steve Drach wrote: > > Hi again, > > Is there anyone willing to review this? It’s a very simple change. > > Thanks > Steve > >> Begin forwarded message: >> >> From: Steve Drach >> Subject: RFR: 8167237: Jar tool can not correctly find/process t

Re: RFR JDK-8166258: Unexpected code conversion by HKSCS converters

Looks good to me. Naoto On 10/12/16 3:50 PM, Xueming Shen wrote: Hi Please help review the change for #8166258 issue: https://bugs.openjdk.java.net/browse/JDK-8166258 webrev: http://cr.openjdk.java.net/~sherman/8166258/webrev/ This is an overlook in the code that generates the c2b (encoding)

Fwd: RFR: 8167237: Jar tool can not correctly find/process the --release option if it occurs before the file list

Hi again, Is there anyone willing to review this? It’s a very simple change. Thanks Steve > Begin forwarded message: > > From: Steve Drach > Subject: RFR: 8167237: Jar tool can not correctly find/process the --release > option if it occurs before the file list > Date: October 6, 2016 at 1:50

RE: RFR(s): 8152617 add missing wildcards to Optional or()andflatMap()

Hi, I know of in/inout/out parameters from GLSL and, with most all conversions in GLSL being explicit, they are the easiest thing ever to reason about. In GLSL a 2D vector and a float array of 2 can both be accessed using array indexing, but nobody cares if one should be a subtype of another o

Re: RFR: JEP draft for Linux/s3990x port

Hi Goetz and Volker, Positive news is that JEP status is moving, changes are reviewed and some changes were already pushed. But because of our testing issues during past week I was not able to execute the testing. We hope jdk9/hs will be open soon but we want to sync jdk9/dev and merge hs-com

Re: Review request: JDK-8167630 jdeps --generate-module-info forgets to close the resource after checking any unnamed package

Not a reviewer, but looks good to me. :-) Kind regards, Jonathan On 12 Oct 2016 23:54, "Lance Andersen" wrote: > +1 > > On Oct 12, 2016, at 6:52 PM, Mandy Chung wrote: > > > > Simple patch close the ClassFileReader with try-with-resource. > > > > > > diff --git a/src/jdk.jdeps/share/classes/co

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

Yes, you're very welcome Stuart. :-) Kind regards, Jonathan On 12 Oct 2016 21:49, "Patrick Reinhart" wrote: You’re welcome :-) -Patrick Am 12.10.2016 um 22:41 schrieb Stuart Marks : Tests passed, spec change approved, changeset pushed: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/af71f6a

Re: Review request: JDK-8167630 jdeps --generate-module-info forgets to close the resource after checking any unnamed package

+1 > On Oct 12, 2016, at 6:52 PM, Mandy Chung wrote: > > Simple patch close the ClassFileReader with try-with-resource. > > > diff --git a/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java > b/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java > --- a/src/jdk.jdeps/sh

Review request: JDK-8167630 jdeps --generate-module-info forgets to close the resource after checking any unnamed package

Simple patch close the ClassFileReader with try-with-resource. diff --git a/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java b/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java --- a/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java +++ b/src/jdk.jdeps/sh

RFR JDK-8166258: Unexpected code conversion by HKSCS converters

Hi Please help review the change for #8166258 issue: https://bugs.openjdk.java.net/browse/JDK-8166258 webrev: http://cr.openjdk.java.net/~sherman/8166258/webrev/ This is an overlook in the code that generates the c2b (encoding) mapping table from the b2c data. \ufffd is the special code point t

Re: RFR (JAXP) 8058152: JDK accepts XSLT stylesheet having import element erroneously placed

Thanks Naoto, Lance! I appended _ERR. -Joe On 10/12/16, 2:50 PM, Naoto Sato wrote: +1. You might want to append "_ERR" to the field "IMPORT_PRECEDE_OTHERS" to align with other errors (no need for further review). Naoto On 10/12/16 1:37 PM, Joe Wang wrote: Hi, Please review a change to va

Re: RFR (JAXP) 8058152: JDK accepts XSLT stylesheet having import element erroneously placed

+1. You might want to append "_ERR" to the field "IMPORT_PRECEDE_OTHERS" to align with other errors (no need for further review). Naoto On 10/12/16 1:37 PM, Joe Wang wrote: Hi, Please review a change to validate that xsl:import element children /must precede/ all other element children of an

Re: RFR:JDK-8163330:HijrahDate aligned day of week incorrect

Hi, Looks ok. Typically, there is a space after the '//' comment characters, it makes it easier to read. Also, in this case, I don't think the comments help. "Monday" isn't important to the test and the 'Any Other day' is still 1, not something else. I would remove those comments. Otherwise

Re: RFR (JAXP) 8058152: JDK accepts XSLT stylesheet having import element erroneously placed

Looks OK Joe > On Oct 12, 2016, at 4:37 PM, Joe Wang wrote: > > Hi, > > Please review a change to validate that xsl:import element children /must > precede/ all other element children of an element, including > any element children as required by the specification [1]. > > [1] https://www.

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

You’re welcome :-) -Patrick > Am 12.10.2016 um 22:41 schrieb Stuart Marks : > > Tests passed, spec change approved, changeset pushed: > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/af71f6a36731 > > Jonathan, thanks for your contri

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

Tests passed, spec change approved, changeset pushed: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/af71f6a36731 Jonathan, thanks for your contribution. And Patrick, thanks again for hosting the webrev. s'marks On 10/12/16 6:53 AM, Jonathan Bluett-Duncan wrote: Hi all, Thank you very mu

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

Hi Naoto, Great, thanks for confirming this. s'marks On 10/11/16 4:13 PM, Naoto Sato wrote: +1 for removing the link to Collections#unmodifiableList in the spec. I don't see any particular reason to specify in the javadoc and don't believe it would break any existing apps. Naoto On 10/11/16

RFR (JAXP) 8058152: JDK accepts XSLT stylesheet having import element erroneously placed

Hi, Please review a change to validate that xsl:import element children /must precede/ all other element children of an element, including any element children as required by the specification [1]. [1] https://www.w3.org/TR/xslt#import JBS: https://bugs.openjdk.java.net/browse/JDK-8058152

Re: Review Request: JDK-8164689: Retrofit jar, jlink, jmod as a ToolProvider

On 12/10/2016 20:20, Mandy Chung wrote: Updated webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8164689/webrev.01 Mandy This looks good. -Alan

Re: RFR 8165793 : Provide an API to query if a ClassLoader is parallel capable

> On Oct 12, 2016, at 11:31 AM, Brent Christian > wrote: > > On 10/11/16 8:25 AM, Alan Bateman wrote: > > >> One thing that would be good is to beef up >> the test to cover more scenarios, esp. loader L1 extends loader L2 where >> you've got 4 combination of capable/non-capable to test. > > I

Re: Review Request: JDK-8164689: Retrofit jar, jlink, jmod as a ToolProvider

Updated webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8164689/webrev.01 Mandy > On Oct 12, 2016, at 9:10 AM, Mandy Chung wrote: > > >> On Oct 11, 2016, at 11:07 PM, Alan Bateman wrote: >> >> On 11/10/2016 19:03, Mandy Chung wrote: >> >>> This patch updates jar, jlink, jmod tool

Re: RFR 8165793 : Provide an API to query if a ClassLoader is parallel capable

On 10/11/16 8:25 AM, Alan Bateman wrote: > One thing that would be good is to beef up the test to cover more scenarios, esp. loader L1 extends loader L2 where you've got 4 combination of capable/non-capable to test. I updated the test case to provide better coverage: http://cr.openjdk.java.net

Re: RFR:JDK-8163330:HijrahDate aligned day of week incorrect

Hi Roger, Thanks for the suggestion, have made the suggested changes and shifted the tests to /java/time/test/java/time/chrono/TestUmmAlQuraChronology.java. Updated webrev: http://cr.openjdk.java.net/~rchamyal/anmeena/8163330/webrev.04/ Thanks, Anubhav > On Oct 12, 2016, at 8:45 PM, Roger Rig

Re: Review Request: JDK-8164689: Retrofit jar, jlink, jmod as a ToolProvider

> On Oct 11, 2016, at 11:07 PM, Alan Bateman wrote: > > On 11/10/2016 19:03, Mandy Chung wrote: > >> This patch updates jar, jlink, jmod tool to be a provider of the new tool >> SPI. Some tests are also updated to replace the use of internal APIs with >> ToolProvider::findFirst to look up a

Re: DateTimeFormatter.format() uses exceptions for flow control

Created an issue [1] and included the patch. Thanks, Roger [1] https://bugs.openjdk.java.net/browse/JDK-8167618 On 10/10/2016 2:53 AM, Clément MATHIEU wrote: On Mon, 2016-10-10 at 06:47 +1000, David Holmes wrote: Hi David, Please note that patches can only be accepted if they are sent thro

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

Hi Chris, On 10/10/2016 9:43 AM, Chris Hegarty wrote: Roger, I addressed all, or most, of your comments in the following webrev. 1) Refactored out the use of sun.nio.ch in the test library, so that a reduced number of tests need their @modules tag updated. ( @modules support with test

Re: RFR:JDK-8163330:HijrahDate aligned day of week incorrect

Hi Anubhav, In general, I agree with Stephen that the tests should be testing an algorithm against facts. Embedding an algorithm in the test increases the risk that the test will just replicate the implementation code and therefor not be much of a test. Though in this case, the specification

Re: RFR:JDK-8163330:HijrahDate aligned day of week incorrect

Hi Stephen, Have incorporated the changes you suggested. Updated webrev is available here http://cr.openjdk.java.net/~rchamyal/anmeena/8163330/webrev.03/ Please review and suggest if anymore changes are required. Thanks, Anubhav > On Oct 12, 2016, at 3:21 PM, Anubhav Meena wrote: > > Gentle

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

Hi all, Thank you very much for all reviewing my changeset over the last few days and for finding the bits I forgot to transfer from webrev01 to webrev02. I've been quiet as I'm still busy with university and will be for the foreseeable future. Stuart, many thanks again for sponsoring the change

Re: RFR(s): 8152617 add missing wildcards to Optional or() andflatMap()

Hi Timo, - Mail original - > De: "timo kinnunen" > À: "Stuart Marks" > Cc: "core-libs-dev" > Envoyé: Mercredi 12 Octobre 2016 09:33:54 > Objet: RE: RFR(s): 8152617 add missing wildcards to Optional or() > andflatMap() > Hi, > > > I’m going to challenge the consensus a little bit

Re: RFR:JDK-8163330:HijrahDate aligned day of week incorrect

The indentation in TCKHijrahChronology is not correct. In TCKHijrahChronology, it would be better to add the expected values to the provider ie two additional value for aligned week and aligned day: {1437, 9, 1, 1, 1} {1437, 9, 2, 1, 2} ... That way, the test relies on facts, not on a formula. S

Re: RFR(s): 8167437: Fix module dependencies for tests that use internal API (java/lang)

The fixed version is here: http://cr.openjdk.java.net/~skovalev/8167437/webrev.01/ I also modified CR description. 10.10.16 18:15, Sergei Kovalev wrote: You are right. I'll rollback the change for the file. 10.10.16 18:05, Alan Bateman wrote: sun.reflect.generics.parser is in java.base, I d

Re: RFR:JDK-8163330:HijrahDate aligned day of week incorrect

Gentle reminder. > On Oct 7, 2016, at 2:12 PM, Anubhav Meena wrote: > > Hi all, > > Please review. > Bug Id : https://bugs.openjdk.java.net/browse/JDK-8163330 > > > Issue: The HijrahDate class incorrectly calculates the aligned-day-of-week

Reminder

Hi All, This is a reminder for the pending review. > Bug Id : https://bugs.openjdk.java.net/browse/JDK-8163330 > > > Issue: The HijrahDate class incorrectly calculates the aligned-day-of-week > field. It based the calculation on the day-of-w

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

Hi Stuart, > It appears that the changes to remove the links to > Collections.unmodifiableList() was dropped from webrev.01 to webrev.02. I've > restored them, along with a couple other changes that were also dropped. I > also updated the ModuleFinder.java comment per a request from Alan Bateman.

RE: RFR(s): 8152617 add missing wildcards to Optional or() andflatMap()

Hi, I’m going to challenge the consensus a little bit. First, Rémi's example can be simplified to this one method which fails to compile with the same error message[0]: private static Optional simple1( Optional o, Function> f ) {return o.flatMap(f);} Second, although not in the webrev, Opt