Deprecation of LogRecord.getMillis in JDK9

[Jason Mehrens]

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.fuchs at 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
>