On 30 May 2018 at 18:15, Kurt Alfred Kluever <k...@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
