RFR: 8072645: java.util.logging should use java.time to get more precise time stamps

[Bernd Eckenfels]

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_mehrens at 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.fuchs at oracle.com
> > To: core-libs-dev at 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