Re: RFR java.time.chrono equals and hashCode

2013-12-16 Thread Stephen Colebourne
Looks good to me Stephen On 17 Dec 2013 06:48, "roger riggs" wrote: > Please review this change to explicitly document the behavior of > equals and hashCode for java.time.chrono concrete types. > The behavior is not changed. > > (They had been documented but the javadoc was not inherited during a

Re: RFR java.time serialization

2013-12-16 Thread Stephen Colebourne
Looks fine AFAICT Stephen On 17 Dec 2013 09:23, "roger riggs" wrote: > Hi Sherman, > > Thanks for the comments, corrected and updated the webrev: > http://cr.openjdk.java.net/~rriggs/webrev-time-serialization/ > > On 12/16/2013 1:00 PM, Xueming Shen wrote: > >> On 12/16/2013 09:02 AM, roger rig

Re: RFR: 8029795 : LinkedHashMap.getOrDefault() doesn't update access order. (was Why doesn't new Map methods generate entry accesses on LinkedHashMap?)

2013-12-16 Thread Mike Duigou
I've updated the documentation per Paul's suggestions. Specifically, in addition to the existing put() and get() methods the new Map methods putIfAbsent() getOrDefault() compute() computeIfAbsent() computeIfPresent() merge() are all documented to perform a single access of the entry (assuming th

Re: Theoretical data race on java.util.logging.Handler.sealed

2013-12-16 Thread Mandy Chung
On 12/14/2013 9:38 AM, Peter Levart wrote: Hi, Daniel reminded me of a couple of issues the 4th revision of the patch would have when backporting to 7u. So here's another variant that tries to be more backport-friendly: http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.05

Re: RFR java.time serialization

2013-12-16 Thread roger riggs
Hi Sherman, Thanks for the comments, corrected and updated the webrev: http://cr.openjdk.java.net/~rriggs/webrev-time-serialization/ On 12/16/2013 1:00 PM, Xueming Shen wrote: On 12/16/2013 09:02 AM, roger riggs wrote: Please review these changes to java.time serialization. The format of the

RFR (JAXP) 8029955 : AIOB in XMLEntityScanner.scanLiteral upon parsing literals with > 100 LF chars

2013-12-16 Thread huizhe wang
Hi, This is a quick fix for a whitespace buffer that was not adjusted properly in one of the two cases. The buffer, whiteSpaceLookup, is filled in two cases and adjusted properly the 2nd time. The code is moved into a method storeWhiteSpace so that it's shared for the 1st case as well. Not

Re: RFR java.time serialization

2013-12-16 Thread Xueming Shen
On 12/16/2013 09:02 AM, roger riggs wrote: Please review these changes to java.time serialization. The format of the serialized data is unchanged; deserialization uses readObject instead of readResolve to flag invalid values. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-time-serializatio

Re: RFR java.time serialization

2013-12-16 Thread Chris Hegarty
Roger, The source changes look good to me, and in line with the Serialization proxy idiom (ignoring the Externalizable stuff). -Chris. On 16 Dec 2013, at 17:02, roger riggs wrote: > Please review these changes to java.time serialization. > The format of the serialized data is unchanged; deser

RFR java.time.chrono equals and hashCode

2013-12-16 Thread roger riggs
Please review this change to explicitly document the behavior of equals and hashCode for java.time.chrono concrete types. The behavior is not changed. (They had been documented but the javadoc was not inherited during an earlier refactoring). Webrev: http://cr.openjdk.java.net/~rriggs/webrev-t

RFR java.time serialization

2013-12-16 Thread roger riggs
Please review these changes to java.time serialization. The format of the serialized data is unchanged; deserialization uses readObject instead of readResolve to flag invalid values. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-time-serialization/ Thanks, Roger

Re: Review request for 8021368: Launch of Java Web Start app fails with ClassCircularityError exception

2013-12-16 Thread Joel Borggren-Franck
Hi Mandy, Looks good. cheers /Joel On 2013-12-14, Mandy Chung wrote: > Hi Peter, > > Thanks for the review. This code path is critical in this core > reflection implementation and I want to resolve this bug with a low > risk fix in an update release and thus the proposed fix. Thanks > for t

Re: Theoretical data race on java.util.logging.Handler.sealed

2013-12-16 Thread Daniel Fuchs
On 12/14/13 6:38 PM, Peter Levart wrote: Hi, Daniel reminded me of a couple of issues the 4th revision of the patch would have when backporting to 7u. So here's another variant that tries to be more backport-friendly: http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.05/ Th