Deprecation of LogRecord.getMillis in JDK9

[Roger Riggs]

Hi Daniel,

I think it makes sense to keep getMillis (and document it) as a 
convenience method.

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