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

[Joao Victor]

About using only 1 thread; i think swing.Timer can have only one
thread inside it (using a util.Timer as back-end), but i don't know if
it'll be possible for every swing component to use the same
swing.Timer (like they do now, calling Timer.sharedInstance() or
something like that); i think each component needs to instantiate its
own swing.Timer...

Cheers,
J.V.


2005/11/10, Meskauskas Audrius <address@hidden>:
> 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
> >
> >
>
>