Re: RFR: 8072645: java.util.logging should use java.time to get more precise time stamps
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_mehr...@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, FunctionString, 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.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.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
Re: RFR: 8072645: java.util.logging should use java.time to get more precise time stamps
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 property. Previously millis was the sole property of record's notion of time, now it is only a component of it. Consider this legacy code: LogRecord r = new LogRecord(...); // timestamp1 ... r.setMillis(System.currentTimeMillis()); // timestamp2 What is the record's notion of time now? It is composed of millis from timestamp2 and nanoAdjustment from timestamp1. Not something that one would want, right? Excellent observation. I had missed that. So what should be done instead is: - deprecate millis writable property and document that it sets the record's time with the resolution of milliseconds and point to new instantUTC property as a replacement. - add instantUTC writable property and document it as the method to be used to set record's time with full resolution - optionally add read-only nanoAdjustment property (I don't think it is needed, since users should start using new time API instead of mangling with millis and nanos themselves) This lends itself to also change internal storage of LogRecord's time. You could just replace the millis field with a reference to instantUTC. Serialization would have to be adjusted a bit (using serialPersistentFields) to stay compatible. What do you think? setMillis should definitely set the whole time for backward compatibility reasons. That will make it more than a simple setter, and therefore deprecating it is probably the best thing to do as the method name could then become misleading (setTimeAsMillis() would be the expected name for such a behaviour). That lets me think that there shouldn't be a setNanoAdjustment() either. getMillis() and getNanoAdjustment() are OK and can stay, since they are consistent - are needed for compatibility reasons (at least getMillis is), and will help with describing the serial form. As you noted, the only correct way to set the LogRecord time is to do it in a single method: We could have either setInstant() or setTime(long millis, int nanos) - setInstant being most probably the best alternative - since we already have a getInstant(), and splitting the time into millis + nanos is a bit strange anyway - since java.time favors seconds + nanos. For serialization - I think we will need to keep serializing a number of milliseconds and a nano second adjustment. Whether the time stamp should be stored internally as an Instant or as a number of milliseconds + a nano adjustment can be discussed. I might favor the second as it would make serialization easier (especially for documenting the serial form). Would you agree with that? best regards, -- daniel Regards, Peter On 02/13/2015 03:56 PM, Daniel Fuchs wrote: 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, --
Re: RFR: 8072645: java.util.logging should use java.time to get more precise time stamps
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 ZonedDateTime should be
replaced with either Instant or an OffsetDateTime using ZoneOffset.UTC.
Any string format should have the ISO-8601 string end with Z, and not end
with -05:00 or any other zone offset.
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 to print the time in the UTC
time zone
by default. A lot of developers use logging for debugging - and when reading
debug messages on the console I usually prefer to see the time in my own
time zone.
Would there be a more efficient way to keep the default formatting of
the time
in the SimpleFormatter?
(The webrev is broken wrt zones as it stores ZoneId.systemDefault() in a
static constant, but that method depends on the mutable
TimeZone.getDefault() ).
Would making it a final (non static) variable be better?
I now wonder whether there should be a way to configure the time zone for
an instance of SimpleFormatter (something like what I did with 'printNanos'
for the XMLFormatter).
LogReecord.getInstantUTC() should be getInstant().
(An Instant is fully defined as a concept, and it cannot be in or not in
UTC).
Right. Thanks for pointing that out.
In SimpleFormatter, you have {@code java.util.loggin} (missing a g).
Good catch.
In XMLFormatter, instead of using DateTimeFormatter.ISO_LOCAL_DATE_TIME,
create a new instance of DateTimeFormatter that does not output the
fraction of a second. That way, there is no need to use
truncatedTo(SECONDS).
StringBuilder appends can be used directly with formatters:
sb.append(ZonedDateTime.ofInstant(time, zoneId).format(dtformatter));
replace with
dtformatter.formatTo(ZonedDateTime.ofInstant(time, zoneId), sb);
Will look into this.
Thanks again for your review! This is quite helpful.
-- daniel
thanks
Stephen
On 13 Feb 2015 14:57, Daniel Fuchs daniel.fu...@oracle.com wrote:
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
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, FunctionString, 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.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.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
Re: RFR: 8072645: java.util.logging should use java.time to get more precise time stamps
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 record's notion of time, now it is only a component of it. Consider this legacy code: LogRecord r = new LogRecord(...); // timestamp1 ... r.setMillis(System.currentTimeMillis()); // timestamp2 What is the record's notion of time now? It is composed of millis from timestamp2 and nanoAdjustment from timestamp1. Not something that one would want, right? So what should be done instead is: - deprecate millis writable property and document that it sets the record's time with the resolution of milliseconds and point to new instantUTC property as a replacement. - add instantUTC writable property and document it as the method to be used to set record's time with full resolution - optionally add read-only nanoAdjustment property (I don't think it is needed, since users should start using new time API instead of mangling with millis and nanos themselves) This lends itself to also change internal storage of LogRecord's time. You could just replace the millis field with a reference to instantUTC. Serialization would have to be adjusted a bit (using serialPersistentFields) to stay compatible. What do you think? Regards, Peter On 02/13/2015 03:56 PM, Daniel Fuchs wrote: 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
Re: RFR: 8072645: java.util.logging should use java.time to get more precise time stamps
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 have the ISO-8601 string end with Z, and not end
with -05:00 or any other zone offset.
(The webrev is broken wrt zones as it stores ZoneId.systemDefault() in a
static constant, but that method depends on the mutable
TimeZone.getDefault() ).
LogReecord.getInstantUTC() should be getInstant().
(An Instant is fully defined as a concept, and it cannot be in or not in
UTC).
In SimpleFormatter, you have {@code java.util.loggin} (missing a g).
In XMLFormatter, instead of using DateTimeFormatter.ISO_LOCAL_DATE_TIME,
create a new instance of DateTimeFormatter that does not output the
fraction of a second. That way, there is no need to use
truncatedTo(SECONDS).
StringBuilder appends can be used directly with formatters:
sb.append(ZonedDateTime.ofInstant(time, zoneId).format(dtformatter));
replace with
dtformatter.formatTo(ZonedDateTime.ofInstant(time, zoneId), sb);
thanks
Stephen
On 13 Feb 2015 14:57, Daniel Fuchs daniel.fu...@oracle.com wrote:
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
Re: RFR: 8072645: java.util.logging should use java.time to get more precise time stamps
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, your ptoposal is changing the semantics of millis property. Previously millis was the sole property of record's notion of time, now it is only a component of it. Consider this legacy code: LogRecord r = new LogRecord(...); // timestamp1 ... r.setMillis(System.currentTimeMillis()); // timestamp2 What is the record's notion of time now? It is composed of millis from timestamp2 and nanoAdjustment from timestamp1. Not something that one would want, right? Excellent observation. I had missed that. So what should be done instead is: - deprecate millis writable property and document that it sets the record's time with the resolution of milliseconds and point to new instantUTC property as a replacement. - add instantUTC writable property and document it as the method to be used to set record's time with full resolution - optionally add read-only nanoAdjustment property (I don't think it is needed, since users should start using new time API instead of mangling with millis and nanos themselves) This lends itself to also change internal storage of LogRecord's time. You could just replace the millis field with a reference to instantUTC. Serialization would have to be adjusted a bit (using serialPersistentFields) to stay compatible. What do you think? setMillis should definitely set the whole time for backward compatibility reasons. That will make it more than a simple setter, and therefore deprecating it is probably the best thing to do as the method name could then become misleading (setTimeAsMillis() would be the expected name for such a behaviour). Unfortunately. But there is javadoc to clear things out, so I don't find this too bad. That lets me think that there shouldn't be a setNanoAdjustment() either. That's right. And I don't think we need a getter for nanoAdjustment either. See below... getMillis() and getNanoAdjustment() are OK and can stay, since they are consistent - are needed for compatibility reasons (at least getMillis is), and will help with describing the serial form. As you noted, the only correct way to set the LogRecord time is to do it in a single method: We could have either setInstant() or setTime(long millis, int nanos) - setInstant being most probably the best alternative - since we already have a getInstant(), and splitting the time into millis + nanos is a bit strange anyway - since java.time favors seconds + nanos. get/setInstant is the right name. As Stephen notes, Instant is timezone agnostic. For serialization - I think we will need to keep serializing a number of milliseconds and a nano second adjustment. Whether the time stamp should be stored internally as an Instant or as a number of milliseconds + a nano adjustment can be discussed. I might favor the second as it would make serialization easier (especially for documenting the serial form). Would you agree with that? 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 frequent code-paths. That's my opinion. Documenting serializable format should be easy anyway. It doesn't have to be based directly on public getters/setters. For example: The LogRecord's instant is serialized as two hypothetical fields to keep backwards compatibility: long millis = getInstant().toEpochMilli(); int nanoOfMilli = getInstant().getNano() % 1000_000; Regards, Peter best regards, -- daniel Regards, Peter On 02/13/2015 03:56 PM, Daniel Fuchs wrote: 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
Re: JEP 238: Multi-Version JAR Files
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 developers, and anyone doing funky stuff with class loading and JAR files. Paul. On Feb 12, 2015, at 9:41 PM, mark.reinh...@oracle.com wrote: New JEP Candidate: http://openjdk.java.net/jeps/238 - Mark Hi Paul, I read through the proposal and couldn't find an explanation of how resources placed in versioned paths are going to be visible. For example, if the multi-versioned jar contains the following structure: my.properties META-INF/versions/8/my.properties META-INF/versions/9/my.properties What will the following code return, when run on JDK9: URL[] urls = ClassLoader.getSystemClassLoader().getResources(my.properties); Will we only get 1 URL: META-INF/versions/9/my.properties or 3 URLs in order: META-INF/versions/9/my.properties, META-INF/versions/8/my.properties, my.properties Class name - .class file resolving is easy, since only the 1st one is used, but there can be multiple general resources for same path. Regards, Peter
Re: RFR: 8072645: java.util.logging should use java.time to get more precise time stamps
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 frequent code-paths. That's my opinion. Documenting serializable format should be easy anyway. It doesn't have to be based directly on public getters/setters. For example: The LogRecord's instant is serialized as two hypothetical fields to keep backwards compatibility: long millis = getInstant().toEpochMilli(); int nanoOfMilli = getInstant().getNano() % 1000_000; Regards, Peter Hi Daniel, I must admit, it's not so simple after all. I tried to do it and I had to do the following to get a decent javadoc: http://cr.openjdk.java.net/~plevart/jdk9-dev/LogRecord.instant/webrev.01/ So take it if you think this isn't too much to support or leave it and do it your way (with just an additional @serial nanoAdjustment field). Regards, Peter
Re: JEP 238: Multi-Version JAR Files
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 favors JDK as the only target for which multi-version jars exist. The versions in the jar are just target JDK versions. Admittedly JDK is the most important library out there, but jar is a general format. So perhaps at the jar level, the facility could be more general. I'm thinking about profiles... For example, taking a layout example from JEP and translating to the profiles idea: jar root - A.class - B.class - C.class - D.class - META-INF - MANIFEST.MF - profiles - jdk8 - A.class - B.class - jdk9 - A.class With additional metadata in MANIFEST.MF: Profile-JDK9: jdk9 jdk8 Profile-JDK8: jdk8 A list (ordered) of profile names is associated with each jar file or expanded directory at runtime. The default list of profile names (if not specified on classpath) consists of just the platfrom profile name (JDK9 or JDK8), but additional profile names could be encoded as part of each classpath element. For example, let's say I want to distribute a multi-profile library jar that depends on JDK7, JDK8 and JDK9 as platform and on guava 17 and 18. I could pack it as: jar root - A.class - B.class - C.class - D.class - META-INF - MANIFEST.MF - profiles - jdk8 - A.class - B.class - jdk9 - A.class - guava18 - C.class - jdk9-guava18 - C.class MANIFEST.MF: Profile-JDK9: jdk9-guava18(GUAVA18) jdk9 jdk8 Profile-JDK8: jdk8 Profile-GUAVA18: guava18 Some example usages: $JDK8_HOME/bin/java -cp guava-18.jar:mylib.jar?profile=+GUAVA18 ...in this example, the list of profile names associated with mylib.jar is: (JDK8, GUAVA18), which yields the following search order inside mylib.jar: - META-INF/profiles/jdk8 - META-INF/profiles/guava18 - jar root $JDK9_HOME/bin/java -cp guava-18.jar:mylib.jar?profile=+GUAVA18 ...in this example, the list of profile names associated with mylib.jar is : (JDK9, GUAVA18), which yields the following search order inside mylib.jar: - META-INF/profiles/jdk9-guava18 - this is a conditional entry, included only when all profile names in brackets are also associated with the jar - META-INF/profiles/jdk9 - META-INF/profiles/jdk8 - META-INF/profiles/guava18 - jar root $JDK9_HOME/bin/java -cp guava-17.jar:mylib.jar ...in this example, the list of profile names associated with mylib.jar is : (JDK9), which yields the following search order inside mylib.jar: - META-INF/profiles/jdk9 - META-INF/profiles/jdk8 - jar root The additional profile names could be encoded in file: URL(s) as the the URL query, for example: file:/path/to/my.jar?pfofile=+GUAVA18 ...so they are part of URL class-path in URLClassLoader. The JarFile and JarInputStream would have to be extended to support specifying a list of profile names in addition to current arguments. This is not much different from proposed JEP. It just adds a layer of resolving of the internal jar file paths through a list of profile names as opposed to hard-coding the layout. I know this complicates tooling support. In particular the additional options for jar tool, but verification part which validates that the exposed public API is same for all combinations of profiles would not be much more complicated. The profiles idea is inspired loosely on Maven profiles. Too complicated? Regards, Peter
RFR: JDK-8073152: Update Standard/ExtendedCharsets to work with module system
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 module system, the standard charset provider is built into rt.jar and the extended charsets provider is in charsets.jar, which is located in the lib/ext directory. both are available during the system boot time. In jigsaw, the extended charsets provider is in jdk.charset (vs the standard is in java.base) module and might not be visible during the early phase of system classes loading, which might cause problem as some of the charsets now in extended charsets may needed during the boot stage. The proposed change here is to re-organize the way these two providers are built, and put in the mechanism that enable the build system to configure which group of charsets need to be moved from the extended charsets into the standard (java.base), based on the target platform, during the jdk build time. The updates are (1) to consolidate the existing configuration files sbcs, dbcs, extsbcs and standard-charsets (and the aliases table originally hardcoded in ExtendeardCharsets.java) into a single configuration file charsets to define all supported charsets, with their name, clz name, history name, package name and all aliases http://cr.openjdk.java.net/~sherman/8073152/webrev/make/data/charsetmapping/charsets.html (2) in addition to the the standard charsets provider, now the extended charsets provider class is also built during the build time based on the new configuration file charsets (3) to add a build-time mechanism to specify individual sun.nio.cs.ext charset to be built into standard charsets provider (sun.nio.cs package in java.base module), with os-specific configuration file, such as stdcs-linux, stdcs-windows and stdcs-solaris. (4) to move DoubleByte, HKSCS and DelegatableDecoder classes into sun.nio.cs, so they can be used/referenced by those dbcs classes that might be moved into sun.nio.cs (5) to change some sun.nio.cs.ext implementation java files to be a .template, so the real .java can be generated during build-time with correct pkg name and aliases info. There are two leftover, gb18030 and euc_tw, these are two charsets with huge mapping table. Might need special update to better fit into sun.nio.cs later. thanks! -Sherman
Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses
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 I suspect that GCC and glibc already assume that unaligned accesses work so it would require a recompilation of libjvm (and probably the whole OS) to make it work. However, if you really think there's a point to making this a runtime flag I won't resist. Andrew. Even if linux-aarch64 always allows unaligned, checking only for aarch64 is not future-proof because it doesn't take the OS into account. However, I really don't like having to enumerate all relevant platforms in multiple places in shared code, so I disagree with the existing code and with perpetuating the pattern. As long as the decision is in platform-specific code, a build-time decision may be entirely appropriate. dl
Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses
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.
Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses
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 that unaligned accesses work so it would require a recompilation of libjvm (and probably the whole OS) to make it work. However, if you really think there's a point to making this a runtime flag I won't resist. Andrew.
