Re: Nasty problem in javax.swing.Timer.restart()

[Meskauskas Audrius]

Can be rewritten! javax.swing.Timer is older than java.util.Timer. The 
parts of swing timer were rewritten several times by various developers, 
and the general plan of the class, I agree, is rather unclear. For sure, 
it needs a single thread not just per timer but even per each task 
restart that is really a little bit too much. I was fixing that class in 
the past, but little can be done without the radical rewrite.

After such rewriting, java.util.Timer will become a subject of very 
serious tests from the side of Swing applications. Also, it will be 
indirectly covered by existing javax.swing.Timer Mauve tests.

Finally, this task would be a lot more important and useful than just 
fix of the too early appearing tool tips.

P.S There are three Mauve tests for swing timer. If you decide to 
rewrite this, check if they run ok on your version. I would also suggest 
to write a test for the restart().

Mark Wielaard wrote:

> Hi,
>
> On Thu, 2005-11-10 at 19:26 +0100, Meskauskas Audrius wrote:
>  
>
> > Thanks for idea. The problem seems real and the solution may work.
> >    
>
> Yes, thanks Joao. I agree the problem is real. The queueLock is used for
> multiple things that are not completely related (guarding the queue
> variable and guarding Timer running status). But I am afraid we have to
> do a more radical rewrite of this class. Reading some bits about how
> swing Timers are used suggests that they should/can just use one Thread
> for all Timers you create. And that makes sense since I assume swing
> Timers are often used so creating/destroying a Thread each time a Timer
> is instantiated might be a bit much overhead. We should then make this
> Thread a daemon thread so when all other Threads stop the program
> properly terminates. I believe our util Timer code is pretty much what
> we want here. Util Timer uses a heap of TimerTasks to makes finding the
> next task to fire O(1) and inserting new tasks O(logn). One Util Timer
> can then be shared by all Swing Timers which just register TimerTasks
> with it. But maybe I am over-engineering here (I wrote Util Timer, so I
> am biased. I also introduced this bug in Swing Timer so I am also a bit
> embarrassed).
>
> We clearly need more (mauve) tests for this class.
>
> Cheers,
>
> Mark
>