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.lev...@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
>
>
