java.lang.AssertionError: cache control: inconsictency, cachedFixedDate=733763, computed=733763, date=2009-12-22T00:00:00.000Z(Courtesy of
at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2070)
at java.util.GregorianCalendar.computeTime(GregorianCalendar.java:2472)
at java.util.Calendar.updateTime(Calendar.java:2468)
at java.util.Calendar.getTimeInMillis(Calendar.java:1087)
at java.util.Calendar.getTime(Calendar.java:1060)
at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1368)
at java.text.DateFormat.parse(DateFormat.java:335)
-enablesystemassertions
). Because, yeah, SimpleDateFormat
is not thread-safe.Date formats are not synchronized. It is recommended to create separate format instances for each thread. If multiple threads access a format concurrently, it must be synchronized externally.Like many things in Java, this is just retarded. If
SimpleDateFormat
was written in a more functional way instead of storing the result of the last call to parse
in itself, this problem wouldn't exist.So yeah, I'm probably a JDK n00b and did not RTFM properly, but this just adds up to the already overflowing list of crap in the JDK.
In the next episode we'll review the OMGWTFBBQ code you have to write to use Java's crappy IO library – and I'm not even talking about the fact that the library exclusively allows 1975-style programming... which is generally the case for everything written in Java anyway.
Also, it's spelled "inconsistency" not "inconsictency", dumbass.
The moral of the story is that if
grep 'static .* SimpleDateFormat'
on your code returns anything, you have a bug!Edit 2010-09-27: This can also manifest itself if parsing a date fails randomly with weird error messages such as:
ParseException: For input string: ""
(even though the string passed in argument was definitely not empty). With such concurrency bugs, a number of weird things can happen...
No comments:
Post a Comment