From github.com+76791+alblue at openjdk.java.net Fri Mar 19 13:11:45 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Fri, 19 Mar 2021 13:11:45 GMT Subject: jmx-dev RFR: 8263855: Use the blessed modifier order in java.management/naming In-Reply-To: References: Message-ID: On Thu, 18 Mar 2021 18:26:20 GMT, Alex Blewitt wrote: > As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules. Would someone mind creating a bug for me? In addition, if it would help, we could create a parent bug for applying cleanups and associate #2993 and #2991. ------------- PR: https://git.openjdk.java.net/jdk/pull/3078 From github.com+76791+alblue at openjdk.java.net Fri Mar 19 13:11:45 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Fri, 19 Mar 2021 13:11:45 GMT Subject: jmx-dev RFR: 8263855: Use the blessed modifier order in java.management/naming Message-ID: As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules. ------------- Commit messages: - Use the blessed modifier order in java.management/naming Changes: https://git.openjdk.java.net/jdk/pull/3078/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3078&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263855 Stats: 158 lines in 39 files changed: 0 ins; 0 del; 158 mod Patch: https://git.openjdk.java.net/jdk/pull/3078.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3078/head:pull/3078 PR: https://git.openjdk.java.net/jdk/pull/3078 From github.com+76791+alblue at openjdk.java.net Fri Mar 19 13:11:45 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Fri, 19 Mar 2021 13:11:45 GMT Subject: jmx-dev RFR: 8263855: Use the blessed modifier order in java.management/naming In-Reply-To: References: Message-ID: On Thu, 18 Mar 2021 19:33:59 GMT, Alex Blewitt wrote: >> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules. > > Would someone mind creating a bug for me? In addition, if it would help, we could create a parent bug for applying cleanups and associate #2993 and #2991. @cl4es would you mind creating a parent task of something like "Source code cleanups" and then another sub task for this change please? ------------- PR: https://git.openjdk.java.net/jdk/pull/3078 From redestad at openjdk.java.net Fri Mar 19 13:11:46 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 19 Mar 2021 13:11:46 GMT Subject: jmx-dev RFR: 8263855: Use the blessed modifier order in java.management/naming In-Reply-To: References: Message-ID: <7ty0ud28Z7ozfWLhyqFcrZV7kmDp43KHakhBjcu2FAU=.f56134f2-d2ea-46b7-85a8-4b965a904e1b@github.com> On Fri, 19 Mar 2021 10:20:39 GMT, Alex Blewitt wrote: >> Would someone mind creating a bug for me? In addition, if it would help, we could create a parent bug for applying cleanups and associate #2993 and #2991. > > @cl4es would you mind creating a parent task of something like "Source code cleanups" and then another sub task for this change please? Created the subtask https://bugs.openjdk.java.net/browse/JDK-8263855 for this along with an umbrella RFE. ------------- PR: https://git.openjdk.java.net/jdk/pull/3078 From github.com+76791+alblue at openjdk.java.net Fri Mar 19 13:11:46 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Fri, 19 Mar 2021 13:11:46 GMT Subject: jmx-dev RFR: 8263855: Use the blessed modifier order in java.management/naming In-Reply-To: <7ty0ud28Z7ozfWLhyqFcrZV7kmDp43KHakhBjcu2FAU=.f56134f2-d2ea-46b7-85a8-4b965a904e1b@github.com> References: <7ty0ud28Z7ozfWLhyqFcrZV7kmDp43KHakhBjcu2FAU=.f56134f2-d2ea-46b7-85a8-4b965a904e1b@github.com> Message-ID: On Fri, 19 Mar 2021 11:01:45 GMT, Claes Redestad wrote: >> @cl4es would you mind creating a parent task of something like "Source code cleanups" and then another sub task for this change please? > > Created the subtask https://bugs.openjdk.java.net/browse/JDK-8263855 for this along with an umbrella RFE. Thanks @cl4es -- do I need to update the git commit message as well, or is updating the title of the PR sufficient? I recall you suggesting not to do amend/rebases previously. ------------- PR: https://git.openjdk.java.net/jdk/pull/3078 From redestad at openjdk.java.net Fri Mar 19 13:30:39 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 19 Mar 2021 13:30:39 GMT Subject: jmx-dev RFR: 8263855: Use the blessed modifier order in java.management/naming In-Reply-To: References: <7ty0ud28Z7ozfWLhyqFcrZV7kmDp43KHakhBjcu2FAU=.f56134f2-d2ea-46b7-85a8-4b965a904e1b@github.com> Message-ID: On Fri, 19 Mar 2021 13:08:24 GMT, Alex Blewitt wrote: >> Created the subtask https://bugs.openjdk.java.net/browse/JDK-8263855 for this along with an umbrella RFE. > > Thanks @cl4es -- do I need to update the git commit message as well, or is updating the title of the PR sufficient? I recall you suggesting not to do amend/rebases previously. No, the git commit messages here doesn't matter, the bots will use the PR name when merging into master. It's good form to use reasonably consistent commit messages as you add commits to a PR, but altering commit history is not necessary and might even be disruptive once a PR has been opened. There's the /summary command you could use to add additional comments to the final commit, see https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/summary ------------- PR: https://git.openjdk.java.net/jdk/pull/3078 From github.com+76791+alblue at openjdk.java.net Fri Mar 19 13:34:46 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Fri, 19 Mar 2021 13:34:46 GMT Subject: jmx-dev RFR: 8263855: Use the blessed modifier order in java.management/naming In-Reply-To: References: <7ty0ud28Z7ozfWLhyqFcrZV7kmDp43KHakhBjcu2FAU=.f56134f2-d2ea-46b7-85a8-4b965a904e1b@github.com> Message-ID: On Fri, 19 Mar 2021 13:28:12 GMT, Claes Redestad wrote: >> Thanks @cl4es -- do I need to update the git commit message as well, or is updating the title of the PR sufficient? I recall you suggesting not to do amend/rebases previously. > > No, the git commit messages here doesn't matter, the bots will use the PR name when merging into master. It's good form to use reasonably consistent commit messages as you add commits to a PR, but altering commit history is not necessary and might even be disruptive once a PR has been opened. > > There's the /summary command you could use to add additional comments to the final commit, see https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/summary Thanks @cl4es will adjust my submissions appropriately in the future. ------------- PR: https://git.openjdk.java.net/jdk/pull/3078 From redestad at openjdk.java.net Fri Mar 19 14:13:40 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 19 Mar 2021 14:13:40 GMT Subject: jmx-dev RFR: 8263855: Use the blessed modifier order in java.management/naming In-Reply-To: References: Message-ID: On Thu, 18 Mar 2021 18:26:20 GMT, Alex Blewitt wrote: > As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules. Overall good - found a few cases where the private modifier is in the wrong place that ought to be fixed as well. src/java.naming/share/classes/com/sun/jndi/ldap/EventQueue.java line 48: > 46: */ > 47: final class EventQueue implements Runnable { > 48: static final private boolean debug = false; Move private to the front? src/java.naming/share/classes/com/sun/jndi/ldap/EventSupport.java line 116: > 114: */ > 115: final class EventSupport { > 116: static final private boolean debug = false; Move private to the front? src/java.naming/share/classes/com/sun/jndi/ldap/LdapSchemaCtx.java line 389: > 387: } > 388: > 389: static final private class SchemaInfo { Move private to the front? ------------- Changes requested by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3078 From github.com+76791+alblue at openjdk.java.net Fri Mar 19 17:13:58 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Fri, 19 Mar 2021 17:13:58 GMT Subject: jmx-dev RFR: 8263855: Use the blessed modifier order in java.management/naming [v2] In-Reply-To: References: Message-ID: <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com> > As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules. Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision: Added more replacements of 'final public' with 'public final' ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3078/files - new: https://git.openjdk.java.net/jdk/pull/3078/files/f1bc7269..1c900d2d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3078&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3078&range=00-01 Stats: 106 lines in 37 files changed: 0 ins; 0 del; 106 mod Patch: https://git.openjdk.java.net/jdk/pull/3078.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3078/head:pull/3078 PR: https://git.openjdk.java.net/jdk/pull/3078 From redestad at openjdk.java.net Fri Mar 19 18:02:41 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 19 Mar 2021 18:02:41 GMT Subject: jmx-dev RFR: 8263855: Use the blessed modifier order in java.management/naming [v2] In-Reply-To: <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com> References: <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com> Message-ID: On Fri, 19 Mar 2021 17:13:58 GMT, Alex Blewitt wrote: >> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules. > > Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision: > > Added more replacements of 'final public' with 'public final' Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3078 From aefimov at openjdk.java.net Mon Mar 22 12:16:40 2021 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Mon, 22 Mar 2021 12:16:40 GMT Subject: jmx-dev RFR: 8263855: Use the blessed modifier order in java.management/naming [v2] In-Reply-To: <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com> References: <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com> Message-ID: On Fri, 19 Mar 2021 17:13:58 GMT, Alex Blewitt wrote: >> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules. > > Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision: > > Added more replacements of 'final public' with 'public final' `java.naming` module changes look good to me. ------------- Marked as reviewed by aefimov (Committer). PR: https://git.openjdk.java.net/jdk/pull/3078 From dfuchs at openjdk.java.net Mon Mar 22 13:09:40 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 22 Mar 2021 13:09:40 GMT Subject: jmx-dev RFR: 8263855: Use the blessed modifier order in java.management/naming [v2] In-Reply-To: <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com> References: <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com> Message-ID: On Fri, 19 Mar 2021 17:13:58 GMT, Alex Blewitt wrote: >> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules. > > Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision: > > Added more replacements of 'final public' with 'public final' Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3078 From github.com+76791+alblue at openjdk.java.net Mon Mar 22 13:41:39 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Mon, 22 Mar 2021 13:41:39 GMT Subject: jmx-dev Integrated: 8263855: Use the blessed modifier order in java.management/naming In-Reply-To: References: Message-ID: On Thu, 18 Mar 2021 18:26:20 GMT, Alex Blewitt wrote: > As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules. This pull request has now been integrated. Changeset: 5262d95b Author: Alex Blewitt Committer: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/5262d95b Stats: 261 lines in 69 files changed: 0 ins; 0 del; 261 mod 8263855: Use the blessed modifier order in java.management/naming Reviewed-by: redestad, aefimov, dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/3078 From dfuchs at openjdk.java.net Thu Mar 25 17:37:49 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 25 Mar 2021 17:37:49 GMT Subject: jmx-dev RFR: 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records Message-ID: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> This RFE proposes to extend the MXBean framework to define a mapping to records. The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names. With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this: CompositeType( "NamedNumber", // typeName "NamedNumber", // description new String[] {"number", "name"}, // itemNames new String[] {"number", "name"}, // itemDescriptions new OpenType[] {SimpleType.INTEGER, SimpleType.STRING} // itemTypes ); The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation: public class NamedNumber { public int getNumber() {return number;} public String getName() {return name;} @ConstructorParameters({"number", "name"}) public NamedNumber(int number, String name) { this.number = number; this.name = name; } private final int number; private final String name; } And the equivalent with a record class: public record NamedNumber(int number, String name) {} ------------- Commit messages: - 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records Changes: https://git.openjdk.java.net/jdk/pull/3201/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264124 Stats: 679 lines in 3 files changed: 647 ins; 12 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/3201.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3201/head:pull/3201 PR: https://git.openjdk.java.net/jdk/pull/3201 From alanb at openjdk.java.net Fri Mar 26 14:47:25 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 26 Mar 2021 14:47:25 GMT Subject: jmx-dev RFR: 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records In-Reply-To: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> Message-ID: <-EtiIDRMVgkZHFkgQNRXOFTlrWolfgt_YJaOiidM2BM=.a023dd02-072f-4613-bcd9-3dc21cede688@github.com> On Thu, 25 Mar 2021 17:30:52 GMT, Daniel Fuchs wrote: > This RFE proposes to extend the MXBean framework to define a mapping to records. > > The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names. > > With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this: > > CompositeType( > "NamedNumber", // typeName > "NamedNumber", // description > new String[] {"number", "name"}, // itemNames > new String[] {"number", "name"}, // itemDescriptions > new OpenType[] {SimpleType.INTEGER, > SimpleType.STRING} // itemTypes > ); > > The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation: > > public class NamedNumber { > public int getNumber() {return number;} > public String getName() {return name;} > @ConstructorParameters({"number", "name"}) > public NamedNumber(int number, String name) { > this.number = number; > this.name = name; > } > private final int number; > private final String name; > } > > And the equivalent with a record class: > > public record NamedNumber(int number, String name) {} src/java.management/share/classes/javax/management/MXBean.java line 792: > 790: accessor for a record component {@code name} of type T, > 791: then the item in the {@code CompositeType} has the same name > 792: than the record component, and has type opentype(T).

