Durations in existing JDK APIs (original) (raw)

Doug Lea dl at cs.oswego.edu
Wed May 30 18:32:46 UTC 2018

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.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; }

More information about the core-libs-dev mailing list