Hi Bernd,
I will make some measurements - I don't expect that the cost
of the new accessor will matter much as from my early
measurements [1] it's not that far from the cost of
System.currentTimeMillis().
best regards,
-- daniel
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-January/030714.html
On 2/14/15 3:31 AM, Bernd Eckenfels wrote:
Hello,
it is good to see new features beeing used. I wonder what the
performance impact is. I think the new accesor is not yet an intrinsic
- but on the other hand it seems not so worse. In addition to that the
splitting in long+int also takes some additional time.
Gruss
Bernd
Am Fri, 13 Feb 2015
15:57:42 -0600 schrieb Jason Mehrens <jason_mehr...@hotmail.com>:
Daniel,
In the XMLFormatter.format you can get rid of the double call to
getNanoAdjustment() since you have stored the value in the local var
'nanos'.
For the new XMLFormatter constructor what do you think about using
Properties, Function<String, String>, or perhaps a builder pattern?
That way if XMLFormatter is modified in the future to support
Throwable.getCause and Throwable.getSuppressed you don't have to keep
creating constructors to toggle features.
Jason
----------------------------------------
Date: Fri, 13 Feb 2015 15:56:28 +0100
From: daniel.fu...@oracle.com
To: core-libs-dev@openjdk.java.net
Subject: RFR: 8072645: java.util.logging should use java.time to
get more precise time stamps
Hi,
Please find below a patch for:
8072645: java.util.logging should use java.time to get more
precise time stamps
http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.00/
specdiff:
http://cr.openjdk.java.net/~dfuchs/webrev_8072645/specdiff-logging-time/java/util/logging/package-summary.html
Overview:
---------
The patch is made of the following pieces:
- LogRecord uses java.time.Clock's systemClock to get an
Instant in the best available resolution.
The instant is split into a number of milliseconds (a long)
and a nanosecond adjustment (an int).
The number of milliseconds is the same than what would have
been obtained by calling System.currentTimeMillis().
- LogRecord acquires a new serializable int nanoAdjustement field,
which can be used together with the number of milliseconds
to reconstruct the instant.
- SimpleFormatter is updated to pass a ZoneDateTime
instance to String.format, instead of a Date.
The effect of that is that the format string can now
be configure to print the full instant precision, if
needed.
- XMLformatter will add a new <nanos> element after the
<millis> element - if the value of the nanoAdjustment
field is not 0.
The <date> string will also contain the nano second
adjustment as well as the zone offset as formatted by
DateTimeFormatter.ISO_OFFSET_DATE_TIME
Compatibility considerations:
-----------------------------
- The serial for of log record is backward/forward compatible.
I added a test to verify that.
- XMLFormatter has acquired a new configurable property
'<FQCN>.printNanos' which allows to revert to the old
XML format, should the new format cause issues in
existing applications.
- The logger.dtd will need to be updated, to support the
new optional <nanos> element. And for this matter,
should we update the logger.dtd or rather define a
logger-v2.dtd?
See planned modification:
<http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-dtd/logger.dtd.frames.html>
best regards,
-- daniel
