On 19/01/2017 23:35, Xueming Shen wrote:
Thanks Claes!
webrev has been updated accordingly
http://cr.openjdk.java.net/~sherman/8173072/webrev
The changes looks okay although I'd to understand more as to why tools
might be generating the extra fields in this way.
Also is the "zipinfo-time"
Seems OK. It would be nice to somehow get more confidence we don't have
remaining circularities. I agree a specialized concurrent hash table to
replace ConcurrentHashMap might help.
I was surprised to see below a change in parentheses that seems to change
the behavior.
final long nextSeed(
Hi,
Unfortunately the switch from Unsafe to VarHandle in LockSupport and
ThreadLocalRandom caused some circularity issues (similar to those for
AtomicInteger) that have shown up in continuous testing (but not when i tested
explicitly using the infrastructure).
The main problem is MethodType le
On 2017-01-20 00:35, Xueming Shen wrote:
Thanks Claes!
webrev has been updated accordingly
http://cr.openjdk.java.net/~sherman/8173072/webrev
+1
/Claes
On 01/19/2017 03:04 PM, Claes Redestad wrote:
Looks good to me.
You could simplify a bit and write: int end = locPos + locSZ - 4;
and
Thanks Claes!
webrev has been updated accordingly
http://cr.openjdk.java.net/~sherman/8173072/webrev
On 01/19/2017 03:04 PM, Claes Redestad wrote:
Looks good to me.
You could simplify a bit and write: int end = locPos + locSZ - 4;
and use direct comparisons instead of adding 4 in each test.
Looks good to me.
You could simplify a bit and write: int end = locPos + locSZ - 4;
and use direct comparisons instead of adding 4 in each test.
Thanks!
/Claes
On 2017-01-19 22:39, Xueming Shen wrote:
Hi
Please review the change for
issue: https://bugs.openjdk.java.net/browse/JDK-8173072
we
Hi
Please review the change for
issue: https://bugs.openjdk.java.net/browse/JDK-8173072
webrev: http://cr.openjdk.java.net/~sherman/8173072/webrev
As described in the issue, the root cause is that the offending zip/jar file
has a "extended timestamp extra field" that does not strictly follow t
Hi Amy,
As an exercise it might useful to modify ArrayList and test with the existing
benchmark. One could follow up with ArrayList changes as a separate issue. If
your investigations show no regressions then we have good confidence the
current patch is ok.
Another useful learning exercise is
> On 19 Jan 2017, at 05:37, Amy Lu wrote:
>
> This is test-only change, can still go into JDK 9?
>
Yes.
It’s verbose but i would prefer if you can explicitly declare each test rather
than having one test deferring to SpliteratorTestHelper.testSpliterator. So in
effect the test methods are p
> On Jan 19, 2017, at 10:50 AM, Daniel Fuchs wrote:
>
> Hi Mandy,
>
> Thanks for the review!
>
> On 19/01/17 17:12, Mandy Chung wrote:
>>
>>
>> Is it intentional to change the level FINEST to DEBUG as opposed to TRACE in
>> a couple places? For example,
>
> The regular mapping would be:
>
Hi Roger,
On 19/01/17 18:22, Roger Riggs wrote:
Hi Daniel,
Very straight-forward.
I can see many places where the supplier form of logging could be used
instead
of the if (loggable...) {log(...) }; pattern. But maybe not worth the
conversion effort or not part of this change.
And in some pla
Hi Mandy,
Thanks for the review!
On 19/01/17 17:12, Mandy Chung wrote:
On Jan 19, 2017, at 7:30 AM, Daniel Fuchs wrote:
Hi,
Please find below a patch for:
8172971: java.management could use System.Logger
https://bugs.openjdk.java.net/browse/JDK-8172971
webrev:
http://cr.openjdk.java.net/
Hi Sean,
The changes look OK. I would capitalize ‘throws’ and looks like you are
missing a period
HTH
Lance
> On Jan 19, 2017, at 12:59 PM, Seán Coffey wrote:
>
> Changes made to the CORBA InputStream/OutputStream class back in 2013
> contained javadoc comments which should have been marked
Hi Sean,
Looks ok but can you turn those texts into a sentence (capitalize it and
final ".').
Thanks, Roger
On 1/19/2017 12:59 PM, Seán Coffey wrote:
Changes made to the CORBA InputStream/OutputStream class back in 2013
contained javadoc comments which should have been marked as
implementa
Hi Daniel,
Very straight-forward.
I can see many places where the supplier form of logging could be used
instead
of the if (loggable...) {log(...) }; pattern. But maybe not worth the
conversion effort or not part of this change.
And in some places there is both the if(loggable) and the supp
Changes made to the CORBA InputStream/OutputStream class back in 2013
contained javadoc comments which should have been marked as
implementation specific. The minor edits here should correct that.
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8077395/webrev/
JBS : https://bugs.openjdk.jav
> On Jan 19, 2017, at 7:30 AM, Daniel Fuchs wrote:
>
> Hi,
>
> Please find below a patch for:
>
> 8172971: java.management could use System.Logger
> https://bugs.openjdk.java.net/browse/JDK-8172971
>
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8172971/webrev.00/
>
This looks good
Hi Claes,
On 01/18/2017 12:01 PM, Claes Redestad wrote:
Hi Peter,
On 01/17/2017 03:10 PM, Peter Levart wrote:
As for the failure reporting: requesting an annotation for invalid
annotation type now always produces AnnotationFormatError.
Previously, some invalid annotations were simply skippe
Hi,
Please find below a patch for:
8172971: java.management could use System.Logger
https://bugs.openjdk.java.net/browse/JDK-8172971
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8172971/webrev.00/
I have also added a new test:
test/sun/management/LoggingTest/LoggingTest.java
This is a si
Hi Lance,
On 19/01/17 15:20, Lance Andersen wrote:
Hi all,
Following trivial javadoc update to Timestamp.toString() needs a review
Looks good!
-- daniel
—
ljanders-mac:jdk ljanders$ hg diff
diff -r 051e7d9159a7 src/java.sql/share/classes/java/sql/Timestamp.java
--- a/src/java.sql/
Hi all,
Following trivial javadoc update to Timestamp.toString() needs a review
—
ljanders-mac:jdk ljanders$ hg diff
diff -r 051e7d9159a7 src/java.sql/share/classes/java/sql/Timestamp.java
--- a/src/java.sql/share/classes/java/sql/Timestamp.javaTue Jan 17
11:34:47 2017 -0800
+++
This is test-only change, can still go into JDK 9?
Thanks,
Amy
On 1/19/17 9:34 PM, Amy Lu wrote:
java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
java/util/Spliterator/SpliteratorCollisions.java
Test functions in above tests are almost duplicate with functions in
java/util/str
java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
java/util/Spliterator/SpliteratorCollisions.java
Test functions in above tests are almost duplicate with functions in
java/util/stream/SpliteratorTestHelper.java. Test can reuse test
functions from SpliteratorTestHelper, but with
No, no change to ArrayList, sorry for the confusion. I just thought
ArrayList/RangeCheckMicroBenchmark.java can also give some data for
reference to the Arrays change.
So I tried a modified ArraysEquals JMH test, the test is originally for
equals(char[] a, char[] a2) and I changed it to perform
24 matches
Mail list logo
