DelayQueue is not Serializable?

[Aleksey Shipilev]

On Wed, Sep 21, 2011 at 3:00 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> On 09/21/11 05:17, Aleksey Shipilev wrote:
>>
>> On Wed, Sep 21, 2011 at 1:12 PM, Aleksey Shipilev
>> <aleksey.shipilev at gmail.com>  wrote:
>>>
>>> On Tue, Sep 20, 2011 at 10:34 PM, Doug Lea<dl at cs.oswego.edu>  wrote:
>>>  From the code perspective, it appears to be point change.
>>
>> I take that assertion back. I understand the Delayed elements which
>> are using constant delays need to be carefully recalibrated after
>> deserialization, which will probably require storing advanced metainfo
>> (i.e. "absolute time-to-fire") in serialized form.
>
> Yes, this is what I was getting at. We try to avoid in j.u.c
> any invisible conversions between relative and absolute time,
> because they are filled with potential surprises; including
> inconsistent clocks across machines, ntp adjustments,
> resets of system clocks, and the difference in precision
> between nanoTime and currentTimeMillis. And further, because
> the "Delayed" elements in the queue are opaque to us, we cannot
> automate any such conversions or adjustments anyway.
>
> If we had an AbsoluteDelayQueue, it would be a good candidate
> for being serializable.
>
> But as it stands, anyone needing to transport delayed tasks across
> machines can do so by iterating over the queue, and dealing
> one-by-one with their own Delayed elements wrt the above issues.

That's one good explanation, thanks Doug!

-Aleksey.