Thanks Roger!
Simpler indeed, one less place for mistakes ;-)
Removing the override did not change the javadoc for the public API.
Joe
On 8/7/20 12:44 PM, Roger Riggs wrote:
Hi,
Simpler is better.
Does removing the override change the javadoc? That might be
considered a spec change.
Oth
Thanks Naoto!
Joe
On 8/7/20 12:45 PM, naoto.s...@oracle.com wrote:
Looks good. Thank you for the change.
Naoto
On 8/7/20 12:13 PM, Joe Wang wrote:
Hi Naoto,
Why not :-). I kept it to go with equals(). Removing both now. Added
a reference comparison as did in the Impl class.
http://cr.ope
Looks good. Thank you for the change.
Naoto
On 8/7/20 12:13 PM, Joe Wang wrote:
Hi Naoto,
Why not :-). I kept it to go with equals(). Removing both now. Added a
reference comparison as did in the Impl class.
http://cr.openjdk.java.net/~joehw/jdk16/8246816/webrev_04/
Joe
On 8/7/20 10:50 AM
Hi,
Simpler is better.
Does removing the override change the javadoc? That might be considered
a spec change.
Otherwise, looks good.
Roger
On 8/7/20 3:13 PM, Joe Wang wrote:
Hi Naoto,
Why not :-). I kept it to go with equals(). Removing both now. Added a
reference comparison as did in
Hi Naoto,
Why not :-). I kept it to go with equals(). Removing both now. Added a
reference comparison as did in the Impl class.
http://cr.openjdk.java.net/~joehw/jdk16/8246816/webrev_04/
Joe
On 8/7/20 10:50 AM, naoto.s...@oracle.com wrote:
Hi Joe,
If the new XMLGregorianCalendarImpl.hashCo
Hi Joe,
If the new XMLGregorianCalendarImpl.hashCode() just calls
super.hashCode(), could it be removed entirely? Also
XMLGregorianCalendarImpl.equals() seems to do the same thing as its
parent. Could it also be removed?
Naoto
On 8/7/20 10:16 AM, Joe Wang wrote:
Naoto, Roger,
Sorry have t
Naoto, Roger,
Sorry have to come back with another iteration. It looks like the
addition of getMillisecond() over the original implementation does
change things.
In particular, getMillisecond() returns FIELD_UNDEFINED when
fractionalSecond == null (or not specified). But the normalization
p
Thanks Naoto, Roger! I'll prepare push based on version 01.
Best,
Joe
On 8/6/20 1:29 PM, Roger Riggs wrote:
+1
On 8/6/20 4:18 PM, naoto.s...@oracle.com wrote:
Hi Joe, thank you for looking it into further.
Yes, I agree the chances of collision is very rare, as
sub-millisecond difference in
+1
On 8/6/20 4:18 PM, naoto.s...@oracle.com wrote:
Hi Joe, thank you for looking it into further.
Yes, I agree the chances of collision is very rare, as sub-millisecond
difference in two objects. So fine with the version 01.
Naoto
On 8/6/20 12:18 PM, Joe Wang wrote:
Thanks Naoto, Roger for
Hi Joe, thank you for looking it into further.
Yes, I agree the chances of collision is very rare, as sub-millisecond
difference in two objects. So fine with the version 01.
Naoto
On 8/6/20 12:18 PM, Joe Wang wrote:
Thanks Naoto, Roger for the review!
For Naoto's concern about the equals me
Thanks Naoto, Roger for the review!
For Naoto's concern about the equals method using EonAndYear and
FractionalSecond, I did cut corners using the all int getXXX method. The
rational was: it fulfills the equals-hashcode contract just fine, is
consistent with the existing implementation, and co
Hi Joe,
Looks fine.
Roger
On 8/5/20 7:37 PM, Joe Wang wrote:
Hello,
Please review a fix for the hashCode generation.
JBS: https://bugs.openjdk.java.net/browse/JDK-8246816
webrev: http://cr.openjdk.java.net/~joehw/jdk16/8246816/webrev/
Thanks,
Joe
Hi Joe,
For the consistency with equals(), just wondering if the sub-second
element should be obtained with getFractionalSecond() instead of
getMillisecond(), as the equals() subsequently calls it in
internalCompare() method. Also should it call getEonAndYear()
appropriately for the year?
N
Hello,
Please review a fix for the hashCode generation.
JBS: https://bugs.openjdk.java.net/browse/JDK-8246816
webrev: http://cr.openjdk.java.net/~joehw/jdk16/8246816/webrev/
Thanks,
Joe
14 matches
Mail list logo
