The DateFormat class does not appear to be
threadsafe.  It is easy to reproduce.
Run the following code.  You will get a lot of
StringIndexOutOfBoundsExceptions.
Please advise me if there is a design problem 
with my code.  Thank you.

Mike Freemon
Sr. Systems Analyst
Information Technology
Illinois Power
Decatur IL  USA
mike_freemon@illinova.com
voice:  217-425-4197


import java.text.*;
import java.util.*;

public class Main implements Runnable
{
    private static DateFormat dateFormat;
    private static Thread thr1;
    private static Thread thr2;
    private static Thread thr3;
    private static Thread thr4;
    
	public static void main(String args[]) 
	{
        dateFormat = DateFormat.getDateTimeInstance(DateFormat.SHORT,DateFormat.MEDIUM);
        TimeZone tz = TimeZone.getTimeZone("CST");
        dateFormat.setTimeZone(tz);

        thr1 = new Thread(new Main());
        thr2 = new Thread(new Main());
        thr3 = new Thread(new Main());
        thr4 = new Thread(new Main());
        
        thr1.start();
        thr2.start();
        thr3.start();
        thr4.start();
        
        try
        {
            thr1.join();
            thr2.join();
            thr3.join();
            thr4.join();
        }
        catch(Exception e)
        {}
        
	} //end of method main
    
    public void run() 
    {
        Date ddd = new Date(97,10,12,8,59,0);
        long start = ddd.getTime();
        long i = 0;
        while(true)
        {
            Date dateCurrent = new Date(start + i);
            String sss = dateFormat.format(dateCurrent);  //error here
            
            i++;
            if (i%100 == 0)  //simple status msg
                System.out.println("count is " + i + "; sss is " + sss);
        }
            
    } //end of method run
    
} //end of class Main
(Review ID: 20178)
======================================================================

======================================================================

working as designed.

I have run across this using SimpleDateFormat.
Why is this designed to be thread unsafe?  And,
of course, why is this not noted in enormous type
somewhere in the DateFormat or SimpleDateFormat doc?

This is incredibly lame. If this truly works as
designed, then the design is broken.  Fix it,
or fix the documentation.

At the very least I would expect this to be 
clearly documented, especially when you consider
that moltiple threads are fundamental to Java
programs.  Perhaps an @threadsafe Javadoc tag?

If this is the design then it really should
be documented.  I don't like the design but see
some good points to it. Bug Parade is a huge help
with problems like this.  But, I that is not an 
excuse for failing to document properly in the
first place.

Java is almost inherently threaded.  The only way to discover that classes are
not thread-safe is through code-inspection.  My team does not have the time to
read through each component that we use to ensure that it is threadsafe.
The design decision to make this un-thread-safe is the bug.

This bug, and Sun's attitude to it, continue to be
a source of irritation.  
Does the thought not occur to shift some resources
from the bleeding edge and get the basics solid?
Devoting resources to WinTel bugs won't sell any more SPARC boxes.

Here is Sun's position on this bug when I asked them to re-open it.
Considering:
1) They give no workaround here nor in the javadoc
2) They do not document the bug in the javadoc
3) The bug was first logged in 1997
I think there has been ample opportunity to fix it properly,
on the changeover from 1.0 to 1.1, and again to 1.2.
Still, everyone's busy on Swing now aren't they?
Thank you for using the "Report A Bug" feature. The closure of
the bug Id that you are refering was due to the inherent nature
by which it was designed, and the risk of working around this
problem versus changing the design is the considerstion factor
for taking this up. This is surely accepted as a flaws, but it is in
no position to be fixed.  It is generally agreeable that in a working 
model of a product, it is better to have a known bug with a workaround
than to try eliminating it resulting in de-stabilization. As a developer,
I hope that you understand the implications and see the point 
based on which we are declining to change the design. On the 
same tone, if there happened to be a circumstance where the 
design related to this has to be changed inevitably, then a change
to this model will be surely considered. Thanks for reporting this 
problem.

See also 4228335, now re-opened!