On 02/12/15 02:13, Stuart Marks wrote:
I'd recommend making setInstant() be more explicit about the range of
Instant values that are allowed, namely those created from
Instant.ofEpochMilli(long), which allows ± 292 million years from the
epoch. Otherwise the reader is forced to try to understand
bject: Re: Deprecation of LogRecord.getMillis in JDK9
I think #3 or a variation is best. Clearly, #1 is inconsistent and simply
documenting it (#2) isn't much better.
I'd recommend making setInstant() be more explicit about the range of Instant
values that are allowed, namely those created fro
I think #3 or a variation is best. Clearly, #1 is inconsistent and simply
documenting it (#2) isn't much better.
I'd recommend making setInstant() be more explicit about the range of Instant
values that are allowed, namely those created from Instant.ofEpochMilli(long),
which allows +/- 292 mil
niel Fuchs
Sent: Tuesday, December 1, 2015 12:48 PM
To: Jason Mehrens; Core-Libs-Dev; Stuart Marks
Subject: Re: Deprecation of LogRecord.getMillis in JDK9
Hi Jason, Stuart,
Here is a potential fix for the issue:
http://cr.openjdk.java.net/~dfuchs/webrev_8144262/webrev.00/src/java.logging/share/cl
Hi Jason, Stuart,
Here is a potential fix for the issue:
http://cr.openjdk.java.net/~dfuchs/webrev_8144262/webrev.00/src/java.logging/share/classes/java/util/logging/LogRecord.java.frames.html
http://cr.openjdk.java.net/~dfuchs/webrev_8144262/specdiff-logging/java/util/logging/LogRecord.html
Hi Stuart,
Thanks for the feedback!
On 30/11/15 23:53, Stuart Marks wrote:
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.
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
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:
andard API
and add an @apiNote instead of the @deprecated
comment.
best regards,
-- daniel
Thanks,
Jason
From: Daniel Fuchs
Sent: Monday, November 30, 2015 11:32 AM
To: Jason Mehrens; Core-Libs-Dev
Subject: Re: Deprecation of LogRecord.getMillis in JDK9
; Core-Libs-Dev
Subject: Re: Deprecation of LogRecord.getMillis in JDK9
Hi Jason,
To complete my earlier reply:
On 30/11/15 18:25, Daniel Fuchs wrote:
> 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?
Well - a lib
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 w
Hi Jason,
To complete my earlier reply:
On 30/11/15 18:25, Daniel Fuchs wrote:
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?
Well - a lib using LogRecord.getMillis() could
use @SuppressWarnings("deprecation') when calli
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
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
14 matches
Mail list logo
