Re: Fwd: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs

On 22.07.2014 20:12, Joe Darcy wrote: Hello Georgiy, On 07/22/2014 08:49 AM, Georgiy Rakov wrote: Hello Joe, following assertion seems to me too loose: * Because of the unspecified order of operations and the * possibility of using differing summation schemes, the output of *

Re: RFR: JDK-8051713 - URL constructor/equals/hashCode/sameFile/openConnection synchronization issues

Hi Peter, This is certainly a thorny issue, and I agree with the approach of using StampedLock. Some small comments / questions: 1) Why abuse fieldsLock in hostAddress(), rather than grabbing the writeLock ? 2) Does the setAccessible in readObject need to be in a doPriv? Also should th

RFR JDK-8051991: Flatten VersionHelper hierarchies

Hi everyone, Could you please review my change for JDK-8051991? http://cr.openjdk.java.net/~prappo/8051991/webrev.00/ -Pavel

Review request for JDK-8051561: Convert JAXP function tests: javax.xml.xpath.* to jtreg (testNG) tests

Hi Joe, alan and every one I'm working on jaxp functional test colocation which is traced by the bug JDK-8043091 . We have finished to convert a few suite and the jaxp/xpath tracked by bug JDK-8051561

JEP 198: Light-Weight JSON API

New JEP Candidate: http://openjdk.java.net/jeps/198 - Mark

Re: RFR: JDK-8051713 - URL constructor/equals/hashCode/sameFile/openConnection synchronization issues

Hi Chris, Thanks for looking into this... On 07/25/2014 02:53 PM, Chris Hegarty wrote: Hi Peter, This is certainly a thorny issue, and I agree with the approach of using StampedLock. Some small comments / questions: 1) Why abuse fieldsLock in hostAddress(), rather than grabbing the writ

Re: RFR (XS) JDK-8051861 [TESTBUG] test "java/math/BigInteger/BigIntegerTest.java" does not hold Random value to have a possibility to reproduce it

Hi! Fixed. On 24.07.2014 19:52, Joe Darcy wrote: If you are going to report the seed to the test log, that should be done unconditionally regardless of whether a passed in seed is being used. diff -r 08d0c4b1a48d test/java/math/BigInteger/BigIntegerTest.java --- a/test/java/math/BigIntege

Re: Review request for JDK-8051561: Convert JAXP function tests: javax.xml.xpath.* to jtreg (testNG) tests

Hi Eric, A few comments: - TestBase.java: 39: typo "Unexcepted" -> "Unexpected" - TestUtils.java: 32: Consider moving XML_DIR to TestBase.java, it seems similar to the other static final strings - TestBase.java: 57,66; Is the extra starting/ending output useful for TestNg Tests? T

ReferenceQueue.remove to allow GC of the queue itself

Hi. I'd like to add one new method into java.lang.ref.ReferenceQueue. Can anyone help me go through the review process? I've reported https://bugs.openjdk.java.net/browse/JDK-8051843 but that probably is not enough, right? Thanks in advance for your help. -jt

RFR (XS) JDK-8051861 [TESTBUG] test "java/math/BigInteger/BigIntegerTest.java" does not hold Random value to have a possibility to reproduce it

Hi, Please review and help me with integration: Problem: java.math.BigInteger.BigIntegerTest uses java.math.Random(), so we have no possibility to reproduce it. Solution: Test gets start random seed from environment variable. If this variable not exists, test write current random seed t

Re: [concurrency-interest] ThreadLocalRandom clinit troubles

Can someone summarize what happened? SecureRandom used to get entropy from /dev/random, which is configurable through a policy file to /dev/urandom. Has this changed? Alex On 12/07/2014 00:33, Martin Buchholz wrote: Thanks to Peter for digging into the secure seed generator classes and comin

Re: ReferenceQueue.remove to allow GC of the queue itself

So, let’s start with the problem, rather than the solution. Could you start with writing up what issue you’re trying to address, and then we can proceed to evaluating whether the proposed solution is the right one? On Jul 24, 2014, at 7:29 AM, Jaroslav Tulach wrote: > Hi. > I'd like to add

Re: Fwd: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs

Hello Georgiy, On 7/25/2014 5:44 AM, Georgiy Rakov wrote: On 22.07.2014 20:12, Joe Darcy wrote: Hello Georgiy, On 07/22/2014 08:49 AM, Georgiy Rakov wrote: Hello Joe, following assertion seems to me too loose: * Because of the unspecified order of operations and the * possibility