Hi Daniel, I like proposed #3 solution too. Usually is best to not allow "poisoning the well". This will really help me out with supporting older platforms and keeping the code smell to a minimum.
Thanks for taking this on, Jason ________________________________________ From: Daniel Fuchs <daniel.fu...@oracle.com> Sent: Tuesday, December 1, 2015 12:48 PM To: Jason Mehrens; Core-Libs-Dev; Stuart Marks Subject: Re: Deprecation of LogRecord.getMillis in JDK9 Hi Jason, Stuart, Here is a potential fix for the issue: http://cr.openjdk.java.net/~dfuchs/webrev_8144262/webrev.00/src/java.logging/share/classes/java/util/logging/LogRecord.java.frames.html http://cr.openjdk.java.net/~dfuchs/webrev_8144262/specdiff-logging/java/util/logging/LogRecord.html As Stuart noted, java.time.Instant has a greater range than what can be constructed from a long milliseconds-since-epoch + a nano-time adjustment. This does not apply to instants returned by the system clock, since those are constructed precisely from such long milliseconds-since-epoch + nano-time adjustment. However - someone could conceivably construct such an Instant and pass it to a LogRecord. If that happens, then LogRecord.getMillis() could potentially throw an undocumented ArithmeticException. So we have at least 3 possibilities: 1. do nothing 2. document that getMillis() can throw ArithmeticException, with the additional consequence that serializing a LogRecord thus constructed would also throw an ArithmeticException. 3. modify setInstant() to validate that the instant will fit in a long milliseconds-since-epoch. The above patch implements option 3 (which currently has my preference). Is that the best solution? I would very much like to hear your opinion. If it seems like the best then I'll add a unit test, send an RFR, and do the paper work for the spec change... best regards, and thanks for all the valuable feedback! -- daniel On 30/11/15 18:04, Jason Mehrens wrote: > Hi Daniel, > > > When JDK-8072645 - java.util.logging should use java.time to get more precise > time stamps was commited the LogRecord.getMillis() method was marked as > deprecated with the reason "To get the full nanosecond resolution event time, > use getInstant". I can see marking LogRecord.setMillis as deprecated since > using that would be an untended loss of precision. However, it seems > excessive to deprecate LogRecord.getMillis when it could be treated as a > convenience method that could simply note that if the caller wants nanosecond > resolution use getInstant. It would be extremely helpful compatibility wise > to have this undeprecated for libs that have support pre-Java 9. If it can't > be undeprecated what is the proper way to target support as low as JDK7 but > might end up executing on JDK9? > > > Thanks, > > > Jason >
