Hi All,
Please review fix for
https://bugs.openjdk.java.net/browse/JDK-8133719
http://cr.openjdk.java.net/~srastogi/8133719/webrev.01/
Thanks,
Shilpi
Hi Jon
Thank you for your advice!
Please check the update http://cr.openjdk.java.net/~fyuan/8170192/webrev.01/ ,
which contains jcommander.jar and removes the extra
blank lines following Christoph's suggestion.
Frank
From: Jonathan Gibbons [mailto:jonathan.gibb...@oracle.com]
Sent
On 11/23/2016 02:39 PM, Paul Sandoz wrote:
Hi,
Please review:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8170155-string-buffer-builder-late-binding/webrev/
This patch:
1) updates the StringBuilder/StringBuffer.chars()/codePoints() so they are late
binding.
2) refactors the spliterator
Hi,
Please review:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8170155-string-buffer-builder-late-binding/webrev/
This patch:
1) updates the StringBuilder/StringBuffer.chars()/codePoints() so they are late
binding.
2) refactors the spliterator late binding and fail fast tests, separating
Hi Stephen,
I changed the webrev accordingly:
http://cr.openjdk.java.net/~reinhapa/reviews/8167648/webrev.00
-Patrick
> Am 23.11.2016 um 14:45 schrieb Stephen Colebourne :
>
> Returning the writer was my intention. I also intended it to return a
> new instance, to avoid changing the variable f
On 11/22/2016 11:50 AM, Langer, Christoph wrote:
I agree that it would be nicer if jtreg would leave the jtreg lib path as
java property to be able to elevate all of its contents. But the current
proposal with a set of TEST_JARS of jtreg, javatest and testng is probably
sufficient for jaxp
Frank,
More recent builds of testng.jar, such as the builds available on
Maven, have separated out the jcommander component so that two jar
files are required: testng.jar and jcommander.jar.
You should consider taking jcommander.jar into account. This will be
more important/noticeable to f
Stuart and I refined the text to mention a concurrent modification policy (e.g.
fail-fast or weakly consistent) of any overriding class.
Paul.
diff -r c7b932897909 src/java.base/share/classes/java/lang/Iterable.java
--- a/src/java.base/share/classes/java/lang/Iterable.java Wed Nov 23
10:
> On 23 Nov 2016, at 07:50, Doug Lea wrote:
>
> On 11/23/2016 10:05 AM, Martin Buchholz wrote:
>> Right now, PBQ's spliterator is in violation of
>>
>> """A Spliterator that does not report IMMUTABLE or CONCURRENT is
>> expected to have a documented policy concerning: when the spliterator
>> bi
+1. Thanks Frank!
-Joe
On 11/23/16, 6:00 AM, Daniel Fuchs wrote:
Hi Frank,
Thanks for taking this on.
Looks good to me.
-- daniel
On 23/11/16 04:41, Frank Yuan wrote:
Hi All
Would you like to review
http://cr.openjdk.java.net/~fyuan/8170192/webrev.00/?
Bug: https://bugs.openjdk.java.net
+1
Brian
On Nov 23, 2016, at 9:25 AM, Paul Sandoz wrote:
> +1
>
> Paul.
>
>> On 23 Nov 2016, at 08:10, joe darcy wrote:
>>
>> Hello,
>>
>> Please review the changes to address
>>
>> JDK-8169479: java.lang.reflect.Constructor class has wrong api
>> documentation
>> http://cr.openjdk.j
+1
Paul.
> On 23 Nov 2016, at 08:10, joe darcy wrote:
>
> Hello,
>
> Please review the changes to address
>
>JDK-8169479: java.lang.reflect.Constructor class has wrong api
> documentation
>http://cr.openjdk.java.net/~darcy/8169479.0/
>
> Patch inline below. There are a few issues re
Hi Roger,
This seems sufficiently clear.
Brian
On Nov 23, 2016, at 7:43 AM, Roger Riggs wrote:
> Please review a clarification of the serialization filtering configuration of
> pattern based filters
> requested and reviewed by the JCK team.
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/
Hello,
Please review the changes to address
JDK-8169479: java.lang.reflect.Constructor class has wrong api
documentation
http://cr.openjdk.java.net/~darcy/8169479.0/
Patch inline below. There are a few issues reported in the bug:
* The Constructor.toString method fails to state it pr
Hi Erik,
On 23-11-2016 12:29, Erik Joelsson wrote:
> Build changes look ok.
>
> In CoreLibraries.gmk, I think it would have been ok to keep the conditional
> checking (OPENJDK_TARGET_CPU_ARCH, ppc), but this certainly works too.
Thanks a lot for reviewing the change.
Regards,
Gustavo
On 11/23/2016 10:05 AM, Martin Buchholz wrote:
Right now, PBQ's spliterator is in violation of
"""A Spliterator that does not report IMMUTABLE or CONCURRENT is
expected to have a documented policy concerning: when the spliterator
binds to the element source;"""
so I think we only get a choice b
Please review a clarification of the serialization filtering
configuration of pattern based filters
requested and reviewed by the JCK team.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-filter-config-8169645/
Thanks, Roger
Hi Martin,
On 23-11-2016 12:38, Doerr, Martin wrote:
> Hi Gustavo,
>
> thanks for providing the webrevs.
>
> I have ran the StrictMath jck tests which fail when building with -O3 and
> without -ffp-contract=off:
> FailedTests:
> api/java_lang/StrictMath/desc.html#acos
> javasoft.sqe.tests.api.
Hi Volker,
On 23-11-2016 12:05, Volker Simonis wrote:
> thanks a lot for tracking this down!
Happy to contribute :)
> The change looks good and I a can sponsor it once you get another
> review from the build group and the FC Extension Request was approved.
Thanks a lot for sponsoring it!
> I
Right now, PBQ's spliterator is in violation of
"""A Spliterator that does not report IMMUTABLE or CONCURRENT is expected
to have a documented policy concerning: when the spliterator binds to the
element source;"""
so I think we only get a choice between IMMUTABLE and CONCURRENT. I
propose:
---
Build changes look ok.
In CoreLibraries.gmk, I think it would have been ok to keep the
conditional checking (OPENJDK_TARGET_CPU_ARCH, ppc), but this certainly
works too.
/Erik
On 2016-11-22 01:43, Gustavo Romero wrote:
Hi,
Could the following change be reviewed, please?
webrev 1/2: http:
On 11/22/2016 08:33 PM, Martin Buchholz wrote:
PriorityBlockingQueue has a late-binding-style, snapshot spliterator
that does not report IMMUTABLE. It *is* immutable ... after the first
access! Should we add IMMUTABLE?
Probably not.
This might overly constrain future improvements; for example
Hi Gustavo,
thanks a lot for tracking this down!
The change looks good and I a can sponsor it once you get another
review from the build group and the FC Extension Request was approved.
In general I'd advise to sign the OCTLA [1] to get access to the Java
SE TCK [2] as this contains quite a lot
Hi Frank,
Thanks for taking this on.
Looks good to me.
-- daniel
On 23/11/16 04:41, Frank Yuan wrote:
Hi All
Would you like to review
http://cr.openjdk.java.net/~fyuan/8170192/webrev.00/?
Bug: https://bugs.openjdk.java.net/browse/JDK-8170192
This patch is fully same as Daniel provided e
Hi Frank,
I ran only the tests under jaxp/tests/javax - and one test was failing
(DurationTest) with a similar error (something about a mismatch between
Integer & Long in data provider).
This looked to be completely unrelated to the permission changes, so I
thought it would be better to investig
Looks good!
On 23/11/16 05:49, John Jiang wrote:
Hi Daniel,
I'll push the below patch:
diff -r 5cd2aa3f3e9b test/ProblemList.txt
--- a/test/ProblemList.txt Tue Nov 22 10:45:48 2016 -0800
+++ b/test/ProblemList.txt Tue Nov 22 21:34:47 2016 -0800
@@ -305,6 +305,6 @@
# jdk_other
-com/s
Returning the writer was my intention. I also intended it to return a
new instance, to avoid changing the variable from final to non-final.
Stephen
On 23 November 2016 at 13:35, Jonathan Bluett-Duncan
wrote:
> Hi Patrick,
>
> Have you considered making `withAutoFlush()` return the `PrintWriter`
On 2016-11-23 14:35, Jonathan Bluett-Duncan wrote:
Hi Patrick,
Have you considered making `withAutoFlush()` return the `PrintWriter`
itself, allowing fluent code snippets like the following?
```
PrintWriter writer = new PrintWriter(new File("path/to/file.txt"),
StandardCharsets.UTF_8).withAutoF
Hi Patrick,
Have you considered making `withAutoFlush()` return the `PrintWriter`
itself, allowing fluent code snippets like the following?
```
PrintWriter writer = new PrintWriter(new File("path/to/file.txt"),
StandardCharsets.UTF_8).withAutoFlush();
```
Kind regards,
Jonathan
On 23 November 2
Added those new public constructors:
PrintWriter(OutputStream, Charset)
PrintWriter(File, Charset)
withAutoFlush()
Also added a new private constructor:
PrintWriter(OutputStream, Charset, boolean)
and rewired the OutputStream constructor calls to this private
constructor.
Here's the webrev
+1
Stephen
On 7 November 2016 at 21:23, Roger Riggs wrote:
> Looks good,
>
> Thanks, Roger
>
>
>
> On 11/7/2016 7:27 AM, Bhanu Gopularam wrote:
>>
>> Thanks Nadeesh. Here is the updated webrev:
>>
>> http://cr.openjdk.java.net/~bgopularam/8160036/webrev.01
>>
>> Thanks,
>> Bhanu
>>
>> -Origin
Hi Stephen,
On 2016-11-23 12:04, Stephen Colebourne wrote:
Perhaps a method withAutoFlush(boolean) could reduce the number of
To make that work, we would have to make the boolean field "autoFlush"
writeable. Also the auto flush behaviour could be changed at any time. I
would then prefer to
Hey! Is this forgotten?
On 03/11/2016 14:35, Brunoais wrote:
Any information you can give on this?
On 29/10/2016 19:10, Brunoais wrote:
Here's my try on going async.
On my tests on my local windows 10 machine (I don't have access to
the linux one without a VM ATM) , now with 1GB file, I no
These are the current constructors:
PrintWriter(Writer)
PrintWriter(Writer, boolean)
PrintWriter(OutputStream)
PrintWriter(OutputStream, boolean)
PrintWriter(String)
PrintWriter(String, String)
PrintWriter(File)
PrintWriter(File, String)
These are the annoying missing ones (not all of the possibl
Are there any obligations to add those constructors?
-Patrick
On 2016-11-18 10:19, Patrick Reinhart wrote:
I was looking at the existing JDK 9 issues for some simple ones I
could solve and found this one. I wanted to know if it makes sense to
add additional constructors here?
Now you need to
Would you please review the fix for below bug?
bug: https://bugs.openjdk.java.net/browse/JDK-8019538
webrev: http://cr.openjdk.java.net/~mli/8019538/webrev.00/
There are 4 issues in the bug,
2 in RmidViaInheritedChannel.java: "port in use" in registry, "port in
use" in rmid start.
2 InheritedC
Hi,
Mandy and I have agreed in a personal discussion that Mandy will take
this issue and target it for a future issue.
So I retract this RFR. Thank you, everybody, for the discussions and help!
Best regards,
Zoltan
Hi Jon
I run the whole jdk regression tests with jtreg-4.2-b03 [1], and then found
lots of tests in different test groups failed with the error message like
following:
test test.java.time.format.TestNumberPrinter.test_pad_ALWAYS(): failure
org.testng.internal.reflect.MethodMatcherException:
Dat
Hi Joe,
tests went well and I pushed:
http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/31ac7aab52da
Thanks
Christoph
From: Joe Wang [mailto:huizhe.w...@oracle.com]
Sent: Dienstag, 22. November 2016 23:02
To: Langer, Christoph
Cc: core-libs-dev@openjdk.java.net
Subject: Re: RFR: 8169772: [JAXP] XAL
39 matches
Mail list logo
