Deprecation of LogRecord.getMillis in JDK9

[Stuart Marks]

Hi all,

Thanks for considering JEP 277 in this discussion. It's far from being finalized 
at this point, but SUPERSEDED seems like the most likely of the deprecation 
reasons from the proposal that would be applied here.

While it seems that getMillis() is merely a convenience method for calling 
getInstant().toEpochMilli(), there are a couple subtle semantic differences that 
might warrant consideration beyond the loss of nanosecond resolution.

First, LogRecord now contains an Instant instead of a millis-since-epoch value. 
Instant is explicitly intended to support points in time prior to the epoch. 
It's possible for a LogRecord to contain such a time via setInstant(). Thus, 
getMillis() can now return a negative number. This isn't explicitly allowed or 
disallowed as far as I can see, but historically millis-since-epoch values have 
always been non-negative. I suspect that most code out there implicitly assumes 
this and would unprepared to deal with negative return values.

Second, Instant uses a long to store seconds before or after the epoch, whereas 
a long millis-since-epoch value can only represent 1/1000th of that range. 
Instant.toEpochMilli() throws an exception in such cases. This behavior would 
show through to LogRecord.getMillis(). (It looks like this limitation is also 
present in the serial form of LogRecord.)

My hunch is that it's exceedingly rare for a LogRecord contain a time before 
1970 or 292 million years in the future, but the API allows it, so it could 
happen, and it should be specified.

This doesn't imply that getMillis() should or shouldn't be deprecated. The 
deciding factor here is whether you think it's important for programmers to 
migrate away from this API. It may be that getMillis() works just fine under all 
but the most extreme cases, so there's no practical need for programmers to 
migrate away from it.

s'marks



On 11/30/15 10:20 AM, Daniel Fuchs wrote:
> On 30/11/15 18:43, Roger Riggs wrote:
>> Hi Daniel,
>>
>> I think it makes sense to keep getMillis (and document it) as a
>> convenience method.
>
> Thanks Roger, Jason, I logged
> https://bugs.openjdk.java.net/browse/JDK-8144262
>
> best regards,
>
> -- daniel
>
>>
>> Roger
>>
>>
>> On 11/30/2015 12:25 PM, Daniel Fuchs wrote:
>>> 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?
>>>
>>> Hi Jason,
>>>
>>> I see your point.
>>>
>>> As you noted, the main reason for deprecating getMillis() is that we
>>> actually wanted to deprecate setMillis().
>>> If I remember well there was a discussion at the time around
>>> whether calling setMillis() should or should not set the nano
>>> second adjustment to 0.
>>>
>>> We ended up adding an Instant field instead of simply adding
>>> a new 'nanos' field adjustment, and then we deprecated
>>> getMillis()/setMillis() in favor of getInstant()/setInstant().
>>>
>>> That said - I agree that the only really problematic API here
>>> is setMillis().
>>>
>>> I wouldn't be opposed to 'undeprecate' getMillis() - I wonder
>>> whether that would be a good use case for JEP 277 though.
>>> (enhanced deprecation http://openjdk.java.net/jeps/277 )
>>>
>>> Any other opinion?
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>
>>>> Jason
>>>>
>>>
>>
>