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

Jason Mehrens jason_mehrens at hotmail.com
Fri Feb 13 21:57:42 UTC 2015


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 		 	   		  


More information about the core-libs-dev mailing list