Deprecation of LogRecord.getMillis in JDK9

[Daniel Fuchs]

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
>>>
>>
>