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