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]
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
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
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
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
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,
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,
On 02/12/2015 09:52 PM, Paul Sandoz wrote:
Hi
In connection with the JEP there is also a design document to help the
discussion:
http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
We are especially interesting in hearing feedback from library developers,
tool/IDE
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
On 02/12/2015 09:52 PM, Paul Sandoz wrote:
Hi
In connection with the JEP there is also a design document to help the
discussion:
http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
Hi Paul,
Thinking about this proposal, I can't escape the feeling that the design
Hi,
Please help review the changes for JDK-8073152
Issue: https://bugs.openjdk.java.net/browse/JDK-8073152
Webrev: http://cr.openjdk.java.net/~sherman/8073152/webrev/
This change is to re-organize how the standard and extended charsets
repository are
built for the jdk/jre images. Before
On 2/14/2015 12:07 AM, Andrew Haley wrote:
On 02/13/2015 10:52 PM, Dean Long wrote:
My understanding is that whether or not aarch64 allows unaligned
accesses is based on a system setting, so this change is too
simplistic.
Disabling unaligned access would be a really perverse thing to do, and
On 02/14/2015 12:09 AM, John Rose wrote:
We also need Unsafe.getIntMisaligned, etc., which wire through to whatever
second-best mechanism the platform offers.
Indeed. I'm intending to prototype a design for those next week. OK?
Andrew.
On 02/13/2015 10:52 PM, Dean Long wrote:
My understanding is that whether or not aarch64 allows unaligned
accesses is based on a system setting, so this change is too
simplistic.
Disabling unaligned access would be a really perverse thing to do, and
I suspect that GCC and glibc already assume
14 matches
Mail list logo
