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
