RFR: 8072645: java.util.logging should use java.time to get more precise time stamps
Jason Mehrens
jason_mehrens at hotmail.com
Tue Feb 17 03:08:36 UTC 2015
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.fuchs at oracle.com
> To: jason_mehrens at hotmail.com; core-libs-dev at 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.fuchs at oracle.com<mailto:daniel.fuchs at oracle.com>
> To: core-libs-dev at openjdk.java.net<mailto: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><http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-dtd/logger.dtd.frames.html>
>
> best regards,
>
> -- daniel
>
More information about the core-libs-dev
mailing list