Re: RFR (JAXP) 8069098 : StAX produces the wrong event stream

+1 > On Oct 26, 2016, at 2:29 PM, Joe Wang wrote: > > Hi, > > Please review an update to the Javadoc of the StAX API from the JSR 173 > specification [1], and fix to the implementation to comply with the > specification that the reader's initial event shall be

Re: RFR 9: 8168517 : java/lang/ProcessBuilder/Basic.java failed

Hi Roger, Okay we are back to where we were a couple of emails ago. :) Removing everything after the p.destroy() seems fine to me. Thanks, David On 29/10/2016 7:16 AM, Roger Riggs wrote: Hi, On 10/28/2016 4:59 PM, David Holmes wrote: But this is the second waitFor call after the process

Re: RFR 9: 8168517 : java/lang/ProcessBuilder/Basic.java failed

Hi, On 10/28/2016 4:59 PM, David Holmes wrote: But this is the second waitFor call after the process is destroyed. Sorry I don't really see the point. The tests were added to determine if waitFor(timeout) was handling the timeout parameter correctly. The 2nd test here was to check the

Re: RFR 9: 8168517 : java/lang/ProcessBuilder/Basic.java failed

On 29/10/2016 5:39 AM, Roger Riggs wrote: Hi, On 10/28/2016 3:14 PM, David Holmes wrote: On 29/10/2016 3:48 AM, Roger Riggs wrote: Hi David, On 10/27/2016 9:00 PM, David Holmes wrote: But this is the second waitFor call after the process is destroyed. Sorry I don't really see the point.

Re: JEP 293: Guidelines for JDK Command-Line Tool Options - @-files

On 28/10/2016 20:15, Robert Scholte wrote: : Now I'm getting new messages, often one of these: Error: module-info.class not found for hibernate.jpa module or Error: module-info.class not found for spring.context module or Error: module-info.class not found for spring.orm module So let's

Re: RFR 9: 8168517 : java/lang/ProcessBuilder/Basic.java failed

Hi, On 10/28/2016 3:14 PM, David Holmes wrote: On 29/10/2016 3:48 AM, Roger Riggs wrote: Hi David, On 10/27/2016 9:00 PM, David Holmes wrote: But this is the second waitFor call after the process is destroyed. Sorry I don't really see the point. The tests were added to determine if

Re: RFR: 8152515: (logging) LogManager.resetLogger should ignore LinkageError

Hi Daniel, I've read the bug report on this and this issue "smells" to me. LinkageError should not be a special case IMHO. The existing code was trying to go the "ignore everything but 'serious errors' " route - but without really considering what constitutes a "serious error". I think the

Re: JEP 293: Guidelines for JDK Command-Line Tool Options - @-files

On Fri, 28 Oct 2016 07:05:06 +0200, Henry Jen wrote: OS-specific encoding, but has to be ASCII friendly, modern system with UTF-8 as system encoding should work just fine. Hmm, this will probably work for 99%, but I'm sure that we will have Maven users which use

Re: RFR 9: 8168517 : java/lang/ProcessBuilder/Basic.java failed

On 29/10/2016 3:48 AM, Roger Riggs wrote: Hi David, On 10/27/2016 9:00 PM, David Holmes wrote: But this is the second waitFor call after the process is destroyed. Sorry I don't really see the point. The tests were added to determine if waitFor(timeout) was handling the timeout parameter

Re: RFR 9: 8168517 : java/lang/ProcessBuilder/Basic.java failed

Hi David, On 10/27/2016 9:00 PM, David Holmes wrote: But this is the second waitFor call after the process is destroyed. Sorry I don't really see the point. The tests were added to determine if waitFor(timeout) was handling the timeout parameter correctly. The 2nd test here was to check the

Re: RFR: 8152515: (logging) LogManager.resetLogger should ignore LinkageError

Hi Daniel, The test is fine. Without the fix, jtreg is handling the uncaught LinkageError exception and has called System.exit which will deadlock since it is already in System.exit. Roger On 10/28/2016 10:44 AM, Daniel Fuchs wrote: On 28/10/16 14:50, Roger Riggs wrote: Hi Daniel, Looks

Re: RFR: JDK-8167618: DateTimeFormatter.format() uses exceptions for flow control.

+1, Roger On 10/28/2016 11:58 AM, nadeesh tv wrote: Hi Anubhav, - * @throws DateTimeException if the field is not available and the section is not optional I think you should not remove the DTException since still there is a chance of throwing DTE Regards, Nadeesh On 10/28/2016

Re: 8152515: (logging) LogManager.resetLogger should ignore LinkageError

Oh, I see! Thanks for pointing out my misconception for me. :) In that case, this fix looks fine to me as a non-reviewer. Kind regards, Jonathan On 28 October 2016 at 17:15, Roger Riggs wrote: > Hi Jonathan, > > There is no issue in this case. > LinkageError does not

Re: 8152515: (logging) LogManager.resetLogger should ignore LinkageError

Hi Jonathan, There is no issue in this case. LinkageError does not extend Exception so they are disjoint at the catch clauses. And the compiler produces an error if a catch clause hides another exception to keep the mistake from being hidden. $.02, Roger On 10/28/2016 12:00 PM, Jonathan

