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