| I understand now, thx :-)
BTW, looks like the port from ClockDaemon to Timer is very simple. The patch for server/trunk in GERONIMO-2354 does just that to avoid needing ClockDaemon.
--jason
On Aug 28, 2006, at 12:56 AM, Guillaume Nodet wrote: If we switch to backport-util-concurrent, the ClockDaemon references will have to be removed. What I meant is that the ClockDaemon vs Timer problem is superseeded by the concurrent vs backport-util-concurrent problem.
I brought retrotranslator in as an argument for the switch to backport, nothing more.
Sorry if it was not clear.
On 8/28/06, Jason Dillon < [EMAIL PROTECTED]> wrote:Ya, I know that :-P
But what does that have to do with ClockDaemon and Timer?
On Aug 28, 2006, at 12:45 AM, Guillaume Nodet wrote: When weaving java.util.concurrent specific JDK 5 classes to JDK 1.4,
retrotranslator changes calls to the standard packages to calls to
the backport-util-concurrent package.
On 8/28/06, Jason Dillon < [EMAIL PROTECTED]> wrote: Retrostranslator uses Timer?
--jason
On Aug 28, 2006, at 12:32 AM, Guillaume Nodet wrote: I think we should switch to backport-util-concurrent instead of concurrent.
This will allow for easier switch to full JDK 5 later (and this is the library used
by retrotranslator, btw).
On 8/28/06, Jason Dillon < [EMAIL PROTECTED] > wrote: Does not look like ClockDaemon is going to ever make it into java.util.concurrent (or the backport). I've also found several sources online that suggest that " Doug Lea says that it replaces its ClockDaemon class.", though I have not actually found anywhere that Doug actually says that.
It also looks like ClockDaemon was added way back before there was java.util.Timer in the JDK... and I'm guessing that since they did not bring it into java.util.concurrent that it is probably recommended to just use java.util.Timer.
--jason
--
Cheers,
Guillaume Nodet
--
Cheers,
Guillaume Nodet
--
Cheers,
Guillaume Nodet |
