A good improvement and ready to go from my perspective,
thanks
Stephen
On 19 February 2015 at 15:19, Daniel Fuchs wrote:
> On 18/02/15 12:11, Stephen Colebourne wrote:
>>
>> In LogRecord, the Javadoc of getInstant():
>> "Get event time."
>> could be
>> "Gets the instant that the event ocurred."
On 18/02/15 12:11, Stephen Colebourne wrote:
In LogRecord, the Javadoc of getInstant():
"Get event time."
could be
"Gets the instant that the event ocurred."
done.
In LogRecord, the Javadoc of setInstant():
"Set event time."
could be
"Sets the instant that the event ocurred."
(matching change
strategy.
best regards,
-- daniel
Jason
Date: Tue, 17 Feb 2015 20:33:15 +0100
From: daniel.fu...@oracle.com
To: scolebou...@joda.org; core-libs-dev@openjdk.java.net; peter.lev...@gmail.com
Subject: Re: RFR: 8072645: java.util.logging should use java.time
ubject: Re: RFR: 8072645: java.util.logging should use java.time to get more
> precise time stamps
>
> Hi,
>
> Here is a new webrev - which should contain all the feedback received
> so far:
>
> #1 LogRecord uses serialPersistentFields for serialization, and
> contains a
In LogRecord, the Javadoc of getInstant():
"Get event time."
could be
"Gets the instant that the event ocurred."
In LogRecord, the Javadoc of setInstant():
"Set event time."
could be
"Sets the instant that the event ocurred."
(matching change to @param)
I'd prefer to see the other methods in the
Hi,
Here is a new webrev - which should contain all the feedback received
so far:
#1 LogRecord uses serialPersistentFields for serialization, and
contains an Instant instead of the two fields millis +
nanoAdjustment.
#2 getMillis/setMillis are deprecated, replaced by getInstant/setInstant
.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
>
Hi Stephen,
Thanks again for your support and suggestions!
On 14/02/15 14:03, Daniel Fuchs wrote:
If I'm not mistaken the previous SimpleFormatter used to use java.util.Date
and printed the time in the local time zone. I have tried to keep this
behavior.
I'm not sure we would want to change it
On 02/14/2015 04:33 PM, Peter Levart wrote:
Well, internally I think it should be stored as an Instant. So you
don't have to reconstruct Instant objects at each call to
getInstant(). Serialization of LogRecord is not a frequent
requirement, so the overhead should be moved to it, rather than to
Hi Daniel,
On 02/14/2015 01:38 PM, Daniel Fuchs wrote:
Hi Peter,
On 2/14/15 10:36 AM, Peter Levart wrote:
Hi Daniel,
The "millis" property in your proposal just changes one part of
LogRecord's notion of time (it doesn't change/reset the
nanoAdjustment part). From compatibility standpoint, y
Hi Stephen,
Thanks a lot for your feedback, it is really helpful!
On 2/14/15 11:28 AM, Stephen Colebourne wrote:
Elements of the date/time handling here don't really work.
Logging is essentially a UTC only problem, using a time-zone is slow and
unecessary. This indicates that all uses of Zoned
toggle features.
Jason
Date: Fri, 13 Feb 2015 15:56:28 +0100
From: daniel.fu...@oracle.com
To: 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.loggin
Hi Peter,
On 2/14/15 10:36 AM, Peter Levart wrote:
Hi Daniel,
The "millis" property in your proposal just changes one part of
LogRecord's notion of time (it doesn't change/reset the nanoAdjustment
part). From compatibility standpoint, your ptoposal is changing the
semantics of "millis" prope
ger.
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
To: core-libs-dev@openjdk.java.net
Subject: RFR: 8072645: java.util.logging sh
Elements of the date/time handling here don't really work.
Logging is essentially a UTC only problem, using a time-zone is slow and
unecessary. This indicates that all uses of ZonedDateTime should be
replaced with either Instant or an OffsetDateTime using ZoneOffset.UTC.
Any string format should
Hi Daniel,
The "millis" property in your proposal just changes one part of
LogRecord's notion of time (it doesn't change/reset the nanoAdjustment
part). From compatibility standpoint, your ptoposal is changing the
semantics of "millis" property. Previously "millis" was the sole
property of re
; creating constructors to toggle features.
>
>
>
> Jason
>
>
>
>
> > Date: Fri, 13 Feb 2015 15:56:28 +0100
> > From: daniel.fu...@oracle.com
> > To: core-libs-dev@openjdk.java.net
> > Subject: RFR: 8072645: java.util.logging should use java.time to
> >
e.com
> To: 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 t
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-
19 matches
Mail list logo
