Durations in existing JDK APIs

[Doug Lea]

Kurt's initial post did not make it to concurrency-interest. At this
point, it is probably least confusing if interested readers who aren't
on core-libs-dev follow this on archives:
http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev

On 05/30/2018 01:36 PM, Martin Buchholz wrote:
> Obvious progress would seem to be more conversion methods.  Conversion code
> tends to be annoying/errorprone because of having to deal with overflow.
> 
> Stephen/Doug: is there any reason we didn't add conversions between
> Duration and TimeUnit when we added conversions to ChronoUnit?

No. I agree that we should have at least this one.

The original rationale for designing j.u.c.TimeUnit using the Flyweight
pattern was to to reduce allocation and GC-related overhead and timing
jitter for methods that otherwise may operate on the order of
nanoseconds. But there are many cases in which this is not much of a
concern (plus JVMs can now sometimes optimize), so people should be
given a choice. It would be a lot of tedious work (and aggregate code
bulk) to retrofit every time-related j.u.c method though, and it's not
clear where to compromise. But at least adding converters should not be
controversial.

-Doug


> 
> Here's a strawman:
> 
>     /**
>      * Converts the given time duration to this unit.
>      *
>      * @param duration the time duration
>      * @return the converted duration in this unit,
>      * or {@code Long.MIN_VALUE} if conversion would negatively overflow,
>      * or {@code Long.MAX_VALUE} if it would positively overflow.
>      */
>     public long convert(Duration duration) {
>         long s = convert(duration.getSeconds(), SECONDS);
>         if (s == Long.MIN_VALUE) return s;
>         long n = convert(duration.getNano(), NANOSECONDS);
>         assert n >= 0 && n < 1_000_000_000;
>         return (s + n < s) ? Long.MAX_VALUE : s + n;
>     }
>