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
