Durations in existing JDK APIs

[Martin Buchholz]

In j.u.concurrent the APIs bottom out in something that just takes a long
nanos, like LockSupport.parkNanos, so there's no advantage to converting to
TimeUnit-based durations greater than 292 years.  And returning multiple
values in Java remains clumsy.

On Wed, May 30, 2018 at 11:06 PM, Peter Levart <peter.levart at gmail.com>
wrote:

> Just thinking loud...
>
>
> On 05/30/18 19:36, 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?
>
> 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;
>     }
>
>
> Duration object has a big range (Long.MIN_VALUE ... Long.MAX_VALUE
> seconds) and a nanosecond precision. Both can not always be expressed as a
> pair of (TimeUnit, long) which are the usual parameter(s) of some methods.
> Above API proposal leaves the decision which TimeUnit to choose for
> conversion to the programmer. Would a pair of methods on Duration that
> return a TimeUnit and a long make sense here? The Duration could choose
> TimeUnit so that returned (TimeUnit, long) pair would be as precise as
> possible and still not overflow (like a floating point)...
>
> Peter
>
>