The update to the MXBean spec looks good. Do you have a typo here, I assume it should say "as the record component". ------------- PR: https://git.openjdk.java.net/jdk/pull/3201 From dfuchs at openjdk.java.net Fri Mar 26 15:15:49 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 26 Mar 2021 15:15:49 GMT Subject: jmx-dev RFR: 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records [v2] In-Reply-To: <-EtiIDRMVgkZHFkgQNRXOFTlrWolfgt_YJaOiidM2BM=.a023dd02-072f-4613-bcd9-3dc21cede688@github.com> References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> <-EtiIDRMVgkZHFkgQNRXOFTlrWolfgt_YJaOiidM2BM=.a023dd02-072f-4613-bcd9-3dc21cede688@github.com> Message-ID: On Fri, 26 Mar 2021 14:45:05 GMT, Alan Bateman wrote: >> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed typo. Moved example with record after example with from method to respect the logical order of precedence. > > src/java.management/share/classes/javax/management/MXBean.java line 792: > >> 790: accessor for a record component {@code name} of type T, >> 791: then the item in the {@code CompositeType} has the same name >> 792: than the record component, and has type opentype(T).

> > The update to the MXBean spec looks good. Do you have a typo here, I assume it should say "as the record component". Right, thanks. Qualifying it as "a typo" was too kind ;-) I have updated the PR. I also moved the `record` example after the `from` example to respect the order of precedence. ------------- PR: https://git.openjdk.java.net/jdk/pull/3201 From dfuchs at openjdk.java.net Fri Mar 26 15:15:48 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 26 Mar 2021 15:15:48 GMT Subject: jmx-dev RFR: 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records [v2] In-Reply-To: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> Message-ID: > This RFE proposes to extend the MXBean framework to define a mapping to records. > > The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names. > > With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this: > > CompositeType( > "NamedNumber", // typeName > "NamedNumber", // description > new String[] {"number", "name"}, // itemNames > new String[] {"number", "name"}, // itemDescriptions > new OpenType[] {SimpleType.INTEGER, > SimpleType.STRING} // itemTypes > ); > > The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation: > > public class NamedNumber { > public int getNumber() {return number;} > public String getName() {return name;} > @ConstructorParameters({"number", "name"}) > public NamedNumber(int number, String name) { > this.number = number; > this.name = name; > } > private final int number; > private final String name; > } > > And the equivalent with a record class: > > public record NamedNumber(int number, String name) {} Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: Fixed typo. Moved example with record after example with from method to respect the logical order of precedence. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3201/files - new: https://git.openjdk.java.net/jdk/pull/3201/files/bf8b437f..1c3292ce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=00-01 Stats: 19 lines in 1 file changed: 9 ins; 9 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3201.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3201/head:pull/3201 PR: https://git.openjdk.java.net/jdk/pull/3201 From chegar at openjdk.java.net Fri Mar 26 17:09:27 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Fri, 26 Mar 2021 17:09:27 GMT Subject: jmx-dev RFR: 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records In-Reply-To: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> Message-ID: <4E-rd6ZdQdNUrnJ2qyEX1fqbowM_0KgcppdNzNc81Cc=.705d5233-bb66-474e-ad1e-7f4b5fa364c7@github.com> On Thu, 25 Mar 2021 17:30:52 GMT, Daniel Fuchs wrote: > This RFE proposes to extend the MXBean framework to define a mapping to records. > > The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names. > > With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this: > > CompositeType( > "NamedNumber", // typeName > "NamedNumber", // description > new String[] {"number", "name"}, // itemNames > new String[] {"number", "name"}, // itemDescriptions > new OpenType[] {SimpleType.INTEGER, > SimpleType.STRING} // itemTypes > ); > > The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation: > > public class NamedNumber { > public int getNumber() {return number;} > public String getName() {return name;} > @ConstructorParameters({"number", "name"}) > public NamedNumber(int number, String name) { > this.number = number; > this.name = name; > } > private final int number; > private final String name; > } > > And the equivalent with a record class: > > public record NamedNumber(int number, String name) {} Generally, I think that this is a good change. It nice to see that the semantics of record classes can be leverage to build the CompositeType in this way. And equally how that maps back to the canonical constructor. ------------- PR: https://git.openjdk.java.net/jdk/pull/3201 From mchung at openjdk.java.net Sat Mar 27 01:52:27 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Sat, 27 Mar 2021 01:52:27 GMT Subject: jmx-dev RFR: 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records [v2] In-Reply-To: References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> Message-ID: On Fri, 26 Mar 2021 15:15:48 GMT, Daniel Fuchs wrote: >> This RFE proposes to extend the MXBean framework to define a mapping to records. >> >> The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names. >> >> With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this: >> >> CompositeType( >> "NamedNumber", // typeName >> "NamedNumber", // description >> new String[] {"number", "name"}, // itemNames >> new String[] {"number", "name"}, // itemDescriptions >> new OpenType[] {SimpleType.INTEGER, >> SimpleType.STRING} // itemTypes >> ); >> >> The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation: >> >> public class NamedNumber { >> public int getNumber() {return number;} >> public String getName() {return name;} >> @ConstructorParameters({"number", "name"}) >> public NamedNumber(int number, String name) { >> this.number = number; >> this.name = name; >> } >> private final int number; >> private final String name; >> } >> >> And the equivalent with a record class: >> >> public record NamedNumber(int number, String name) {} > > Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: > > Fixed typo. Moved example with record after example with from method to respect the logical order of precedence. src/java.management/share/classes/javax/management/MXBean.java line 757: > 755: > 756:

