I was trying to replicate a bug by using the same instance of SimpleDateFormat across multiple threads. However I got stuck with another problem and did not find any answers to it.
This simple code block replicates the issues I am seeing.
DateFormat d1 = new SimpleDateFormat("ddMMyyyy");
DateFormat d2 = new SimpleDateFormat("ddMMyyyy");
DateFormat d3 = new SimpleDateFormat("ddMMyy");
System.out.println("d1 = " + d1);
System.out.println("d2 = " + d2);
System.out.println("d3 = " + d3);
The results of this operations under java 7 (1.7_0_21) is as follows
d1 = java.text.SimpleDateFormat@c5bfbc60
d2 = java.text.SimpleDateFormat@c5bfbc60
d3 = java.text.SimpleDateFormat@b049fd40
As you can see that although I am creating new objects for d1 and d2 they end up being the same reference. d3 ends up being a new instance as pattern is different.
Does java compile/runtime do this optimization? Any pointers will be helpful
They are different instances, try this
it prints
as for the same
java.text.SimpleDateFormat@c5bfbc60
, they are based on class name and hashCode. According to Object.hashCode API it does not necessarily return distinct values for distinct objectsSimpleDateFormat
norDateFormat
(SimpleDateFormat
superclass) norFormat
(DateFormat
superclass) have atoString()
implemented, so thetoString()
from theObject
class is actually executed, whose code is :Now,
SimpleDateFormat
hashCode is generated:Which means that if you create numerous
SimpleDateFormat
instances with the samepattern
, like in your case, they will have the samehashCode
and hencetoString()
will return the same for these instances.Moreover, as it has been spotted by rixmath,
SimpleDateFormat
instances with the samepattern
will also be equal.SimpleDateFormat
actually implementshashCode
by returning the hashcode of the pattern.You can verify that there are actually distinct objects by using
System.identityHashCode()
:This will print 3 different values.