Daniel,
I agree with you that removing the new XMLFormatter constructor is the right thing to do in this case. Jason ________________________________ > Date: Sat, 14 Feb 2015 13:06:21 +0100 > From: daniel.fu...@oracle.com > To: jason_mehr...@hotmail.com; core-libs-dev@openjdk.java.net > Subject: Re: RFR: 8072645: java.util.logging should use java.time to > get more precise time stamps > > Hi Jason, > > On 2/13/15 10:57 PM, Jason Mehrens wrote: > > 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'. > > Thanks for spotting that, will do. > > > > > 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. > > I don't know... I added the new constructor as an after thought, to help > writing subclasses that might not want to rely on the property defined > in the configuration. If we're going to rely on property anyway, then > the correct thing to do would be to define them as configuration properties > and look for them in the LogManager. > > Maybe I should just remove the new constructor. > > What do you think? > > best regards, > > -- daniel > > > > > > > Jason > > > > ---------------------------------------- > > > Date: Fri, 13 Feb 2015 15:56:28 +0100 > From: daniel.fu...@oracle.com<mailto:daniel.fu...@oracle.com> > To: core-libs-dev@openjdk.java.net<mailto: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><http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-dtd/logger.dtd.frames.html> > > > best regards, > > -- daniel >