If the class is a {@link Record}, its getters are the > 757: accessors for the record components. Otherwise, the It may be good to add a link like {@linkplain RecordComponent record components} ------------- PR: https://git.openjdk.java.net/jdk/pull/3201 From mchung at openjdk.java.net Sat Mar 27 01:52:28 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Sat, 27 Mar 2021 01:52:28 GMT Subject: jmx-dev RFR: 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records [v2] In-Reply-To: References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> Message-ID: <0RxhjEDdg8ZZRNLjbknHs_sa71hn6ax3LAtv_-pZGqY=.a3e1631a-4280-4b2e-95c0-794785b9d165@github.com> On Sat, 27 Mar 2021 01:40:17 GMT, Mandy Chung wrote: >> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed typo. Moved example with record after example with from method to respect the logical order of precedence. > > src/java.management/share/classes/javax/management/MXBean.java line 757: > >> 755: >> 756:

If the class is a {@link Record}, its getters are the >> 757: accessors for the record components. Otherwise, the > > It may be good to add a link like {@linkplain RecordComponent record components} You add record in "Mappings for other types". I think it deserves a separate section "Mappings for record classes" (maybe after primitive types). It's useful to add a row for record in the summary table above "Mappings for primitive types" ------------- PR: https://git.openjdk.java.net/jdk/pull/3201 From iklam at openjdk.java.net Mon Mar 29 21:47:02 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 29 Mar 2021 21:47:02 GMT Subject: jmx-dev RFR: 8264285: Clean the modification of ccstr JVM flags Message-ID: There are two versions of JVMFlagAccess::ccstrAtPut() for modifying JVM flags of the ccstr type (i.e., strings). - One version requires the caller to free the old value, but some callers don't do that (writeableFlags.cpp). - The other version frees the old value on behalf of the caller. However, this version is accessible only via FLAG_SET_XXX macros and is currently unused. So it's unclear whether it actually works. We should combine these two versions into a single function, fix problems in the callers, and add test cases. The old value should be freed automatically, because typically the caller isn't interested in the old value. Note that the FLAG_SET_XXX macros do not return the old value. Requiring the caller of FLAG_SET_XXX to free the old value would be tedious and error prone. ------------- Commit messages: - restored SET_FLAG_XXX for ccstr type, and fixed bugs in existing ccstr modification code - 8264285: Do not support FLAG_SET_XXX for VM flags of string type Changes: https://git.openjdk.java.net/jdk/pull/3254/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3254&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264285 Stats: 205 lines in 9 files changed: 160 ins; 24 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/3254.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3254/head:pull/3254 PR: https://git.openjdk.java.net/jdk/pull/3254 From dfuchs at openjdk.java.net Mon Mar 29 22:15:47 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 29 Mar 2021 22:15:47 GMT Subject: jmx-dev RFR: 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records [v2] In-Reply-To: <0RxhjEDdg8ZZRNLjbknHs_sa71hn6ax3LAtv_-pZGqY=.a3e1631a-4280-4b2e-95c0-794785b9d165@github.com> References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> <0RxhjEDdg8ZZRNLjbknHs_sa71hn6ax3LAtv_-pZGqY=.a3e1631a-4280-4b2e-95c0-794785b9d165@github.com> Message-ID: On Sat, 27 Mar 2021 01:49:38 GMT, Mandy Chung wrote: >> src/java.management/share/classes/javax/management/MXBean.java line 757: >> >>> 755: >>> 756:

