RFR of JDK-8173326: Problem list java/rmi/registry/readTest/CodebaseTest.java on Windows

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8173326 Thank you -Hamlin diff -r a468135ebe8e test/ProblemList.txt --- a/test/ProblemList.txtTue Jan 24 18:41:36 2017 -0800 +++

RE: RFR (JAXP) 8169827: javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed

Thank you, Christoph Frank > -Original Message- > From: Langer, Christoph [mailto:christoph.lan...@sap.com] > Sent: Tuesday, January 24, 2017 6:30 PM > To: Frank Yuan > Cc: 'Daniel Fuchs'; core-libs-dev@openjdk.java.net > Subject: RE: RFR (JAXP) 8169827: >

Re: Cleanup String.replace() occurences with single characters

Hi, String::replace(CharSequence, CharSequence) does not use a regex, but String::replace(char, char) can still be slightly more efficient, As this is relatively new code that wasn't around when 8044461 was done I'm sure we can get it cleaned up. Thanks! /Claes On 2017-01-24 20:33, Christoph

Re: RFR: 8170832: Add a new launcher environment variable JAVA_OPTIONS

> On Jan 24, 2017, at 10:20 AM, Henry Jen wrote: > > Hi, > > Please review the webrev[1] that add support for JAVA_OPTIONS environment > variable. The bug[2] describes how JAVA_OPTIONS works. > > [1] http://cr.openjdk.java.net/~henryjen/jdk9/8170832/4/webrev/ This

Cleanup String.replace() occurences with single characters

Hey, similar to https://bugs.openjdk.java.net/browse/JDK-8044461 I noticed two (newly introduced) places where we could avoid the regex overhead when replacing single chars. I'd be happy if this is sponsored. Cheers, Christoph === PATCH # User Christoph

RFR: 8170832: Add a new launcher environment variable JAVA_OPTIONS

Hi, Please review the webrev[1] that add support for JAVA_OPTIONS environment variable. The bug[2] describes how JAVA_OPTIONS works. [1] http://cr.openjdk.java.net/~henryjen/jdk9/8170832/4/webrev/ [2] https://bugs.openjdk.java.net/browse/JDK-8170832 Cheers, Henry

Re: RFR: 8029019: (ann) Optimize annotation handling in core reflection

Peter, > On 2017-01-17 15:10, Peter Levart wrote: >> Hi, >> >> This is a preview of a patch that addresses the following issue: >> >>https://bugs.openjdk.java.net/browse/JDK-8029019 This very good work. I have not done a complete review, but what jumps out at me is that you have removed

Re: RFR: 8029019: (ann) Optimize annotation handling in core reflection

Hi Peter, thanks for the thorough examination of this issue. After going through the patch I do like what I see, but I have a few comments: AnnotationInvocationHandler: in invoke, cleaning up and replacing the explicit AssertionError should be fine, but perhaps convert it to an assert that the

Re: (JAXP) RFR: 8173111: Excessive recursion in EventFilterSupport when filtering over large number of XML events can cause StackOverflow

Hi, Thanks for all the feedback. I have updated the webrev http://cr.openjdk.java.net/~dfuchs/webrev_8173111/webrev.01 The test now uses assertEquals as suggested by Lance and Aleksej (thanks for the suggestion). I also fixed the missing white space in the code that Christoph spotted at line

RE: RFR (JAXP) 8169827: javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed

Hi, I submitted my fix under Bug https://bugs.openjdk.java.net/browse/JDK-8173261: http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/620d0c38581f I also added a comment to https://bugs.openjdk.java.net/browse/JDK-8169827 Best regards Christoph > -Original Message- > From: Frank Yuan

Re: Calling a lambda expression from a new thread before the main method is run causes the thread to lock up

Thank you Remi and David for your detailed explanations, this was very helpful, and I understand the issues now. Please go ahead and close the Jira bug I created for this (JDK-8173252), I see this is WAI. On Tue, Jan 24, 2017 at 12:39 AM, wrote: > Here is your code slightly

Re: Calling a lambda expression from a new thread before the main method is run causes the thread to lock up

I have to second Remi's view here - hidden concurrency is an accident waiting to happen, far too many things can go wrong if the users of your API don't know that new threads can be involved. It's not wrong, per-se, to start threads from a static initializer - just wrong to do something that

Re: Calling a lambda expression from a new thread before the main method is run causes the thread to lock up

On 24/01/2017 5:21 PM, Luke Hutchison wrote: On Mon, Jan 23, 2017 at 10:48 PM, David Holmes > wrote: On 24/01/2017 2:41 PM, Luke Hutchison wrote: If you run the code below, the active JVM thread (in the

Re: RFR of JDK-8171142: jdk_rmi registry test fail to clean up on failure

Hi Roger, David, Thank you for reviewing, modified as you suggested, and the code is pushed. -Hamlin On 2017/1/23 23:21, Roger Riggs wrote: Hi Hamlin, test/javax/rmi/PortableRemoteObject/ConcurrentHashMapTest.java: line 130: trivial, but please add a space in "!=null"... Note: on

RE: RFR (JAXP) 8169827: javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed

> From: Langer, Christoph [mailto:christoph.lan...@sap.com] > To: Frank Yuan > Cc: 'Daniel Fuchs'; core-libs-dev@openjdk.java.net > Subject: RE: RFR (JAXP) 8169827: > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed > > Hi Frank, > > thanks for your comments. > > I

Re: Calling a lambda expression from a new thread before the main method is run causes the thread to lock up

> De: "Luke Hutchison" > À: "Remi Forax" > Cc: "David Holmes" , core-libs-dev@openjdk.java.net > Envoyé: Mardi 24 Janvier 2017 09:13:17 > Objet: Re: Calling a lambda expression from a new thread before the main > method > is run

RE: RFR (JAXP) 8169827: javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed

Hi Frank, thanks for your comments. I already thought it might be better to create a new bug for my repair work - as 8169827 actually is about the intermittent failure which will perhaps not be solved with my changes. So I'll create a new item and submit my changes for that one. Furthermore,

Re: Calling a lambda expression from a new thread before the main method is run causes the thread to lock up

On Tue, Jan 24, 2017 at 12:02 AM, Remi Forax wrote: > a worker thread of the executor will try to execute the code of the static > method but because the static initializer is not finished, the worker > thread has to wait But what is the worker thread waiting for in the case

Re: Calling a lambda expression from a new thread before the main method is run causes the thread to lock up

- Mail original - > De: "Luke Hutchison" > À: "David Holmes" > Cc: core-libs-dev@openjdk.java.net > Envoyé: Mardi 24 Janvier 2017 08:21:39 > Objet: Re: Calling a lambda expression from a new thread before the main > method is run