[concurrency-interest] Durations in existing JDK APIs

Martin Buchholz martinrb at google.com
Wed May 30 20:19:05 EDT 2018


v.0.2 has both conversion methods in TimeUnit.  The unexpected weirdness is
that convert(Duration) saturates while toDuration throws
ArithmeticException, but both seem author-culture-consistent.  Perhaps
TimeUnit#toDuration doesn't provide enough value in view of the existing
Duration.of and TimeUnit#toChronoUnit.  And most of the time you'd expect
to convert from Duration to long, just before calling a TimeUnit based
method.

    /**
     * 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.
     * @throws NullPointerException if {@code duration} is null
     */
    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;
    }

    /**
     * Converts the given time duration in this unit to a Duration.
     *
     * @param duration the time duration
     * @return the time duration represented as a Duration
     * @throws ArithmeticException if the duration cannot be represented
     * as a Duration due to numeric overflow
     */
    public Duration toDuration(long duration) {
        return Duration.of(duration, toChronoUnit());
    }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20180530/c9e6be6b/attachment.html>


More information about the Concurrency-interest mailing list