If the class is a {@link Record}, its getters are the >>> 757: accessors for the record components. Otherwise, the >> >> It may be good to add a link like {@linkplain RecordComponent record components} > > You add record in "Mappings for other types". I think it deserves a separate section "Mappings for record classes" (maybe after primitive types). It's useful to add a row for record in the summary table above "Mappings for primitive types" Link added. With respect to adding a section for records, it's a bit difficult to separate that from the "Mapping for other types" without a lot of duplication. I can add a row in the summary table, and then add a new section "Mapping for records" just before "Mapping for other types", that just gives a brief overview and refers to the mapping for other types below. Something like this - what do you think?

Mappings for Records

A {@linkplain Record record} R whose {@linkplain Class#getRecordComponents() components} are all convertible to open types, is itself convertible to a {@link CompositeType} as follows. The type name of this {@code CompositeType} is determined by the same type name rules defined by the Mapping for other types below. Its getters are the accessors for the {@linkplain RecordComponent record components}, and the record is reconstructed using its canonical constructor, without needing any annotation.

A record may also expose additional non-canonical constructors, which can be used to reconstruct the record if the composite data does not exactly contain all the components expected by the canonical constructor. However, in order to be taken into account by the MXBean framework, such non-canonical constructors need to be annotated with either the {@link ConstructorParameters @javax.management.ConstructorParameters} or {@code @java.beans.ConstructorProperties} annotation.

The complete rules for the mapping are detailed as part of the Mapping for other types below.

Mappings for other types

Given a record, or a Java class or interface J that does not match the other rules in the table above, the MXBean framework will attempt to map it to a {@link CompositeType} as follows. [....] ------------- PR: https://git.openjdk.java.net/jdk/pull/3201 From dholmes at openjdk.java.net Tue Mar 30 03:51:43 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 30 Mar 2021 03:51:43 GMT Subject: jmx-dev RFR: 8264285: Clean the modification of ccstr JVM flags In-Reply-To: References: Message-ID: <71SWS17lpVrTS_4--6mimeyjCYjYzP_VO_lJ-rImnxg=.a75340ae-d17e-4f0d-8868-21d4449d64f6@github.com> On Mon, 29 Mar 2021 21:35:52 GMT, Ioi Lam wrote: > There are two versions of JVMFlagAccess::ccstrAtPut() for modifying JVM flags of the ccstr type (i.e., strings). > > - One version requires the caller to free the old value, but some callers don't do that (writeableFlags.cpp). > - The other version frees the old value on behalf of the caller. However, this version is accessible only via FLAG_SET_XXX macros and is currently unused. So it's unclear whether it actually works. > > We should combine these two versions into a single function, fix problems in the callers, and add test cases. The old value should be freed automatically, because typically the caller isn't interested in the old value. > > Note that the FLAG_SET_XXX macros do not return the old value. Requiring the caller of FLAG_SET_XXX to free the old value would be tedious and error prone. Hi Ioi, This looks good to me. Thanks for fixing it up. One minor nit below. Thanks, David src/hotspot/share/services/writeableFlags.cpp line 250: > 248: if (err == JVMFlag::SUCCESS) { > 249: assert(value == NULL, "old value is freed automatically and not returned"); > 250: } The whole block should be ifdef DEBUG. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3254 From coleenp at openjdk.java.net Wed Mar 31 13:02:23 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 31 Mar 2021 13:02:23 GMT Subject: jmx-dev RFR: 8264285: Clean the modification of ccstr JVM flags In-Reply-To: References: Message-ID: On Mon, 29 Mar 2021 21:35:52 GMT, Ioi Lam wrote: > There are two versions of JVMFlagAccess::ccstrAtPut() for modifying JVM flags of the ccstr type (i.e., strings). > > - One version requires the caller to free the old value, but some callers don't do that (writeableFlags.cpp). > - The other version frees the old value on behalf of the caller. However, this version is accessible only via FLAG_SET_XXX macros and is currently unused. So it's unclear whether it actually works. > > We should combine these two versions into a single function, fix problems in the callers, and add test cases. The old value should be freed automatically, because typically the caller isn't interested in the old value. > > Note that the FLAG_SET_XXX macros do not return the old value. Requiring the caller of FLAG_SET_XXX to free the old value would be tedious and error prone. I had a question but overall nice cleanup! src/hotspot/share/runtime/flags/debug_globals.hpp line 38: > 36: // have any MANAGEABLE flags of the ccstr type, but we really need to > 37: // make sure the implementation is correct (in terms of memory allocation) > 38: // just in case someone may add such a flag in the future. Could you have just added a develop flag to the manageable flags instead? src/hotspot/share/runtime/flags/jvmFlagAccess.cpp line 327: > 325: // The callers typically don't care what the old value is. > 326: // If the caller really wants to know the old value, read it (and make a copy if necessary) > 327: // before calling this API. good comment! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3254 From dfuchs at openjdk.java.net Wed Mar 31 15:35:53 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 31 Mar 2021 15:35:53 GMT Subject: jmx-dev RFR: 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records [v3] In-Reply-To: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> Message-ID: <2mt02-hwVOJDUEygnx0n3fs5qRu_cRXdqsrSPwyO4Wg=.d64c3751-290f-4506-9ba0-d5c7fc325d59@github.com> > This RFE proposes to extend the MXBean framework to define a mapping to records. > > The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names. > > With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this: > > CompositeType( > "NamedNumber", // typeName > "NamedNumber", // description > new String[] {"number", "name"}, // itemNames > new String[] {"number", "name"}, // itemDescriptions > new OpenType[] {SimpleType.INTEGER, > SimpleType.STRING} // itemTypes > ); > > The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation: > > public class NamedNumber { > public int getNumber() {return number;} > public String getName() {return name;} > @ConstructorParameters({"number", "name"}) > public NamedNumber(int number, String name) { > this.number = number; > this.name = name; > } > private final int number; > private final String name; > } > > And the equivalent with a record class: > > public record NamedNumber(int number, String name) {} Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge branch 'master' into mxbeans-8264124 - Minor tweaks. Improved test. - Merge branch 'master' into mxbeans-8264124 - Integrated review feedback. Updated the section for Mapping to records. - Integrated review feedback. Added a section for Mapping to records. - Fixed typo. Moved example with record after example with from method to respect the logical order of precedence. - 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3201/files - new: https://git.openjdk.java.net/jdk/pull/3201/files/1c3292ce..59965133 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=01-02 Stats: 15001 lines in 575 files changed: 11278 ins; 1193 del; 2530 mod Patch: https://git.openjdk.java.net/jdk/pull/3201.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3201/head:pull/3201 PR: https://git.openjdk.java.net/jdk/pull/3201 From dfuchs at openjdk.java.net Wed Mar 31 15:41:19 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 31 Mar 2021 15:41:19 GMT Subject: jmx-dev RFR: 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records [v2] In-Reply-To: References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> <0RxhjEDdg8ZZRNLjbknHs_sa71hn6ax3LAtv_-pZGqY=.a3e1631a-4280-4b2e-95c0-794785b9d165@github.com> Message-ID: On Mon, 29 Mar 2021 22:12:01 GMT, Daniel Fuchs wrote: >> You add record in "Mappings for other types". I think it deserves a separate section "Mappings for record classes" (maybe after primitive types). It's useful to add a row for record in the summary table above "Mappings for primitive types" > > Link added. With respect to adding a section for records, it's a bit difficult to separate that from the "Mapping for other types" without a lot of duplication. I can add a row in the summary table, and then add a new section "Mapping for records" just before "Mapping for other types", that just gives a brief overview and refers to the mapping for other types below. > > Something like this - what do you think? > >

Mappings for Records

> >

A {@linkplain Record record} R whose {@linkplain > Class#getRecordComponents() components} are > all convertible to open types, is itself convertible to a > {@link CompositeType} as follows. > The type name of this {@code CompositeType} > is determined by the same type name rules > defined by the Mapping for other types > below. Its getters are the accessors for the {@linkplain > RecordComponent record components}, and the record is reconstructed > using its canonical constructor, without needing any annotation.

> >

A record may also expose additional non-canonical constructors, which > can be used to reconstruct the record if the composite data does > not exactly contain all the components expected by the > canonical constructor. However, in order to be taken into account > by the MXBean framework, such non-canonical constructors > need to be annotated with either the {@link ConstructorParameters > @javax.management.ConstructorParameters} or > {@code @java.beans.ConstructorProperties} annotation.

> >

The complete rules for the mapping are detailed as part > of the Mapping for other types > below.

> >

Mappings for other types

> >

Given a record, or a Java class or interface J that does not match the other > rules in the table above, the MXBean framework will attempt to map > it to a {@link CompositeType} as follows. [....] Hi Mandy, I have updated the PR with a revised version of the text above. Is that more in line what you had in mind? best regards, -- daniel ------------- PR: https://git.openjdk.java.net/jdk/pull/3201 From dfuchs at openjdk.java.net Wed Mar 31 17:46:40 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 31 Mar 2021 17:46:40 GMT Subject: jmx-dev RFR: 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records [v4] In-Reply-To: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> Message-ID: > This RFE proposes to extend the MXBean framework to define a mapping to records. > > The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names. > > With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this: > > CompositeType( > "NamedNumber", // typeName > "NamedNumber", // description > new String[] {"number", "name"}, // itemNames > new String[] {"number", "name"}, // itemDescriptions > new OpenType[] {SimpleType.INTEGER, > SimpleType.STRING} // itemTypes > ); > > The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation: > > public class NamedNumber { > public int getNumber() {return number;} > public String getName() {return name;} > @ConstructorParameters({"number", "name"}) > public NamedNumber(int number, String name) { > this.number = number; > this.name = name; > } > private final int number; > private final String name; > } > > And the equivalent with a record class: > > public record NamedNumber(int number, String name) {} Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: Moved mapping for records just before Mapping for MXBean interface; Improved test. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3201/files - new: https://git.openjdk.java.net/jdk/pull/3201/files/59965133..7d478dec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=02-03 Stats: 127 lines in 2 files changed: 81 ins; 44 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3201.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3201/head:pull/3201 PR: https://git.openjdk.java.net/jdk/pull/3201 From mchung at openjdk.java.net Wed Mar 31 18:35:16 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 31 Mar 2021 18:35:16 GMT Subject: jmx-dev RFR: 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records [v2] In-Reply-To: References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> <0RxhjEDdg8ZZRNLjbknHs_sa71hn6ax3LAtv_-pZGqY=.a3e1631a-4280-4b2e-95c0-794785b9d165@github.com> Message-ID: <6QvyGXdDKhrOjFZ0GuVsiig5fp5Mo1cCjuI3UvshX20=.dc5fa768-f6e7-4066-a51c-8c21b51b531b@github.com> On Wed, 31 Mar 2021 15:38:22 GMT, Daniel Fuchs wrote: >> Link added. With respect to adding a section for records, it's a bit difficult to separate that from the "Mapping for other types" without a lot of duplication. I can add a row in the summary table, and then add a new section "Mapping for records" just before "Mapping for other types", that just gives a brief overview and refers to the mapping for other types below. >> >> Something like this - what do you think? >> >>

Mappings for Records

>> >>

A {@linkplain Record record} R whose {@linkplain >> Class#getRecordComponents() components} are >> all convertible to open types, is itself convertible to a >> {@link CompositeType} as follows. >> The type name of this {@code CompositeType} >> is determined by the same type name rules >> defined by the Mapping for other types >> below. Its getters are the accessors for the {@linkplain >> RecordComponent record components}, and the record is reconstructed >> using its canonical constructor, without needing any annotation.

>> >>

A record may also expose additional non-canonical constructors, which >> can be used to reconstruct the record if the composite data does >> not exactly contain all the components expected by the >> canonical constructor. However, in order to be taken into account >> by the MXBean framework, such non-canonical constructors >> need to be annotated with either the {@link ConstructorParameters >> @javax.management.ConstructorParameters} or >> {@code @java.beans.ConstructorProperties} annotation.

>> >>

The complete rules for the mapping are detailed as part >> of the Mapping for other types >> below.

>> >>

Mappings for other types

>> >>

Given a record, or a Java class or interface J that does not match the other >> rules in the table above, the MXBean framework will attempt to map >> it to a {@link CompositeType} as follows. [....] > > Hi Mandy, I have updated the PR with a revised version of the text above. Is that more in line what you had in mind? > > best regards, > -- daniel This looks better. I like a separate mapping section for records since the mapping rules are straight-forward. The complexity comes if we want to support a record to implement `CompositeDataView` that allows a type to support more flexible conversion to `CompositeData` which is why you add records in the "Mappings for other types". I am wondering if we really want to support records to implement `CompositeDataView` but we may want to avoid such a special case. I suggest add subsections in "Mappings for other types": There are two mapping rules: (1) _opentype(J)_ maps `J` to `CompositeType` (2) _opendata(J)_ maps `J` to `CompositeData`. _opentype(J)_ for record class does not need to refer to other types. The common cases for _opendata(J)_ for record class is using the canonical constructors. The other less common cases like using non-canonical constructors and `CompositeDataView` can state that it follows the same rules as specified for other types. "Mappings for other types" does not need any change for records. "Reconstructing an instance of Java type J from a CompositeData" section should be renamed to "Reconstructing an instance of Java type or record class J from a CompositeData" Here is a minor tweaking on "Mappings for Records" A record is convertible to a CompositeType if and only if all its components are convertible to open types. Otherwise, it is not convertible. A record class is converted to a CompositeType with one item for every record component as follows. - The type name of this CompositeType is determined by the type name rules detailed below. - Each record component of type T, the item in the CompositeType has the same name as the record component and of type opentype(T). The mapping from an instance of a record class to a CompositeData corresponding to the CompositeType is the same as specified as for other types (add a link). A record is reconstructed from a CompositeData using its canonical constructor. The canonical constructor doesn't require the presence of @javax.management.ConstructorParameters or @java.beans.ConstructorProperties annotations. If these annotations are present on the canonical constructor, they will be ignored. If the CompositeData from which the record is reconstructed doesn't contain all the record components, the MXBean framework will attempt to reconstruct the record in the same way as specified for other types (add a link). ------------- PR: https://git.openjdk.java.net/jdk/pull/3201 From iklam at openjdk.java.net Wed Mar 31 19:01:48 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 31 Mar 2021 19:01:48 GMT Subject: jmx-dev RFR: 8264285: Clean the modification of ccstr JVM flags [v2] In-Reply-To: References: Message-ID: > There are two versions of JVMFlagAccess::ccstrAtPut() for modifying JVM flags of the ccstr type (i.e., strings). > > - One version requires the caller to free the old value, but some callers don't do that (writeableFlags.cpp). > - The other version frees the old value on behalf of the caller. However, this version is accessible only via FLAG_SET_XXX macros and is currently unused. So it's unclear whether it actually works. > > We should combine these two versions into a single function, fix problems in the callers, and add test cases. The old value should be freed automatically, because typically the caller isn't interested in the old value. > > Note that the FLAG_SET_XXX macros do not return the old value. Requiring the caller of FLAG_SET_XXX to free the old value would be tedious and error prone. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: relax flag attributions (ala JDK-7123237) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3254/files - new: https://git.openjdk.java.net/jdk/pull/3254/files/7eca2343..673aaafc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3254&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3254&range=00-01 Stats: 37 lines in 4 files changed: 0 ins; 36 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3254.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3254/head:pull/3254 PR: https://git.openjdk.java.net/jdk/pull/3254 From iklam at openjdk.java.net Wed Mar 31 19:05:14 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 31 Mar 2021 19:05:14 GMT Subject: jmx-dev RFR: 8264285: Clean the modification of ccstr JVM flags [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 12:58:50 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> relax flag attributions (ala JDK-7123237) > > src/hotspot/share/runtime/flags/debug_globals.hpp line 38: > >> 36: // have any MANAGEABLE flags of the ccstr type, but we really need to >> 37: // make sure the implementation is correct (in terms of memory allocation) >> 38: // just in case someone may add such a flag in the future. > > Could you have just added a develop flag to the manageable flags instead? I had to use a `product` flag due to the following code, which should have been removed as part of [JDK-8243208](https://bugs.openjdk.java.net/browse/JDK-8243208), but I was afraid to do so because I didn't have a test case. I.e., all of our diagnostic/manageable/experimental flags were `product` flags. With this PR, now I have a test case -- I changed `DummyManageableStringFlag` to a `notproduct` flag, and removed the following code. I am re-running tiers1-4 now. void JVMFlag::check_all_flag_declarations() { for (JVMFlag* current = &flagTable[0]; current->_name != NULL; current++) { int flags = static_cast(current->_flags); // Backwards compatibility. This will be relaxed/removed in JDK-7123237. int mask = JVMFlag::KIND_DIAGNOSTIC | JVMFlag::KIND_MANAGEABLE | JVMFlag::KIND_EXPERIMENTAL; if ((flags & mask) != 0) { assert((flags & mask) == JVMFlag::KIND_DIAGNOSTIC || (flags & mask) == JVMFlag::KIND_MANAGEABLE || (flags & mask) == JVMFlag::KIND_EXPERIMENTAL, "%s can be declared with at most one of " "DIAGNOSTIC, MANAGEABLE or EXPERIMENTAL", current->_name); assert((flags & KIND_NOT_PRODUCT) == 0 && (flags & KIND_DEVELOP) == 0, "%s has an optional DIAGNOSTIC, MANAGEABLE or EXPERIMENTAL " "attribute; it must be declared as a product flag", current->_name); } } } ------------- PR: https://git.openjdk.java.net/jdk/pull/3254 From dfuchs at openjdk.java.net Wed Mar 31 20:56:32 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 31 Mar 2021 20:56:32 GMT Subject: jmx-dev RFR: 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records [v5] In-Reply-To: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> Message-ID: > This RFE proposes to extend the MXBean framework to define a mapping to records. > > The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names. > > With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this: > > CompositeType( > "NamedNumber", // typeName > "NamedNumber", // description > new String[] {"number", "name"}, // itemNames > new String[] {"number", "name"}, // itemDescriptions > new OpenType[] {SimpleType.INTEGER, > SimpleType.STRING} // itemTypes > ); > > The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation: > > public class NamedNumber { > public int getNumber() {return number;} > public String getName() {return name;} > @ConstructorParameters({"number", "name"}) > public NamedNumber(int number, String name) { > this.number = number; > this.name = name; > } > private final int number; > private final String name; > } > > And the equivalent with a record class: > > public record NamedNumber(int number, String name) {} Daniel Fuchs has updated the pull request incrementally with two additional commits since the last revision: - Integrated review feedback - Improved test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3201/files - new: https://git.openjdk.java.net/jdk/pull/3201/files/7d478dec..9227ba58 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=03-04 Stats: 114 lines in 2 files changed: 53 ins; 13 del; 48 mod Patch: https://git.openjdk.java.net/jdk/pull/3201.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3201/head:pull/3201 PR: https://git.openjdk.java.net/jdk/pull/3201 From dfuchs at openjdk.java.net Wed Mar 31 20:56:32 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 31 Mar 2021 20:56:32 GMT Subject: jmx-dev RFR: 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records [v2] In-Reply-To: <6QvyGXdDKhrOjFZ0GuVsiig5fp5Mo1cCjuI3UvshX20=.dc5fa768-f6e7-4066-a51c-8c21b51b531b@github.com> References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> <0RxhjEDdg8ZZRNLjbknHs_sa71hn6ax3LAtv_-pZGqY=.a3e1631a-4280-4b2e-95c0-794785b9d165@github.com> <6QvyGXdDKhrOjFZ0GuVsiig5fp5Mo1cCjuI3UvshX20=.dc5fa768-f6e7-4066-a51c-8c21b51b531b@github.com> Message-ID: On Wed, 31 Mar 2021 18:32:31 GMT, Mandy Chung wrote: >> Hi Mandy, I have updated the PR with a revised version of the text above. Is that more in line what you had in mind? >> >> best regards, >> -- daniel > > This looks better. I like a separate mapping section for records since the mapping rules are straight-forward. The complexity comes if we want to support a record to implement `CompositeDataView` that allows a type to support more flexible conversion to `CompositeData` which is why you add records in the "Mappings for other types". I am wondering if we really want to support records to implement `CompositeDataView` but we may want to avoid such a special case. > > I suggest add subsections in "Mappings for other types": There are two mapping rules: (1) _opentype(J)_ maps `J` to `CompositeType` (2) _opendata(J)_ maps `J` to `CompositeData`. _opentype(J)_ for record class does not need to refer to other types. The common cases for _opendata(J)_ for record class is using the canonical constructors. The other less common cases like using non-canonical constructors and `CompositeDataView` can state that it follows the same rules as specified for other types. "Mappings for other types" does not need any change for records. > > "Reconstructing an instance of Java type J from a CompositeData" section should be renamed to "Reconstructing an instance of Java type or record class J from a CompositeData" > > Here is a minor tweaking on "Mappings for Records" > > A record is convertible to a CompositeType if and only if all its components are > convertible to open types. Otherwise, it is not convertible. > > A record class is converted to a CompositeType with one item for every record component as follows. > - The type name of this CompositeType is determined by the type name rules detailed below. > - Each record component of type T, the item in the CompositeType has the same name > as the record component and of type opentype(T). > > The mapping from an instance of a record class to a CompositeData corresponding to > the CompositeType is the same as specified as for other types (add a link). > > A record is reconstructed from a CompositeData using its canonical constructor. > The canonical constructor doesn't require the presence of @javax.management.ConstructorParameters > or @java.beans.ConstructorProperties annotations. If these annotations are present on > the canonical constructor, they will be ignored. > > If the CompositeData from which the record is reconstructed doesn't contain all the record components, > the MXBean framework will attempt to reconstruct the record in the same way as specified for > other types (add a link). I have updated the PR with those changes, plus a few minor adjustments. ------------- PR: https://git.openjdk.java.net/jdk/pull/3201 From dfuchs at openjdk.java.net Wed Mar 31 21:02:51 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 31 Mar 2021 21:02:51 GMT Subject: jmx-dev RFR: 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records [v6] In-Reply-To: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> Message-ID: <-HFZga_QfdbwjZcwnYCmvWjaXEACUzdW3fd6D6BhX6I=.38ba198b-70e4-4682-a7f4-13965bb47162@github.com> > This RFE proposes to extend the MXBean framework to define a mapping to records. > > The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names. > > With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this: > > CompositeType( > "NamedNumber", // typeName > "NamedNumber", // description > new String[] {"number", "name"}, // itemNames > new String[] {"number", "name"}, // itemDescriptions > new OpenType[] {SimpleType.INTEGER, > SimpleType.STRING} // itemTypes > ); > > The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation: > > public class NamedNumber { > public int getNumber() {return number;} > public String getName() {return name;} > @ConstructorParameters({"number", "name"}) > public NamedNumber(int number, String name) { > this.number = number; > this.name = name; > } > private final int number; > private final String name; > } > > And the equivalent with a record class: > > public record NamedNumber(int number, String name) {} Daniel Fuchs has updated the pull request incrementally with two additional commits since the last revision: - minor style issue - minor style issue ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3201/files - new: https://git.openjdk.java.net/jdk/pull/3201/files/9227ba58..a624a763 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3201&range=04-05 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3201.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3201/head:pull/3201 PR: https://git.openjdk.java.net/jdk/pull/3201 From mchung at openjdk.java.net Wed Mar 31 21:47:08 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 31 Mar 2021 21:47:08 GMT Subject: jmx-dev RFR: 8264124: Update MXBean specification and implementation to extend mapping of CompositeType to records [v6] In-Reply-To: <-HFZga_QfdbwjZcwnYCmvWjaXEACUzdW3fd6D6BhX6I=.38ba198b-70e4-4682-a7f4-13965bb47162@github.com> References: <7Oco_BzQDkrrNFy6FRoUFAUx5IuHu9YtuEfNuLverUI=.b57d8a09-8b39-4db1-a439-57285dedb7f7@github.com> <-HFZga_QfdbwjZcwnYCmvWjaXEACUzdW3fd6D6BhX6I=.38ba198b-70e4-4682-a7f4-13965bb47162@github.com> Message-ID: On Wed, 31 Mar 2021 21:02:51 GMT, Daniel Fuchs wrote: >> This RFE proposes to extend the MXBean framework to define a mapping to records. >> >> The MXBean framework already defines a mapping of `CompositeType` to plain java objects. Records are a natural representation of CompositeTypes. A record can be easily reconstructed from a `CompositeData` through the record canonical constructor. A clear advantage of records over plain java objects is that the canonical constructor will not need to be annotated in order to map composite data property names to constructor parameter names. >> >> With this RFE, here is an example comparing coding a composite type `NamedNumber` that consists of an `int` and a `String`, using records and using a plain java class. In both case, the `CompositeType` looks like this: >> >> CompositeType( >> "NamedNumber", // typeName >> "NamedNumber", // description >> new String[] {"number", "name"}, // itemNames >> new String[] {"number", "name"}, // itemDescriptions >> new OpenType[] {SimpleType.INTEGER, >> SimpleType.STRING} // itemTypes >> ); >> >> The plain Java class needs a public constructor annotated with `@ConstructorParameters` annotation: >> >> public class NamedNumber { >> public int getNumber() {return number;} >> public String getName() {return name;} >> @ConstructorParameters({"number", "name"}) >> public NamedNumber(int number, String name) { >> this.number = number; >> this.name = name; >> } >> private final int number; >> private final String name; >> } >> >> And the equivalent with a record class: >> >> public record NamedNumber(int number, String name) {} > > Daniel Fuchs has updated the pull request incrementally with two additional commits since the last revision: > > - minor style issue > - minor style issue Thanks for making the change. The spec change looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/3201 From iklam at openjdk.java.net Wed Mar 31 22:53:29 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 31 Mar 2021 22:53:29 GMT Subject: jmx-dev RFR: 8264285: Clean the modification of ccstr JVM flags [v2] In-Reply-To: <71SWS17lpVrTS_4--6mimeyjCYjYzP_VO_lJ-rImnxg=.a75340ae-d17e-4f0d-8868-21d4449d64f6@github.com> References: <71SWS17lpVrTS_4--6mimeyjCYjYzP_VO_lJ-rImnxg=.a75340ae-d17e-4f0d-8868-21d4449d64f6@github.com> Message-ID: On Tue, 30 Mar 2021 03:44:26 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> relax flag attributions (ala JDK-7123237) > > src/hotspot/share/services/writeableFlags.cpp line 250: > >> 248: if (err == JVMFlag::SUCCESS) { >> 249: assert(value == NULL, "old value is freed automatically and not returned"); >> 250: } > > The whole block should be ifdef DEBUG. Since this whole block can be optimized out by the C compiler in product builds, I'd rather leave out the `#ifdef` to avoid clutter. ------------- PR: https://git.openjdk.java.net/jdk/pull/3254