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
