Durations in existing JDK APIs (original) (raw)

Stephen Colebourne scolebourne at joda.org
Wed May 30 18:05:10 UTC 2018

On 30 May 2018 at 18:15, Kurt Alfred Kluever <kak at google.com> wrote:

1. Rename ALL existing unitless primitive method parameters to include their time unit.

This seems like a simple win. AFAIK, parameter names can be changed freely in the JDK.

2. Add a java.time overload to some APIs ... Note that new default implementations will have to delegate to the existing overloads, and will have to choose between losing precision or capping large values at e.g. 292 years (for long nanos), but it is hard to imagine this being a serious problem in practice for any of them.

+1. 292 years seems OK for these methods.

Note: it's probably not worth adding Duration overloads to legacy APIs (e.g., java.util.Timer) or low-level APIs (e.g.,java.lang.Object.wait()).

+1

3. Add a java.time overload to most APIs that currently accept a <long, TimeUnit> pair.

+1, although this is a big task

4. Add APIs to convert between TimeUnit and Duration. As users transition to the new Duration-centric world, these APIs will come in handy. They will also be necessary for overload-implementers. We're proposing Duration.of(long, TimeUnit) and TimeUnit.convert(Duration).

The rule has so far been that java.time.* does not have methods that take instances of "legacy" date/time classes. As such, the conversion method toChronoUnit() was added.

Thus, I support adding TimeUnit.convert(Duration), but not Duration.of(long, TimeUnit).

Probably worth adding a Duration overload:

* java.lang.Thread.sleep(long millis) * java.lang.Thread.sleep(long millis, long nanos) * Note: this API is particularly weird since it accepts millis and nanos!

Yes, this would be a good place to start.

* java.lang.Thread.join(long millis) * java.lang.Thread.join(long millis, long nanos) * Note: this API is particularly weird since it accepts millis and nanos!

Less important, but makes sense if altering Thread.

* java.nio.channel.Selector.select(long timeout) * java.lang.ReferenceQueue.remove(long timeout)

Maybe these.

* java.lang.Object.wait... * java.util.concurrent.locks.LockSupport... nanos) java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject... * java.util.logging.LogRecord.setMillis(long millis) * java.util.Timer.schedule...

I don't think there is a real need to tackle these.

Networking APIs (perhaps not worth adding a Duration overload?):

* java.net.InetAddress.isReachable(int timeout) * java.net.InetAddress.isReachable(NetworkInterface netif, int ttl, int timeout) * java.net.URLConnection.setConnectTimeout(int timeout) * java.net.URLConnection.setReadTimeout(int timeout) * java.net.Socket.setSoTimeout(int timeout) * java.net.Socket.connect(SocketAddress endpoint, int timeout) * java.net.ServerSocket.setSoTimeout(int timeout) * java.net.DatagramSocket.setSoTimeout(int timeout)

More of a case for some of these I think

thanks for working on the list. Its good to see the scale of the problem. thanks Stephen

More information about the core-libs-dev mailing list