I had a similar problem with LocalDate, I was trying to use it across
calls between EJBs and it seemed to fail in the Serialization area and
had something to do with Chronology. I never solved it and just changed
my code to use DateTime classes instead.
If it's been fixed, that would be great, I might need it on the next
project.
This link to the issue;
http://sourceforge.net/mailarchive/forum.php?thread_name=94E5C33DD7DC424
3B1E33DBE5232B9240F7AA6%40EXUNZ061LDA05.oceania.corp.anz.com&forum_name=
joda-interest
(if the link doesn't work, look for my name in the September 2010 issues
from the archive).
________________________________
From: Hiller, Dean (Contractor) [mailto:dean.hil...@broadridge.com]
Sent: Saturday, 30 April 2011 8:00 a.m.
To: joda-interest@lists.sourceforge.net
Cc: Vermuelen, Paul (Contractor); Tim Dalsing; Sivanesan,Om (Contractor)
Subject: [Joda-interest] more detail/proof on hashCode failure of
LocalDate
Proof is below. The main summary is that DateTimeFieldType.java has NO
hashCode method so returns different hashcodes in different JVMs
L.....and AbstractPartialDate's hashCode calls that hashCode which
varies from JVM to JVM so two dates that are equal become unequal. It
works in a single JVM since there is only one instance of
DateTimeFieldType in a JVM. First bug I hit in joda time after using it
for about 2 years(still way better than the jdk time api ;) ).
I have the following code to log what the LocalDate(or rather
AbstractPartialDate) is doing in it's hashCode method
It turns out the hashcode of the dt.getFieldType(i)(year, monthOfYear
and date are all different) returns different values on the different
servers!!!! Ouch!!!!
This email is html color coded from eclipse copy so not sure if you can
read it???.....
log.info("Resolver: saving rdbms key=" + overallKey
+ " hash1=" + pk.getAccountId().hashCode() + " hash2="
+ pk.getMarketvalueDt().hashCode());
LocalDate dt = pk.getMarketvalueDt();
for (int i = 0; i < dt.size(); i++) {
int val = dt.getValue(i);
int typeHash = dt.getFieldType(i).hashCode();
log.info("type=" + dt.getFieldType(i) + " hashVal=" + val
+ " hashType=" + typeHash);
}
log.info("hash=" + dt.getChronology().hashCode());
Log from server 1....
2011-04-29 13:41:53,209 INFO [Function Execution Processor1]
c.b.p.p.KeyMappingR
esolution
: Resolver: saving rdbms key=RdbmsKey
[rdbmsClass=com.broadridge.papr.olddb.marketvalue.ETLMvAccountDbo,
rdbmsKey=MvAccountPK [accountId=18487, marketvalueDt=2011-01-12]]
hash1=18487 hash2=-77876543
2011-04-29 13:41:53,209 INFO [Function Execution Processor1]
c.b.p.p.KeyMappingResolution
: type=year hashVal=2011 hashType=20028211
2011-04-29 13:41:53,209 INFO [Function Execution Processor1]
c.b.p.p.KeyMappingResolution
: type=monthOfYear hashVal=1 hashType=1235672037
2011-04-29 13:41:53,209 INFO [Function Execution Processor1]
c.b.p.p.KeyMappingResolution
: type=dayOfMonth hashVal=12 hashType=1773059369
2011-04-29 13:41:53,209 INFO [Function Execution Processor1]
c.b.p.p.KeyMappingResolution
: hash=885211
Log from server 2
2011-04-29 13:41:53,210 INFO [PartitionedRegion Message Processor1]
c.b.p.p.KeyMappingResolution
: Resolver: saving rdbms key=RdbmsKey
[rdbmsClass=com.broadridge.papr.olddb.marketvalue.ETLMvAccountDbo,
rdbmsKey=MvAccountPK [accountId=18487, marketvalueDt=2011-01-12]]
hash1=18487 hash2=-1292312838
2011-04-29 13:41:53,210 INFO [PartitionedRegion Message Processor1]
c.b.p.p.KeyMappingResolution
: type=year hashVal=2011 hashType=1905251818
2011-04-29 13:41:53,210 INFO [PartitionedRegion Message Processor1]
c.b.p.p.KeyMappingResolution
: type=monthOfYear hashVal=1 hashType=438644709
2011-04-29 13:41:53,210 INFO [PartitionedRegion Message Processor1]
c.b.p.p.KeyMappingResolution
: type=dayOfMonth hashVal=12 hashType=2137747659
2011-04-29 13:41:53,210 INFO [PartitionedRegion Message Processor1]
c.b.p.p.KeyMappingResolution
: hash=885211
From: Hiller, Dean (Contractor)
Sent: Friday, April 29, 2011 1:32 PM
To: 'joda-interest@lists.sourceforge.net'
Subject: hashCode on LocalDate failed in this instance
We are using a nosql platform in which we shipped a LocalDate to another
server. The hashCode of LocalDate on the other server was different than
the one on my local server. I am still not why. The toString spit out
the exact same date AND on my local server when I serialize/deserialize,
the hashCode was still the same. It was only when I serialized the
LocalDate to another server and called hashcode that I received a
different result even though the toString is the exact same date on both
nodes.
Is LocalDate grabbing some different timezone from the local computer
instead of serializing and sending that date. All of this comes from
simple new LocalDate().plusOrMinusXXX(int x) calls. We don't use any
timezone stuff at this point though.
Thanks,
Dean
This message and any attachments are intended only for the use of the
addressee and
may contain information that is privileged and confidential. If the
reader of the
message is not the intended recipient or an authorized representative of
the
intended recipient, you are hereby notified that any dissemination of
this
communication is strictly prohibited. If you have received this
communication in
error, please notify us immediately by e-mail and delete the message and
any
attachments from your system.
"This e-mail and any attachments to it (the "Communication") is, unless
otherwise stated, confidential, may contain copyright material and is for the
use only of the intended recipient. If you receive the Communication in error,
please notify the sender immediately by return e-mail, delete the Communication
and the return e-mail, and do not read, copy, retransmit or otherwise deal with
it. Any views expressed in the Communication are those of the individual sender
only, unless expressly stated to be those of Australia and New Zealand Banking
Group Limited ABN 11 005 357 522, or any of its related entities including ANZ
National Bank Limited (together "ANZ"). ANZ does not accept liability in
connection with the integrity of or errors in the Communication, computer
virus, data corruption, interference or delay arising from or in respect of the
Communication."
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Joda-interest mailing list
Joda-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/joda-interest
