Hi Goetz,
On 15/12/2016 4:55 PM, Lindenmaier, Goetz wrote:
Hi,
I'm sorry for that. Our solaris builds were fine.
I saw the fix. Thanks Erik for fixing! I thought
windows was the last platform not to support
declarations in the code.
Me too! And I'm sure we have declarations all over the plac
Hi Joe
Thank you very much for your comments!
I have made a new webrev
http://cr.openjdk.java.net/~fyuan/8087303_8114834/webrev.01/ as your
suggestions, please check.
Thanks
Frank
> -Original Message-
> From: Joe Wang [mailto:huizhe.w...@oracle.com]
> Subject: Re: RFR (JAXP) JDK-80873
Hi Christoph
Thank you for the review!
Please check http://cr.openjdk.java.net/~fyuan/8087303_8114834/webrev.01/.
I have updated the code as your comments except output_html.properties, I am
not sure for the license of this file.
To Joe
Could you confirm Christoph's comment for output_html.pro
Hi Pango,
The backport is done and I will send backport and review request for
JDK8 later today (I'm pending testing results).
Best Regards,
Aleksej
On 15/12/16 05:41, Pango wrote:
Hi all,
May I ask has there been any progress on this issue?
Actually we are also struggling with this pro
On 13/12/2016 21:18, Peter Levart wrote:
I think this is OK.
Just a couple of nits in test:
1. You create a static Path bob = Paths.get("bob") field, but then you
don't use it in:
56 try (FileChannel fc = FileChannel.open(Paths.get("bob"),
CREATE, WRITE)) {
Adding to Peter's c
Hi Frank,
thanks, looks good :)
Best
Christoph
> -Original Message-
> From: Frank Yuan [mailto:frank.y...@oracle.com]
> Sent: Donnerstag, 15. Dezember 2016 11:52
> To: Langer, Christoph ; 'Joe Wang'
>
> Cc: core-libs-dev@openjdk.java.net
> Subject: RE: RFR (JAXP) JDK-8087303 LSSerialize
SubmissionPublisherTest, line 420: "s1.awaitSubscribe();"
I might be wrong, shouldn't this be "s2.awaitSubscribe();"?
Regards,
Stefan
2016-12-14 0:13 GMT+01:00 Martin Buchholz :
> We were supposed to be winding down jdk9, and there are a lot of changes
> here, but ... it would be a shame not t
Hi,
Can I, please, have an approval to backport JDK-8146086 to 8u-dev.
The source fix was slightly modified to remove stream/lamdba usages,
therefore the fix is a subject to review.
Webrev with 8u-dev changes:
http://cr.openjdk.java.net/~aefimov/8146086/8/00/
The fix was tested with JPRT on all
Hi,
please review(@Joe) & approve the downport of this regression fix. As it is a
JAXP issue and includes a testcase, the change needs to be split into a jaxp
part and a jdk part.
The jaxp part applies cleanly after unshuffling, the JDK part had to be
modified to fit into the jdk8 layout.
Bug
On 14/12/16 00:42, Joe Wang wrote:
Thanks Christoph!
I updated the webrev for the classes you mentioned below, in a few
cases, used NetBeans' source format feature -- not for all of the
classes though (esp. the crazily large
XMLDocumentFragmentScannerImpl.java, it gets better though, overtime).
Hi Hamlin,
Looks good, but I would suggest to rename the parameter
'remoteOk' into something more natural, like 'shouldFail'.
This should better help to understand the logic in createReg,
which otherwise appears a bit obscure.
No need to regenerate the webrev.
best regards,
-- daniel
On 15/1
Gah, thanks Daniel. I originally worked this fix on 8u and neglected to
remove synchronized when forward porting.
I've been having a few discussions on altering how we do locking in this
code in general and CoWArrayList is a nice idea. I'd like to leave this
change until I get to that work though.
Hi Hamlin,
If this is supposed to fix the call from line 68: then doesn't the test
for reg != null
at line 70 already have the same effect?
Roger
On 12/14/2016 10:19 PM, Hamlin Li wrote:
Would you please review the below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8171133
webrev:
Hi Brian,
I read it to say that changes can become permanent at any time (lazy or
aggressive) and
are guaranteed to be permanent only with a flush().
It does indicate for normal termination, the equivalent of flush occurs,
making pending changes permanent.
There is no statement that ensures a
Hi Roger,
On Dec 15, 2016, at 7:21 AM, Roger Riggs wrote:
> I read it to say that changes can become permanent at any time (lazy or
> aggressive) and
> are guaranteed to be permanent only with a flush().
> It does indicate for normal termination, the equivalent of flush occurs,
> making pendin
Joe, Christoph,
Thanks for your reviews!
Best Regards,
Aleksej
On 14/12/16 23:52, Langer, Christoph wrote:
+1
This is cool :)
-Original Message-
From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf
Of Joe Wang
Sent: Mittwoch, 14. Dezember 2016 20:26
To: Ale
Wouldn't it be better to use a function/bifunction instead of a supplier
because the supplier is a capturing?
Tom
Von meinem iPhone gesendet
> Am 14.12.2016 um 19:04 schrieb Aleks Efimov :
>
> Hi Joe,
>
> Thank you for the suggestions. What about modifying the 'debugPrintln' and
> 'dPrint' f
On 12/15/2016 07:36 AM, Stefan Zobel wrote:
SubmissionPublisherTest, line 420: "s1.awaitSubscribe();"
I might be wrong, shouldn't this be "s2.awaitSubscribe();"?
Thanks. Changed.
Using s1 on that line wasn't wrong, but wasn't intentional.
(The first use of s1 catches error-before-subscribe; t
> On 14 Dec 2016, at 19:54, Martin Buchholz wrote:
>
> I see that SpliteratorTraversingAndSplittingTest tests far more collection
> implementations than Collection8Test does, but we now have tests that caught
> spliterator bugs not caught by SpliteratorTraversingAndSplittingTest. Our
> tests
Hi Christoph,
The patches look good to me.
Thanks,
Joe
On 12/15/16, 6:11 AM, Langer, Christoph wrote:
Hi,
please review(@Joe) & approve the downport of this regression fix. As
it is a JAXP issue and includes a testcase, the change needs to be
split into a jaxp part and a jdk part.
The ja
> 2016-12-15 18:35 GMT+01:00 Doug Lea :
>
> Thanks. Changed.
> Using s1 on that line wasn't wrong, but wasn't intentional.
> (The first use of s1 catches error-before-subscribe; the
> "s2" cases just check against side effects, but they should
> use s2 consistently for uniformity.)
>
> -Doug
>
Ah,
On 12/15/16, 6:38 AM, Daniel Fuchs wrote:
On 14/12/16 00:42, Joe Wang wrote:
Thanks Christoph!
I updated the webrev for the classes you mentioned below, in a few
cases, used NetBeans' source format feature -- not for all of the
classes though (esp. the crazily large
XMLDocumentFragmentScanner
Hello,
Next up in porting fdlibm to Java after cbrt (JDK-8136799), pow
(JDK-8134795) and hypot (JDK-7130085) earlier in JDK 9 is exp:
JDK-8139688 Port fdlibm exp to Java
http://cr.openjdk.java.net/~darcy/8139688.5/
Same methodology followed as when porting the earlier functions.
Than
Hi Tom,
The main purpose of this fix is to postpone debug message string parts
calculation/concatenation till when the actual output is needed, i.e. we
don't want to call which(clazz) until the debug output is needed
(debug=true) in XPathFactoryFinder ). I'm not sure that
function/bifunction
Hi Frank,
Thanks for the update. It looks good.
The license header for output_html.properties can be updated as the follows:
###
# Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
##
Hi Roger, Daniel,
Thank you for reviewing.
On 2016/12/15 22:45, Roger Riggs wrote:
Hi Hamlin,
If this is supposed to fix the call from line 68: then doesn't the
test for reg != null
at line 70 already have the same effect?
Please consider the situation: LocateRegistry.createRegistry(port) in
Hi Rob,
Code changes looks good to me.
Thanks,
Vyom
On Thursday 15 December 2016 08:27 PM, Rob McKenna wrote:
Gah, thanks Daniel. I originally worked this fix on 8u and neglected to
remove synchronized when forward porting.
I've been having a few discussions on altering how we do locking in
Please take a review at
http://cr.openjdk.java.net/~weijun/8171340/webrev.00/
All "openConnection()" modified to "openConnection(Proxy.NO_PROXY)".
Everything else is whitespace change.
Thanks
Max
Would you please review the below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8171298
diff -r 63e82d0eb4f6 test/ProblemList.txt
--- a/test/ProblemList.txtWed Dec 14 19:23:08 2016 -0800
+++ b/test/ProblemList.txtThu Dec 15 21:01:34 2016 -0800
@@ -205,6 +205,8 @@
java/rmi/trans
Hi Aleksej,
Thank you. Really appreciate your prompt response.
Hope this fix could be included in the next release (8u122?).
Best Regards,
Pango Chan
2016-12-15 20:04 GMT+09:00 Aleks Efimov :
> Hi Pango,
> The backport is done and I will send backport and review request for JDK8
> later today
Hi Aleksej and Pango,
Thank you for backport and pushing.
Regards,
Yuji
2016-12-16 14:32 GMT+09:00 Pango :
> Hi Aleksej,
>
> Thank you. Really appreciate your prompt response.
> Hope this fix could be included in the next release (8u122?).
>
> Best Regards,
> Pango Chan
>
> 2016-12-15 20:04 GM
31 matches
Mail list logo
