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
+++
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:
>
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
> 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
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
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
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
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
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
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
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
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
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
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
> 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
> 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
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,
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
- 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
19 matches
Mail list logo