Re: 8152515: (logging) LogManager.resetLogger should ignore LinkageError

Hi Jonathan, On 28/10/16 17:00, Jonathan Bluett-Duncan wrote: I've an awful suspicion that the `catch (LinkageError e)` block is unreachable, as the `catch (Exception e)` block would run first, being located above the other block in the source code. Is my suspicion correct? Not really. As

Re: 8152515: (logging) LogManager.resetLogger should ignore LinkageError

I've an awful suspicion that the `catch (LinkageError e)` block is unreachable, as the `catch (Exception e)` block would run first, being located above the other block in the source code. Is my suspicion correct? Kind regards, Jonathan On 28 October 2016 at 16:36, Jason Mehrens

Re: RFR: JDK-8167618: DateTimeFormatter.format() uses exceptions for flow control.

Hi Anubhav, - * @throws DateTimeException if the field is not available and the section is not optional I think you should not remove the DTException since still there is a chance of throwing DTE Regards, Nadeesh On 10/28/2016 12:18 AM, Anubhav Meena wrote: Hi all, Please review.

Re: Review Request: JDK-8167057 jdeps to list the modules and internal APIs to help find @modules for tests

> On Oct 28, 2016, at 3:03 AM, Daniel Fuchs wrote: > > Hi Mandy, > > Looks good to me in general, but I feel like the new > option --list-reduced-deps should be better documented: > I agree and this details and example can be covered in the man page. >

Re: 8152515: (logging) LogManager.resetLogger should ignore LinkageError

Daniel, Looks good to me. Thanks for fixing this! Jason From: Daniel Fuchs Sent: Friday, October 28, 2016 6:51 AM To: core-libs-dev Cc: Jason Mehrens Subject: RFR: 8152515: (logging) LogManager.resetLogger should ignore

Re: RFR: 8152515: (logging) LogManager.resetLogger should ignore LinkageError

On 28/10/16 14:50, Roger Riggs wrote: Hi Daniel, Looks fine. Roger Thanks Roger. I have turned the reproducer attached to JDK-8152515 into a jtreg test. The test creates some logger and registers a handler that throws LinkageError when closed. The test passes as expected with the fix.

Re: JDK 9 RFR of JDK-8168524: Remove two jdk_nio tests from ProblemList: BashStreams and DeleteInterference.java

+1 (for BashStreams test) Since this is restoring tests to gather more data. Roger On 10/27/2016 11:15 PM, Amy Lu wrote: On 10/24/16 10:50 PM, Brian Burkhalter wrote: +1 for the DeleteInterference portion. Thank you Brian. Still need a reviewer for BashStreams test. Thanks, Amy Brian

Re: RFR: 8152515: (logging) LogManager.resetLogger should ignore LinkageError

Hi Daniel, Looks fine. Roger On 10/28/2016 7:51 AM, Daniel Fuchs wrote: Hi, Please find below a trivial patch for: 8152515: (logging) LogManager.resetLogger should ignore LinkageError https://bugs.openjdk.java.net/browse/JDK-8152515 Patch:

RFR: 8152515: (logging) LogManager.resetLogger should ignore LinkageError

Hi, Please find below a trivial patch for: 8152515: (logging) LogManager.resetLogger should ignore LinkageError https://bugs.openjdk.java.net/browse/JDK-8152515 Patch: http://cr.openjdk.java.net/~dfuchs/webrev_8152515/webrev.00/ The issue might occur at shutdown, when a handler that makes

Re: Review Request: JDK-8167057 jdeps to list the modules and internal APIs to help find @modules for tests

Hi Mandy, Looks good to me in general, but I feel like the new option --list-reduced-deps should be better documented: jdeps.properties: 152 main.opt.list-deps=\ 153 \ --list-deps\n\ 154 \ --list-reduced-deps Lists the dependences and use of JDK internal\n\ 155 \

Re: Request/discussion: BufferedReader reading using async API while providing sync API

I'll try going back to a previous version I worked on which used the java7's AsynchronousFileChannel and work from there. My small research shows it can also work with AsynchronousFileChannel mostly without changes. For now, 1 question: Is Thread.sleep() a possible way of dealing the block

RFR: JDK-8167618: DateTimeFormatter.format() uses exceptions for flow control.

Hi all, Please review. Please ignore last mail as links not working properly there. Bug Id : https://bugs.openjdk.java.net/browse/JDK-8167618 Issue: DateTimeFormatter.format() uses exceptions for flow control. Webrev:

RFR: JDK-8167618: DateTimeFormatter.format() uses exceptions for flow control.

Hi all, Please review. Bug Id : https://bugs.openjdk.java.net/browse/JDK-8167618 Issue: DateTimeFormatter.format() uses exceptions for flow control. Webrev: http://cr.openjdk.java.net/~rchamyal/anmeena/8167618/webrev.00/

Re: Request/discussion: BufferedReader reading using async API while providing sync API

On 27/10/2016 22:45, Vitaly Davidovich wrote: On Thursday, October 27, 2016, Brunoais > wrote: You are right. Even in windows it does not set the flags for async reads. It seems like it is windows itself that does the decision