Durations in existing JDK APIs (original) (raw)

Martin Buchholz martinrb at google.com
Thu May 31 07:13:05 UTC 2018

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.MINVALUE} if conversion would negatively overflow, * or {@code Long.MAXVALUE} if it would positively overflow. */ public long convert(Duration duration) { long s = convert(duration.getSeconds(), SECONDS); if (s == Long.MINVALUE) return s; long n = convert(duration.getNano(), NANOSECONDS); assert n >= 0 && n < 1000000000; return (s + n < s) ? Long.MAXVALUE : s + n; } Duration object has a big range (Long.MINVALUE ... Long.MAXVALUE 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

More information about the core-libs-dev mailing list