5.2.x java time session and deadline

[garydgregory]

Use Java 8's java.time package in sessions and deadlines.

[ok2c]

@garydgregory IOSession is a low level transport class. There are absolutely no benefit of using Instant for internal time representation in it. I see no point changing it. Deadline changes look good to me.

[ok2c]

@garydgregory I also looked at the Instant#now implementation. It basically uses System.currentTimeMillis() internally. So, I also see no benefit of using it in low level classes.

[garydgregory]

@garydgregory I also looked at the Instant#now implementation. It basically uses System.currentTimeMillis() internally. So, I also see no benefit of using it in low level classes.

Newer versions of Java (like 11) provide nanosecond resolution. Not everyone is stuck on Java 8.

[ok2c]

Not everyone is stuck on Java 8.
@garydgregory But we are.

[garydgregory]

Not everyone is stuck on Java 8.
@garydgregory But we are.

Uh? Anyone can run our jar files on Java 11 and 17 and get the benefits.

[ok2c]

get the benefits.

@garydgregory What would those be? Nanosecond time resolution for timeout calculation with 1s precision?

[garydgregory]

get the benefits.

@garydgregory What would those be? Nanosecond time resolution for timeout calculation with 1s precision?

The most important aspect of this type of change is type safety. On Java 8, we can use objects like Instant and Duration instead of a mix of int and long which appear unscaled and are subject to underflow, overflow, and wrap around behavior. Not to mention that sometimes an argument is expressed in seconds, sometimes it's in milliseconds, a sure recipe for bugs.

[ok2c]

get the benefits.

@garydgregory What would those be? Nanosecond time resolution for timeout calculation with 1s precision?

The most important aspect of this type of change is type safety. On Java 8, we can use objects like Instant and Duration instead of a mix of int and long which appear unscaled and are subject to underflow, overflow, and wrap around behavior. Not to mention that sometimes an argument is expressed in seconds, sometimes it's in milliseconds, a sure recipe for bugs.

@garydgregory This is a legitimate reason but not for low level classes where memory footprint matters more. If have spare cycles better invest them into porting high level APIs (such those in the cookie and cache packages) from Date to Instance.

[garydgregory]

get the benefits.

@garydgregory What would those be? Nanosecond time resolution for timeout calculation with 1s precision?

The most important aspect of this type of change is type safety. On Java 8, we can use objects like Instant and Duration instead of a mix of int and long which appear unscaled and are subject to underflow, overflow, and wrap around behavior. Not to mention that sometimes an argument is expressed in seconds, sometimes it's in milliseconds, a sure recipe for bugs.

@garydgregory This is a legitimate reason but not for low level classes where memory footprint matters more. If have spare cycles better invest them into porting high level APIs (such those in the cookie and cache packages) from Date to Instance.

From where I stand, consistency is important, as is the use of the better abstractions. I don't see evidence of memory footprint issues. I've not seen memory issues in this department in the past. There are lots of objects coming and going in a Java app, even a trivial one, and Java is getting better and better at managing memory on and off heap for object allocation. I brief, I don't see a real issue.

[michael-o]

I agree with @ok2c Instant gives here zero benefit compared with long.