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

[Daniel Fuchs]

Hi Bernd,

I will make some measurements - I don't expect that the cost
of the new accessor will matter much as from my early
measurements [1] it's not that far from the cost of
System.currentTimeMillis().

best regards,

-- daniel

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-January/030714.html


On 2/14/15 3:31 AM, Bernd Eckenfels wrote:
> 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