From liangchenblue at gmail.com Thu Jun 1 00:32:23 2023 From: liangchenblue at gmail.com (-) Date: Thu, 1 Jun 2023 08:32:23 +0800 Subject: ClassHierarchyResolver changes for the Classfile object In-Reply-To: References: Message-ID: The doPrivileged is from Mandy Chung's modification to my patch of reimplementation of MethodHandleProxies.asInterfaceInstance. It allows system code to fetch from system classloader with security manager, but I can just leave this change to be part of that patch instead. On Thu, Jun 1, 2023, 1:34 AM Adam Sotona wrote: > > > > > *From: *classfile-api-dev on behalf > of liangchenblue at gmail.com > *Date: *Wednesday, 31 May 2023 8:26 > *To: *classfile-api-dev > *Subject: *ClassHierarchyResolver changes for the Classfile object > > Hello, > Since we are migrating to the Classfile object (8308899), which was > initiated by our observation that Class hierarchy resolvers shouldn't > always cache their results, I wonder what changes I should adapt to my > current patch (8304425, PR #13082). > > We have already decided a few API changes for the resolver: > 1. Remove the default hierarchy resolver (at least change to static > factories), caching is bound to Classfile lifetime > > Yes, but we need to check performance impact on existing use cases (where > to extra hold Classfile instance with cache). > > > > > > 2. Two new resolver factories: Bytecode/resource parsing and > classloading/reflection from a given classloader (The goal of this > patch) > > > > Yes. > > > 3. The resolution result ClassHierarchyInfo will be converted into an > interface; record is an implementation detail (TBD) > > > > This can go even further. To save footprint ClassHierarchyInfo does not > need to expose anything, it does not need to carry thisClass and all > interface infos can point to a singleton object, something like this: > > /** > > * *Information* *about* *a* *resolved* *class* *or* *interface.* > > */ > > sealed interface *ClassHierarchyInfo* > > permits ClassHierarchyImpl.*ClassHierarchyInfoImpl* { > > > > /** > > * {*@return* the {*@link* ClassHierarchyInfo} of an interface} > > * no other information about interface is required > > */ > > static *ClassHierarchyInfo* *ofInterface*() { > > return ClassHierarchyImpl.*INTERFACE_INFO_INSTANCE*; > > } > > > > /** > > * *@return* the {*@link* ClassHierarchyInfo} of an interface > > * *@param* superClass information about super of the class is > required > > */ > > static *ClassHierarchyInfo* *ofClass*(ClassDesc superClass) { > > return new > ClassHierarchyImpl.ClassHierarchyInfoImpl(superClass); > > } > > } > > > > What should I do with my patch? Should I drop the changes to default > resolver (which adds security manager suppression) and move on with > the current content, or should I expand it to address all 3 planned > changes (despite some of them still in drafting phase) and accomodate > to the Classfile object? (We still have to decide about the default > resolver fo a Classfile object, esp. whether to have one or not) > > > > I?m not sure why the default class hierarchy resolver should call > AccessController.doPrivileged? > > > > > Thanks, > > Adam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Thu Jun 1 00:47:25 2023 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 31 May 2023 17:47:25 -0700 Subject: ClassHierarchyResolver changes for the Classfile object In-Reply-To: References:

Message-ID: <844f92d4-970a-ed1c-cdc9-b84da4115909@oracle.com> It's a question to the ClassHierarchyResolver interaction with the security manager.?? Although it's deprecated for removal, we still need to consider when it's installed and whether the API would throw SecurityException due to the security permission check or the implementation is safe to use the system class loader loading resources with privilege. Mandy On 5/31/23 5:32 PM, - wrote: > The doPrivileged is from Mandy Chung's modification to my patch of > reimplementation of MethodHandleProxies.asInterfaceInstance. It allows > system code to fetch from system classloader with security manager, > but I can just leave this change to be part of that patch instead. > > On Thu, Jun 1, 2023, 1:34 AM Adam Sotona wrote: > > *From: *classfile-api-dev on > behalf of liangchenblue at gmail.com > *Date: *Wednesday, 31 May 2023 8:26 > *To: *classfile-api-dev > *Subject: *ClassHierarchyResolver changes for the Classfile object > > Hello, > Since we are migrating to the Classfile object (8308899), which was > initiated by our observation that Class hierarchy resolvers shouldn't > always cache their results, I wonder what changes I should adapt to my > current patch (8304425, PR #13082). > > We have already decided a few API changes for the resolver: > 1. Remove the default hierarchy resolver (at least change to static > factories), caching is bound to Classfile lifetime > > Yes, but we need to check performance impact on existing use cases > (where to extra hold Classfile instance with cache). > > 2. Two new resolver factories: Bytecode/resource parsing and > classloading/reflection from a given classloader (The goal of this > patch) > > Yes. > > > 3. The resolution result ClassHierarchyInfo will be converted into an > interface; record is an implementation detail (TBD) > > This can go even further. To save footprint ClassHierarchyInfo > does not need to expose anything, it does not need to carry > thisClass and all interface infos can point to a singleton object, > something like this: > > /** > > ???? * *Information**about**a**resolved**class**or**interface.* > > */ > > sealedinterface*/ClassHierarchyInfo/* > > permitsClassHierarchyImpl./ClassHierarchyInfoImpl/ { > > /** > > ???????? * {*@return*the {*@link*ClassHierarchyInfo} ofaninterface} > > ???????? * nootherinformationaboutinterfaceisrequired > > */ > > static/ClassHierarchyInfo/ */ofInterface/*() { > > returnClassHierarchyImpl./INTERFACE_INFO_INSTANCE/; > > ??????? } > > /** > > ???????? * *@return*the {*@link*ClassHierarchyInfo} ofaninterface > > ???????? * *@param*superClass > informationaboutsuperoftheclassisrequired > > */ > > static/ClassHierarchyInfo/ */ofClass/*(ClassDesc superClass) { > > returnnewClassHierarchyImpl.ClassHierarchyInfoImpl(superClass); > > ??????? } > > ??? } > > > > What should I do with my patch? Should I drop the changes to default > resolver (which adds security manager suppression) and move on with > the current content, or should I expand it to address all 3 planned > changes (despite some of them still in drafting phase) and accomodate > to the Classfile object? (We still have to decide about the default > resolver fo a Classfile object, esp. whether to have one or not) > > I?m not sure why the default class hierarchy resolver should call > AccessController.doPrivileged? > > > Thanks, > > Adam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Thu Jun 1 07:53:12 2023 From: adam.sotona at oracle.com (Adam Sotona) Date: Thu, 1 Jun 2023 07:53:12 +0000 Subject: ClassHierarchyResolver changes for the Classfile object In-Reply-To: <844f92d4-970a-ed1c-cdc9-b84da4115909@oracle.com> References:

<844f92d4-970a-ed1c-cdc9-b84da4115909@oracle.com> Message-ID: I understand the benefits having default class hierarchy resolver configuration its own privileged access to the system class loader, however such ?default? probably should not be available for external use and even JDK-internal use differs case by case. I think it should be user responsibility to deal with security manager when needed. Thanks, Adam From: Mandy Chung Date: Thursday, 1 June 2023 2:47 To: liangchenblue at gmail.com , Adam Sotona Cc: classfile-api-dev Subject: Re: ClassHierarchyResolver changes for the Classfile object It's a question to the ClassHierarchyResolver interaction with the security manager. Although it's deprecated for removal, we still need to consider when it's installed and whether the API would throw SecurityException due to the security permission check or the implementation is safe to use the system class loader loading resources with privilege. Mandy On 5/31/23 5:32 PM, - wrote: The doPrivileged is from Mandy Chung's modification to my patch of reimplementation of MethodHandleProxies.asInterfaceInstance. It allows system code to fetch from system classloader with security manager, but I can just leave this change to be part of that patch instead. On Thu, Jun 1, 2023, 1:34 AM Adam Sotona > wrote: From: classfile-api-dev > on behalf of liangchenblue at gmail.com > Date: Wednesday, 31 May 2023 8:26 To: classfile-api-dev > Subject: ClassHierarchyResolver changes for the Classfile object Hello, Since we are migrating to the Classfile object (8308899), which was initiated by our observation that Class hierarchy resolvers shouldn't always cache their results, I wonder what changes I should adapt to my current patch (8304425, PR #13082). We have already decided a few API changes for the resolver: 1. Remove the default hierarchy resolver (at least change to static factories), caching is bound to Classfile lifetime Yes, but we need to check performance impact on existing use cases (where to extra hold Classfile instance with cache). 2. Two new resolver factories: Bytecode/resource parsing and classloading/reflection from a given classloader (The goal of this patch) Yes. 3. The resolution result ClassHierarchyInfo will be converted into an interface; record is an implementation detail (TBD) This can go even further. To save footprint ClassHierarchyInfo does not need to expose anything, it does not need to carry thisClass and all interface infos can point to a singleton object, something like this: /** * Information about a resolved class or interface. */ sealed interface ClassHierarchyInfo permits ClassHierarchyImpl.ClassHierarchyInfoImpl { /** * {@return the {@link ClassHierarchyInfo} of an interface} * no other information about interface is required */ static ClassHierarchyInfo ofInterface() { return ClassHierarchyImpl.INTERFACE_INFO_INSTANCE; } /** * @return the {@link ClassHierarchyInfo} of an interface * @param superClass information about super of the class is required */ static ClassHierarchyInfo ofClass(ClassDesc superClass) { return new ClassHierarchyImpl.ClassHierarchyInfoImpl(superClass); } } What should I do with my patch? Should I drop the changes to default resolver (which adds security manager suppression) and move on with the current content, or should I expand it to address all 3 planned changes (despite some of them still in drafting phase) and accomodate to the Classfile object? (We still have to decide about the default resolver fo a Classfile object, esp. whether to have one or not) I?m not sure why the default class hierarchy resolver should call AccessController.doPrivileged? Thanks, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From liangchenblue at gmail.com Thu Jun 1 08:36:27 2023 From: liangchenblue at gmail.com (-) Date: Thu, 1 Jun 2023 16:36:27 +0800 Subject: ClassHierarchyResolver changes for the Classfile object In-Reply-To: References:

<844f92d4-970a-ed1c-cdc9-b84da4115909@oracle.com> Message-ID: I think I will leave the security manager patch to where we need it, and will drop it from the CHR refactor. On Thu, Jun 1, 2023, 3:53 PM Adam Sotona wrote: > I understand the benefits having default class hierarchy resolver > configuration its own privileged access to the system class loader, however > such ?default? probably should not be available for external use and even > JDK-internal use differs case by case. I think it should be user > responsibility to deal with security manager when needed. > > > > Thanks, > > Adam > > > > > > *From: *Mandy Chung > *Date: *Thursday, 1 June 2023 2:47 > *To: *liangchenblue at gmail.com , Adam Sotona < > adam.sotona at oracle.com> > *Cc: *classfile-api-dev > *Subject: *Re: ClassHierarchyResolver changes for the Classfile object > > It's a question to the ClassHierarchyResolver interaction with the > security manager. Although it's deprecated for removal, we still need to > consider when it's installed and whether the API would throw > SecurityException due to the security permission check or the > implementation is safe to use the system class loader loading resources > with privilege. > > Mandy > > On 5/31/23 5:32 PM, - wrote: > > The doPrivileged is from Mandy Chung's modification to my patch of > reimplementation of MethodHandleProxies.asInterfaceInstance. It allows > system code to fetch from system classloader with security manager, but I > can just leave this change to be part of that patch instead. > > > > On Thu, Jun 1, 2023, 1:34 AM Adam Sotona wrote: > > > > > > *From: *classfile-api-dev on behalf > of liangchenblue at gmail.com > *Date: *Wednesday, 31 May 2023 8:26 > *To: *classfile-api-dev > *Subject: *ClassHierarchyResolver changes for the Classfile object > > Hello, > Since we are migrating to the Classfile object (8308899), which was > initiated by our observation that Class hierarchy resolvers shouldn't > always cache their results, I wonder what changes I should adapt to my > current patch (8304425, PR #13082). > > We have already decided a few API changes for the resolver: > 1. Remove the default hierarchy resolver (at least change to static > factories), caching is bound to Classfile lifetime > > Yes, but we need to check performance impact on existing use cases (where > to extra hold Classfile instance with cache). > > > > > > 2. Two new resolver factories: Bytecode/resource parsing and > classloading/reflection from a given classloader (The goal of this > patch) > > > > Yes. > > > 3. The resolution result ClassHierarchyInfo will be converted into an > interface; record is an implementation detail (TBD) > > > > This can go even further. To save footprint ClassHierarchyInfo does not > need to expose anything, it does not need to carry thisClass and all > interface infos can point to a singleton object, something like this: > > /** > > * *Information* *about* *a* *resolved* *class* *or* *interface.* > > */ > > sealed interface *ClassHierarchyInfo* > > permits ClassHierarchyImpl.*ClassHierarchyInfoImpl* { > > > > /** > > * {*@return* the {*@link* ClassHierarchyInfo} of an interface} > > * no other information about interface is required > > */ > > static *ClassHierarchyInfo* *ofInterface*() { > > return ClassHierarchyImpl.*INTERFACE_INFO_INSTANCE*; > > } > > > > /** > > * *@return* the {*@link* ClassHierarchyInfo} of an interface > > * *@param* superClass information about super of the class is > required > > */ > > static *ClassHierarchyInfo* *ofClass*(ClassDesc superClass) { > > return new > ClassHierarchyImpl.ClassHierarchyInfoImpl(superClass); > > } > > } > > > > What should I do with my patch? Should I drop the changes to default > resolver (which adds security manager suppression) and move on with > the current content, or should I expand it to address all 3 planned > changes (despite some of them still in drafting phase) and accomodate > to the Classfile object? (We still have to decide about the default > resolver fo a Classfile object, esp. whether to have one or not) > > > > I?m not sure why the default class hierarchy resolver should call > AccessController.doPrivileged? > > > > > Thanks, > > Adam > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liangchenblue at gmail.com Thu Jun 1 08:44:33 2023 From: liangchenblue at gmail.com (-) Date: Thu, 1 Jun 2023 16:44:33 +0800 Subject: ClassHierarchyResolver changes for the Classfile object In-Reply-To: References: Message-ID: (Sorry, forgot to cc classfile api dev) For your performance impact concerns, I think we can probably keep caching for the system class loader resource parsing CHR. But I think we will still convert the field to a static method. Should I incoporate all 3 changes in my patch? > On Thu, Jun 1, 2023, 1:34 AM Adam Sotona wrote: > >> >> >> >> >> *From: *classfile-api-dev on behalf >> of liangchenblue at gmail.com >> *Date: *Wednesday, 31 May 2023 8:26 >> *To: *classfile-api-dev >> *Subject: *ClassHierarchyResolver changes for the Classfile object >> >> Hello, >> Since we are migrating to the Classfile object (8308899), which was >> initiated by our observation that Class hierarchy resolvers shouldn't >> always cache their results, I wonder what changes I should adapt to my >> current patch (8304425, PR #13082). >> >> We have already decided a few API changes for the resolver: >> 1. Remove the default hierarchy resolver (at least change to static >> factories), caching is bound to Classfile lifetime >> >> Yes, but we need to check performance impact on existing use cases (where >> to extra hold Classfile instance with cache). >> >> >> >> >> >> 2. Two new resolver factories: Bytecode/resource parsing and >> classloading/reflection from a given classloader (The goal of this >> patch) >> >> >> >> Yes. >> >> >> 3. The resolution result ClassHierarchyInfo will be converted into an >> interface; record is an implementation detail (TBD) >> >> >> >> This can go even further. To save footprint ClassHierarchyInfo does not >> need to expose anything, it does not need to carry thisClass and all >> interface infos can point to a singleton object, something like this: >> >> /** >> >> * *Information* *about* *a* *resolved* *class* *or* *interface.* >> >> */ >> >> sealed interface *ClassHierarchyInfo* >> >> permits ClassHierarchyImpl.*ClassHierarchyInfoImpl* { >> >> >> >> /** >> >> * {*@return* the {*@link* ClassHierarchyInfo} of an interface} >> >> * no other information about interface is required >> >> */ >> >> static *ClassHierarchyInfo* *ofInterface*() { >> >> return ClassHierarchyImpl.*INTERFACE_INFO_INSTANCE*; >> >> } >> >> >> >> /** >> >> * *@return* the {*@link* ClassHierarchyInfo} of an interface >> >> * *@param* superClass information about super of the class is >> required >> >> */ >> >> static *ClassHierarchyInfo* *ofClass*(ClassDesc superClass) { >> >> return new >> ClassHierarchyImpl.ClassHierarchyInfoImpl(superClass); >> >> } >> >> } >> >> >> >> What should I do with my patch? Should I drop the changes to default >> resolver (which adds security manager suppression) and move on with >> the current content, or should I expand it to address all 3 planned >> changes (despite some of them still in drafting phase) and accomodate >> to the Classfile object? (We still have to decide about the default >> resolver fo a Classfile object, esp. whether to have one or not) >> >> >> >> I?m not sure why the default class hierarchy resolver should call >> AccessController.doPrivileged? >> >> >> >> >> Thanks, >> >> Adam >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Thu Jun 1 14:57:11 2023 From: adam.sotona at oracle.com (Adam Sotona) Date: Thu, 1 Jun 2023 14:57:11 +0000 Subject: [External] : Re: Planned features of a classfile context object In-Reply-To: <37aba51e-33f7-90de-6c4b-aff0f1bee6a4@oracle.com> References:

<093f8cc9-72b6-d23e-2e92-202ec83eb3ed@oracle.com>

<69bf8797-1c16-2d20-1464-4c725e30dec9@oracle.com>

<37aba51e-33f7-90de-6c4b-aff0f1bee6a4@oracle.com> Message-ID: FYI: I?ve added missing buildTo() overrides, fixed Javadoc and snippets and added more tests. https://github.com/openjdk/jdk/pull/14180 is now ready for review. Thank you, Adam From: Brian Goetz Date: Wednesday, 31 May 2023 17:08 To: Adam Sotona , liangchenblue at gmail.com Cc: classfile-api-dev Subject: Re: [External] : Re: Planned features of a classfile context object Small nits: - should add in buildTo() overload that mirrors build() overloads - Not sure doing ClassFileImpl as a record is a win The rest of it seems nicely minimal. On 5/31/2023 5:55 AM, Adam Sotona wrote: OK, I?ve updated the PR accordingly: https://github.com/openjdk/jdk/pull/14180/files https://github.com/openjdk/jdk/blob/b7e42aa60e8ef6440ffe09577ab2de695dbc7513/src/java.base/share/classes/jdk/internal/classfile/Classfile.java If there are no objections I?ll proceed to update all doc and snippets to reflect the changes. Thanks, Adam From: liangchenblue at gmail.com Date: Wednesday, 31 May 2023 3:48 To: Brian Goetz Cc: Adam Sotona , classfile-api-dev

Subject: Re: [External] : Re: Planned features of a classfile context object I like this withOptions() factory too. Looks more convenient than the static of() parent-based forking; similar API designs exist in ModuleLayer, but I think we can just keep the instance version as we don't have multiple parents for a Classfile. On Wed, May 31, 2023 at 7:32?AM Brian Goetz wrote: > > I think having an instance method on Classfile that produces a modified context: > > Classfile withOptions(Option...) > > would let you "refine" the options while keeping the base options / cache config / etc. > > I agree with Adam that moving all the "make me a class" stuff in one place is a benefit. > > On 5/29/2023 3:52 AM, Adam Sotona wrote: > > > > > > From: liangchenblue at gmail.com > Date: Friday, 26 May 2023 23:53 > To: Brian Goetz > Cc: Adam Sotona , classfile-api-dev

> Subject: [External] : Re: Planned features of a classfile context object > > The Classfile context in the patch looks somewhat like a Classfile > element to me :) With that in mind, I wish we can allow users to > transform/fork these immutable contexts, such as skipping line numbers > for particular files, skip constantpool sharing for select > transformations, etc. with the same code pattern in Classfile > Transformers. Of course, a transformation will always read the default > values of options if not explicitly set, and the transformed context > will have dropped options replaced with their default values. > > > > I can imagine use for context factory method: > > Classfile.Context.of(Classfile.Context parentContext, Option? optionsOverride) > > or after merge of Classfile.Context to Classfile: > > Classfile.of(Classfile parentContext, Option? optionsOverride) > > Is it what you think about? > > > > In addition, ClassModel.transform can probably be kept, which means > using the creation context of the ClassModel to transform this model, > if we make it clear that all models have their lifetime bound to a > Classfile object. > > I found the rule of all new classes created from the context only as positive move. > > Active class creation directly from ClassModel is very confusing with respect to all the options that must be defined before the model is created. > > Explicit call of cc.transform(classModel, transform) is more clear about what build/transform/write options are applied. > > > > Thanks, > > Adam > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Thu Jun 1 16:10:56 2023 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 1 Jun 2023 09:10:56 -0700 Subject: ClassHierarchyResolver changes for the Classfile object In-Reply-To: References:

<844f92d4-970a-ed1c-cdc9-b84da4115909@oracle.com> Message-ID: I don't have an opinion as I'm not close to this area.?? The javadoc needs to specify `SecurityException` be thrown if that's the design. Mandy On 6/1/23 12:53 AM, Adam Sotona wrote: > > I understand the benefits having default class hierarchy resolver > configuration its own privileged access to the system class loader, > however such ?default? probably should not be available for external > use and even JDK-internal use differs case by case. I think it should > be user responsibility to deal with security manager when needed. > > Thanks, > > Adam > > *From: *Mandy Chung > *Date: *Thursday, 1 June 2023 2:47 > *To: *liangchenblue at gmail.com , Adam Sotona > > *Cc: *classfile-api-dev > *Subject: *Re: ClassHierarchyResolver changes for the Classfile object > > It's a question to the ClassHierarchyResolver interaction with the > security manager.?? Although it's deprecated for removal, we still > need to consider when it's installed and whether the API would throw > SecurityException due to the security permission check or the > implementation is safe to use the system class loader loading > resources with privilege. > > Mandy > > On 5/31/23 5:32 PM, - wrote: > > The doPrivileged is from Mandy Chung's modification to my patch of > reimplementation of MethodHandleProxies.asInterfaceInstance. It > allows system code to fetch from system classloader with security > manager, but I can just leave this change to be part of that patch > instead. > > On Thu, Jun 1, 2023, 1:34 AM Adam Sotona > wrote: > > *From: *classfile-api-dev > on behalf of liangchenblue at gmail.com > *Date: *Wednesday, 31 May 2023 8:26 > *To: *classfile-api-dev > *Subject: *ClassHierarchyResolver changes for the Classfile object > > Hello, > Since we are migrating to the Classfile object (8308899), > which was > initiated by our observation that Class hierarchy resolvers > shouldn't > always cache their results, I wonder what changes I should > adapt to my > current patch (8304425, PR #13082). > > We have already decided a few API changes for the resolver: > 1. Remove the default hierarchy resolver (at least change to > static > factories), caching is bound to Classfile lifetime > > Yes, but we need to check performance impact on existing use > cases (where to extra hold Classfile instance with cache). > > 2. Two new resolver factories: Bytecode/resource parsing and > classloading/reflection from a given classloader (The goal of this > patch) > > Yes. > > > 3. The resolution result ClassHierarchyInfo will be converted > into an > interface; record is an implementation detail (TBD) > > This can go even further. To save footprint ClassHierarchyInfo > does not need to expose anything, it does not need to carry > thisClass and all interface infos can point to a singleton > object, something like this: > > /** > > ???? * *Information**about**a**resolved**class**or**interface.* > > */ > > sealedinterface*/ClassHierarchyInfo/* > > permitsClassHierarchyImpl./ClassHierarchyInfoImpl/ { > > /** > > ???????? * {*@return*the {*@link*ClassHierarchyInfo} > ofaninterface} > > ???????? * nootherinformationaboutinterfaceisrequired > > */ > > static/ClassHierarchyInfo/ */ofInterface/*() { > > returnClassHierarchyImpl./INTERFACE_INFO_INSTANCE/; > > } > > /** > > ???????? * *@return*the {*@link*ClassHierarchyInfo} ofaninterface > > ???????? * *@param*superClass > informationaboutsuperoftheclassisrequired > > */ > > static/ClassHierarchyInfo/ */ofClass/*(ClassDesc superClass) { > > returnnewClassHierarchyImpl.ClassHierarchyInfoImpl(superClass); > > } > > ??? } > > > > What should I do with my patch? Should I drop the changes to > default > resolver (which adds security manager suppression) and move on > with > the current content, or should I expand it to address all 3 > planned > changes (despite some of them still in drafting phase) and > accomodate > to the Classfile object? (We still have to decide about the > default > resolver fo a Classfile object, esp. whether to have one or not) > > I?m not sure why the default class hierarchy resolver should > call AccessController.doPrivileged? > > > Thanks, > > Adam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liangchenblue at gmail.com Wed Jun 21 00:35:22 2023 From: liangchenblue at gmail.com (-) Date: Wed, 21 Jun 2023 08:35:22 +0800 Subject: Constant Descriptors usage and Latest versions Message-ID: Hello, During the recent browsing of Classfile API and its usages, a few issues stood out to me: 1. LATEST_MAJOR_VERSION and LATEST_MINOR_VERSION should become static methods: otherwise, javac will inline the constant values, making a program compiled with an older JDK unable to fetch the latest Major class file version. 2. Many usages (in user code) of Constant Descriptors from java.lang.constant package are somewhat inefficient: for instance, ClassDesc and MethodTypeDesc should both be stored in static final fields than constructed on each call; MethodTypeDesc should be constructed with a parameter array instead of with a descriptor string, as descriptor string parsing has been proven slow in recent benchmarks. 3. We should probably have a set of char constants for annotation tags in Classfile as well. Best, Chen Liang From brian.goetz at oracle.com Wed Jun 21 01:53:14 2023 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 20 Jun 2023 21:53:14 -0400 Subject: Constant Descriptors usage and Latest versions In-Reply-To: References: Message-ID: <3a00453c-18ff-1360-2efc-5a18268175e4@oracle.com> > 1. LATEST_MAJOR_VERSION and LATEST_MINOR_VERSION should become static > methods: otherwise, javac will inline the constant values, making a > program compiled with an older JDK unable to fetch the latest Major > class file version. Good catch. > 2. Many usages (in user code) of Constant Descriptors from > java.lang.constant package are somewhat inefficient: for instance, > ClassDesc and MethodTypeDesc should both be stored in static final > fields than constructed on each call; MethodTypeDesc should be > constructed with a parameter array instead of with a descriptor > string, as descriptor string parsing has been proven slow in recent > benchmarks. The XxxDesc-accepting methods were built on top of XxxEntry-accepting methods, so you should be able to do everything you need (just with fewer seat belts) by constructing constant pool entries using UTF8 descriptors. Are there other changes you want to suggest here, or are you making a suggestion for the docs?? Having a section on constant pool entries / descriptors in the package javadoc would make sense. > 3. We should probably have a set of char constants for annotation tags > in Classfile as well. > Seems reasonable. No objections to any of this.? Would you like to propose something concrete? From liangchenblue at gmail.com Wed Jun 21 05:04:36 2023 From: liangchenblue at gmail.com (-) Date: Wed, 21 Jun 2023 13:04:36 +0800 Subject: Constant Descriptors usage and Latest versions In-Reply-To: <3a00453c-18ff-1360-2efc-5a18268175e4@oracle.com> References: <3a00453c-18ff-1360-2efc-5a18268175e4@oracle.com> Message-ID: For 1 and 3, there's currently Classfile context object migration, so I think I can create an issue and send a pull request to Adam's fork updating the Classfile interface. For 2, this problem is actually more related to the Constant API, for Constant Descriptors themselves are prime candidates to be Constable, as they are already immutable. I just happened to find that we construct reusable MethodTypeDesc each time a method is called in the SystemModulesPlugin migration, which makes my attempts to speed up MethodTypeDesc::descriptorString less meaningful. I can create an issue and a patch to convert existing JDK usages to use from static final fields whenever possible; and we can additionally update the API specification asking users to store in static final fields like for the Vector API. On Wed, Jun 21, 2023 at 9:53?AM Brian Goetz wrote: > > > > > 1. LATEST_MAJOR_VERSION and LATEST_MINOR_VERSION should become static > > methods: otherwise, javac will inline the constant values, making a > > program compiled with an older JDK unable to fetch the latest Major > > class file version. > > Good catch. > > > 2. Many usages (in user code) of Constant Descriptors from > > java.lang.constant package are somewhat inefficient: for instance, > > ClassDesc and MethodTypeDesc should both be stored in static final > > fields than constructed on each call; MethodTypeDesc should be > > constructed with a parameter array instead of with a descriptor > > string, as descriptor string parsing has been proven slow in recent > > benchmarks. > > The XxxDesc-accepting methods were built on top of XxxEntry-accepting > methods, so you should be able to do everything you need (just with > fewer seat belts) by constructing constant pool entries using UTF8 > descriptors. > > Are there other changes you want to suggest here, or are you making a > suggestion for the docs? Having a section on constant pool entries / > descriptors in the package javadoc would make sense. > > > 3. We should probably have a set of char constants for annotation tags > > in Classfile as well. > > > > Seems reasonable. > > No objections to any of this. Would you like to propose something concrete? From brian.goetz at oracle.com Wed Jun 21 12:17:10 2023 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 21 Jun 2023 08:17:10 -0400 Subject: Constant Descriptors usage and Latest versions In-Reply-To: References: <3a00453c-18ff-1360-2efc-5a18268175e4@oracle.com> Message-ID: <4dfae769-1ea7-2bb3-76cc-e4c450339344@oracle.com> > For 2, this problem is actually more related to the Constant API, for > Constant Descriptors themselves are prime candidates to be Constable, > as they are already immutable. Fun fact: in the initial prototype they were Constable, at which point we realized that some work was needed in the condy protocol to make it practice for libraries to do this, so we backed out the `implements Constable` "temporarily" while waiting for some work on condy.? Which has been a while at this point.? (The main issue is that many condy's would like to use an ordinary static method for their bootstrap, rather than libraries having to have two versions of each factory, one for bytecoded use and one for condy use, but condy bootstraps currently require the three metadata arguments, even when not used.) From liangchenblue at gmail.com Tue Jun 27 14:38:55 2023 From: liangchenblue at gmail.com (-) Date: Tue, 27 Jun 2023 22:38:55 +0800 Subject: Constant Descriptors usage and Latest versions In-Reply-To: References: <3a00453c-18ff-1360-2efc-5a18268175e4@oracle.com> Message-ID: I have submitted an issue https://bugs.openjdk.org/browse/JDK-8310848 and a patch https://github.com/openjdk/jdk/pull/14640 for 2, fixing up existing JDK usages. Adam, can you review it? Chen Liang On Wed, Jun 21, 2023 at 1:04?PM - wrote: > > For 1 and 3, there's currently Classfile context object migration, so > I think I can create an issue and send a pull request to Adam's fork > updating the Classfile interface. > > For 2, this problem is actually more related to the Constant API, for > Constant Descriptors themselves are prime candidates to be Constable, > as they are already immutable. I just happened to find that we > construct reusable MethodTypeDesc each time a method is called in the > SystemModulesPlugin migration, which makes my attempts to speed up > MethodTypeDesc::descriptorString less meaningful. I can create an > issue and a patch to convert existing JDK usages to use from static > final fields whenever possible; and we can additionally update the API > specification asking users to store in static final fields like for > the Vector API. > > On Wed, Jun 21, 2023 at 9:53?AM Brian Goetz wrote: > > > > > > > > > 1. LATEST_MAJOR_VERSION and LATEST_MINOR_VERSION should become static > > > methods: otherwise, javac will inline the constant values, making a > > > program compiled with an older JDK unable to fetch the latest Major > > > class file version. > > > > Good catch. > > > > > 2. Many usages (in user code) of Constant Descriptors from > > > java.lang.constant package are somewhat inefficient: for instance, > > > ClassDesc and MethodTypeDesc should both be stored in static final > > > fields than constructed on each call; MethodTypeDesc should be > > > constructed with a parameter array instead of with a descriptor > > > string, as descriptor string parsing has been proven slow in recent > > > benchmarks. > > > > The XxxDesc-accepting methods were built on top of XxxEntry-accepting > > methods, so you should be able to do everything you need (just with > > fewer seat belts) by constructing constant pool entries using UTF8 > > descriptors. > > > > Are there other changes you want to suggest here, or are you making a > > suggestion for the docs? Having a section on constant pool entries / > > descriptors in the package javadoc would make sense. > > > > > 3. We should probably have a set of char constants for annotation tags > > > in Classfile as well. > > > > > > > Seems reasonable. > > > > No objections to any of this. Would you like to propose something concrete? From liangchenblue at gmail.com Wed Jun 28 06:32:57 2023 From: liangchenblue at gmail.com (-) Date: Wed, 28 Jun 2023 14:32:57 +0800 Subject: A list of issues about Classfile API Message-ID: Hello, I just looked over the Classfile API and found a few design issues, aside from simple typos addressed in https://github.com/openjdk/jdk/pull/14686: Specific issues: 1. LocalVariable and LocalVariableType: They are missing factory methods. In addition, they shouldn't have writeTo(BufWriter) method exposed in the public API. 2. ConstantPoolBuilder::constantValueEntry/loadableConstantEntry/annotationConstantValueEntry should accept the 4 subword types: Byte, Boolean, Char, Short, which should simply map to int entries. 3. BufWriter::asByteBuffer is weird: it is a write-allowed buffer that can modify the buf until the old array is discarded when the backing buf is expanded. Currently used by stack map generation and stack counting, we should probably refit this to be user-safe or make this an internal API. 4. FieldRefEntry, MethodRefEntry, InterfaceMethodRefEntry, ConstantDynamicEntry, InvokeDynamicEntry should have typeSymbol() to easily access the shared field and method type symbols. 5. AttributeMapper::validSince should be removed, as mentioned by Adam a while ago; it's unused and its implementations are sometimes incorrect. General issues: 1. What about the attributes in Code? Currently, attributes in code aren't delivered in Streaming besides the few hardcoded ones, which means that custom attributes will be lost after a code model undergoes an accept-all code transform. Is that the intended behavior? 1.1. If CodeElement is only for streamable elements, then StackMapTableAttribute shouldn't be a CodeElement, as it's never delivered in code streams. 2. For nullable references, currently Classfile API accepts an Optional argument instead of a nullable argument. Should we switch those to nullable arguments instead, like parameter name for MethodParameterInfo? 3. We can add @sealedGraph tag to sealed interfaces in the Classfile API, which will render an svg image of the sealed class hierarchy (exists in classes like j.l.i.CallSite already) Thank you for taking time and reading through this long list. Feel free to discuss these issues and propose suitable solutions. Many thanks, Chen Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Wed Jun 28 14:00:34 2023 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 28 Jun 2023 10:00:34 -0400 Subject: A list of issues about Classfile API In-Reply-To: References: Message-ID: <5445af2b-254c-099d-f076-f102b39f235b@oracle.com> Thanks for gathering this list.? Some quick thoughts inline. On 6/28/2023 2:32 AM, - wrote: > Hello, I just looked over the Classfile API and found a few design > issues, aside from simple typos addressed in > https://github.com/openjdk/jdk/pull/14686: > > Specific issues: > 1. LocalVariable and LocalVariableType: They are missing factory > methods. In addition, they shouldn't have writeTo(BufWriter) method > exposed in the public API. I see two factory methods in LocalVariable and the same in LocalVariableType, both called "of".? Are there other versions missing? But I do agree that the inclusion of `writeTo(BufWriter)` is implementation that should be encapsulated. > 2. > ConstantPoolBuilder::constantValueEntry/loadableConstantEntry/annotationConstantValueEntry > should accept the 4 subword types: Byte, Boolean, Char, Short, which > should simply map to int entries. If we think this is needed, we'll need an overload for constantValueEntry(Object), since Byte and friends are not ConstantDesc, and there is unfortunately no common supertype for the wrapper classes.? If you have a sharp type in hand, you can also use intEntry for Byte/Char/Short. > 3. BufWriter::asByteBuffer is weird: it is a write-allowed buffer that > can modify the buf until the old array is discarded when the backing > buf is expanded. Currently used by stack map generation and stack > counting, we should probably refit this to be user-safe or make this > an internal API. Yes, this seems to have been added in to support the stack map generator.? I agree it should move internal and/or be refitted. > 4. FieldRefEntry, MethodRefEntry, InterfaceMethodRefEntry, > ConstantDynamicEntry, InvokeDynamicEntry should have typeSymbol() to > easily access the shared field and method type symbols. Agree > 5. AttributeMapper::validSince should be removed, as mentioned by Adam > a while ago; it's unused and its implementations are sometimes incorrect. I have mixed feelings about this.? The JVMS has a table of when each attribute was defined, and this is a sensible and authoritative place to put this information.? On the other hand, it is not enforced when writing classfiles, and for attributes that are not defined by JVMS, this quantity is basically undefined. Perhaps it should be renamed to something that doesn't imply validation, such as "introducedInVersion"? If we're to remove it, we should ask a similar question about allowMultiple(), though we do enforce this one and it seems useful as a way of catching silly errors. > General issues: > 1. What about the attributes in Code? Currently, attributes in code > aren't delivered in Streaming besides the few hardcoded ones, which > means that custom attributes will be lost after a code model undergoes > an accept-all code transform. Is that the intended behavior? Not the intended behavior.? The definition of CodeElement says: public sealed interface CodeElement extends ClassfileElement ??????? permits Instruction, PseudoInstruction, ??????????????? CustomAttribute, RuntimeVisibleTypeAnnotationsAttribute, RuntimeInvisibleTypeAnnotationsAttribute, ??????????????? StackMapTableAttribute { } so CustomAttribute should definitely be expected by consumers.? We eat a number of other attributes, such as line numbers, stack map, etc, presenting their contents as pseudo-instructions.? And we definitely eat stackmaps (similar to how we treat BootstrapMethodsTable as part of the CP, not an attribute.)? But the residue of attributes (which is usually empty) should be delivered as custom attributes.? I suspect we never noticed because so few classfile have these. > ? ? 1.1. If CodeElement is only for streamable elements, then > StackMapTableAttribute shouldn't be a CodeElement, as it's never > delivered in code streams. Yes, probably true. I think we could definitely do better at making it clear which attributes are considered "part of something else", and under what conditions they will show up anyway (e.g., if you ask for CodeModel::attributes you will see the stack map table.)? Not clear whether the way to do this is with code (such as a NotHandledAsElement supertype) or a section of the user's guide (what user's guide?) about attributes. > 2. For nullable references, currently Classfile API accepts an > Optional argument instead of a nullable argument. Should we > switch those to nullable arguments instead, like parameter name for > MethodParameterInfo? Is there a third choice?? :)?? Both are kind of sad. We should certainly be consistent.? Thankfully, I think there are relatively few cases here to handle? > 3. We can add?@sealedGraph tag to sealed interfaces in the Classfile > API, which will render an svg image of the sealed class hierarchy > (exists in classes like j.l.i.CallSite already) For types where all the subtypes are private (and there are a lot of these), naming the subtypes is probably just teasing the user.? Does the SVG renderer remove non-public permitted subtypes?? Some of the public types permit both public and private subtypes, which would be confusing. Cheers, -Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From liangchenblue at gmail.com Wed Jun 28 15:02:35 2023 From: liangchenblue at gmail.com (-) Date: Wed, 28 Jun 2023 23:02:35 +0800 Subject: A list of issues about Classfile API In-Reply-To: <5445af2b-254c-099d-f076-f102b39f235b@oracle.com> References: <5445af2b-254c-099d-f076-f102b39f235b@oracle.com> Message-ID: Short conclusion: we have agreed on two actions so far, 1. Hide writeTo(BufWriter) in classfile.instruction.LocalVariable(Type) 2. Add typeSymbol for the 5 entries that have Field/Method types And for the rest, here are my responses, inlined: On Wed, Jun 28, 2023 at 10:00?PM Brian Goetz wrote: > Thanks for gathering this list. Some quick thoughts inline. > > On 6/28/2023 2:32 AM, - wrote: > > Hello, I just looked over the Classfile API and found a few design issues, > aside from simple typos addressed in > https://github.com/openjdk/jdk/pull/14686: > > Specific issues: > 1. LocalVariable and LocalVariableType: They are missing factory methods. > In addition, they shouldn't have writeTo(BufWriter) method exposed in the > public API. > > > I see two factory methods in LocalVariable and the same in > LocalVariableType, both called "of". Are there other versions missing? > Sorry, I meant classfile.attribute.LocalVariableInfo and LocalVariableTypeInfo. > > But I do agree that the inclusion of `writeTo(BufWriter)` is > implementation that should be encapsulated. > > 2. > ConstantPoolBuilder::constantValueEntry/loadableConstantEntry/annotationConstantValueEntry > should accept the 4 subword types: Byte, Boolean, Char, Short, which should > simply map to int entries. > > > If we think this is needed, we'll need an overload for > constantValueEntry(Object), since Byte and friends are not ConstantDesc, > and there is unfortunately no common supertype for the wrapper classes. If > you have a sharp type in hand, you can also use intEntry for > Byte/Char/Short. > Oops, never noticed these 4 subword primitive types are not ConstantDesc. This suggestion is moot. > > > 3. BufWriter::asByteBuffer is weird: it is a write-allowed buffer that can > modify the buf until the old array is discarded when the backing buf is > expanded. Currently used by stack map generation and stack counting, we > should probably refit this to be user-safe or make this an internal API. > > > Yes, this seems to have been added in to support the stack map generator. > I agree it should move internal and/or be refitted. > I think we will move this to internal for now, as its behavior as a public API is up to debate. We can always add it in the future shall we need it. > > 4. FieldRefEntry, MethodRefEntry, InterfaceMethodRefEntry, > ConstantDynamicEntry, InvokeDynamicEntry should have typeSymbol() to easily > access the shared field and method type symbols. > > > Agree > > 5. AttributeMapper::validSince should be removed, as mentioned by Adam a > while ago; it's unused and its implementations are sometimes incorrect. > > > I have mixed feelings about this. The JVMS has a table of when each > attribute was defined, and this is a sensible and authoritative place to > put this information. On the other hand, it is not enforced when writing > classfiles, and for attributes that are not defined by JVMS, this quantity > is basically undefined. > > Perhaps it should be renamed to something that doesn't imply validation, > such as "introducedInVersion"? > > If we're to remove it, we should ask a similar question about > allowMultiple(), though we do enforce this one and it seems useful as a way > of catching silly errors. > Introduction version is more like a Classfile version-based toggle to treat an attribute too new as unknown (default behavior per JVMS). Maybe users want more fine-grained control to parse attributes based on class reader context, which I think may be better done by allowing mapper to return Optional.empty/null for readAttribute; and Classfile API may emit an UnknownAttribute instead based on options. > > > General issues: > 1. What about the attributes in Code? Currently, attributes in code aren't > delivered in Streaming besides the few hardcoded ones, which means that > custom attributes will be lost after a code model undergoes an accept-all > code transform. Is that the intended behavior? > > > Not the intended behavior. The definition of CodeElement says: > > public sealed interface CodeElement extends ClassfileElement > permits Instruction, PseudoInstruction, > CustomAttribute, RuntimeVisibleTypeAnnotationsAttribute, > RuntimeInvisibleTypeAnnotationsAttribute, > StackMapTableAttribute { > } > > so CustomAttribute should definitely be expected by consumers. We eat a > number of other attributes, such as line numbers, stack map, etc, > presenting their contents as pseudo-instructions. And we definitely eat > stackmaps (similar to how we treat BootstrapMethodsTable as part of the CP, > not an attribute.) But the residue of attributes (which is usually empty) > should be delivered as custom attributes. I suspect we never noticed > because so few classfile have these. > In addition, if we do stream custom attributes, we might declare UnknownAttribute a subtype of CodeElement and stream them as well, if the process unknown attribute option allows. > > > 1.1. If CodeElement is only for streamable elements, then > StackMapTableAttribute shouldn't be a CodeElement, as it's never delivered > in code streams. > > > Yes, probably true. I think we could definitely do better at making it > clear which attributes are considered "part of something else", and under > what conditions they will show up anyway (e.g., if you ask for > CodeModel::attributes you will see the stack map table.) Not clear whether > the way to do this is with code (such as a NotHandledAsElement supertype) > or a section of the user's guide (what user's guide?) about attributes. > The ClassfileElement is currently only restricting streaming; attributes themselves can appear on any AttributedElement without type restriction, and attribute mappers work across all contexts as well. It's possible that some 3rd party user introduces a custom attribute that should be parsed differently when present in a Field vs in a Method; don't think our API handles such cases at all. > > 2. For nullable references, currently Classfile API accepts an > Optional argument instead of a nullable argument. Should we switch > those to nullable arguments instead, like parameter name for > MethodParameterInfo? > > > Is there a third choice? :) Both are kind of sad. > > We should certainly be consistent. Thankfully, I think there are > relatively few cases here to handle? > It's said that Optional wrapper would bring extra overhead even when value types drop, especially if the wrapped type could have been inlined. Code wise, it does look somewhat verbose (compared to the traditional null-based approach used by familiar ASM), so it's more like a personal habit thing, and I slightly favor nullable due to IDE warnings and preexisting ASM usage. I think we can find most use cases already by searching for Optional in Classfile API. > > > 3. We can add @sealedGraph tag to sealed interfaces in the Classfile API, > which will render an svg image of the sealed class hierarchy (exists in > classes like j.l.i.CallSite already) > > > For types where all the subtypes are private (and there are a lot of > these), naming the subtypes is probably just teasing the user. Does the > SVG renderer remove non-public permitted subtypes? Some of the public > types permit both public and private subtypes, which would be confusing. > It does filter and only render types in public API: see the FFI API's MemoryLayout example: https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/MemoryLayout-sealed-graph.svg > > > Cheers, > -Brian > > Again, thank you for your time and this detailed review! Chen Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Wed Jun 28 15:23:38 2023 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 28 Jun 2023 11:23:38 -0400 Subject: A list of issues about Classfile API In-Reply-To: References: <5445af2b-254c-099d-f076-f102b39f235b@oracle.com> Message-ID: <7744f5ad-44c8-a866-b2e6-507cf4c1b9d1@oracle.com> On 6/28/2023 11:02 AM, - wrote: > And for the rest, here are my responses, inlined: > Specific issues: > >> 1. LocalVariable and LocalVariableType: They are missing factory >> methods. In addition, they shouldn't have writeTo(BufWriter) >> method exposed in the public API. > > I see two factory methods in LocalVariable and the same in > LocalVariableType, both called "of".? Are there other versions > missing? > > Sorry, I meant classfile.attribute.LocalVariableInfo and > LocalVariableTypeInfo. Since these are purely internal classes, I think instantiating through constructors is fine here. > > > Yes, this seems to have been added in to support the stack map > generator.? I agree it should move internal and/or be refitted. > > I think we will move this to internal for now, as its behavior as a > public API is up to debate. We can always add it in the future shall > we need it. This works for me. > > >> 5. AttributeMapper::validSince should be removed, as mentioned by >> Adam a while ago; it's unused and its implementations are >> sometimes incorrect. > > I have mixed feelings about this.? The JVMS has a table of when > each attribute was defined, and this is a sensible and > authoritative place to put this information.? On the other hand, > it is not enforced when writing classfiles, and for attributes > that are not defined by JVMS, this quantity is basically undefined. > > Perhaps it should be renamed to something that doesn't imply > validation, such as "introducedInVersion"? > > If we're to remove it, we should ask a similar question about > allowMultiple(), though we do enforce this one and it seems useful > as a way of catching silly errors. > > Introduction version is more like a Classfile version-based toggle to > treat an attribute too new as unknown (default behavior per JVMS). > Maybe users want more fine-grained control to parse attributes based > on class reader context, which I think may be better done by allowing > mapper to return Optional.empty/null for readAttribute; and Classfile > API may emit an UnknownAttribute instead based on options. Having options to determine whether to filter inapplicable attributes seems a configuration mess for little value.? I'm OK with removing validSince(), since we are unlikely to act on it substantially. > > >> General issues: >> 1. What about the attributes in Code? Currently, attributes in >> code aren't delivered in Streaming besides the few hardcoded >> ones, which means that custom attributes will be lost after a >> code model undergoes an accept-all code transform. Is that the >> intended behavior? > > Not the intended behavior.? The definition of CodeElement says: > > public sealed interface CodeElement extends ClassfileElement > ??????? permits Instruction, PseudoInstruction, > ??????????????? CustomAttribute, > RuntimeVisibleTypeAnnotationsAttribute, > RuntimeInvisibleTypeAnnotationsAttribute, > ??????????????? StackMapTableAttribute { > } > > so CustomAttribute should definitely be expected by consumers.? We > eat a number of other attributes, such as line numbers, stack map, > etc, presenting their contents as pseudo-instructions.? And we > definitely eat stackmaps (similar to how we treat > BootstrapMethodsTable as part of the CP, not an attribute.)? But > the residue of attributes (which is usually empty) should be > delivered as custom attributes.? I suspect we never noticed > because so few classfile have these. > > In addition, if we do stream custom attributes, we might declare > UnknownAttribute a subtype of CodeElement and stream them as well, if > the process unknown attribute option allows. Yes, that seems right. Separately: we need better documentation for attribute handing. This could go in a section of the package Javadoc, but there are a number of conceptual things to capture: how some attributes are considered part of some other classfile element, ho those attributes are presented as elements, how to use AttributeMapper, what happens with unknown attributes, compability considerations when adapting classfiles with unknown attributes, the horrible special story of the type annotation attributes, etc. > > >> ? ? 1.1. If CodeElement is only for streamable elements, then >> StackMapTableAttribute shouldn't be a CodeElement, as it's never >> delivered in code streams. > > Yes, probably true. I think we could definitely do better at > making it clear which attributes are considered "part of something > else", and under what conditions they will show up anyway (e.g., > if you ask for CodeModel::attributes you will see the stack map > table.)? Not clear whether the way to do this is with code (such > as a NotHandledAsElement supertype) or a section of the user's > guide (what user's guide?) about attributes. > > The ClassfileElement is currently only restricting streaming; > attributes themselves can appear on any AttributedElement without type > restriction, and attribute mappers work across all contexts as well. Yes, this is how it was intended -- the attributes bytes are always available if you ask the right way, but the element view shows you a logical, if not physical, view of the classfile. > > Is there a third choice?? :)?? Both are kind of sad. > > We should certainly be consistent.? Thankfully, I think there are > relatively few cases here to handle? > > It's said that Optional wrapper would bring extra overhead even when > value types drop, especially if the wrapped type could have been > inlined. Code wise, it does look somewhat verbose (compared to the > traditional null-based approach used by familiar ASM), so it's more > like a personal habit thing, and I slightly favor nullable due to IDE > warnings and preexisting ASM usage. I think we can find most use cases > already by searching for Optional in Classfile API. OK, let's make a list of both nullable and Optional parameters (this is a useful doc item to have anyway), and make the least bad choice we can given the context. > >> 3. We can add?@sealedGraph tag to sealed interfaces in the >> Classfile API, which will render an svg image of the sealed class >> hierarchy (exists in classes like j.l.i.CallSite already) > > For types where all the subtypes are private (and there are a lot > of these), naming the subtypes is probably just teasing the user.? > Does the SVG renderer remove non-public permitted subtypes?? Some > of the public types permit both public and private subtypes, which > would be confusing. > > It does filter and only render types in public API: see the FFI API's > MemoryLayout example: > https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/MemoryLayout-sealed-graph.svg > OK, so I think we can apply this to interfaces that have any public subtypes. > Again, thank you for your time and this detailed review! Thanks for your diligent help with this project, your efforts are definitely improving both the implementation and API. Cheers, -Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Wed Jun 28 15:33:47 2023 From: adam.sotona at oracle.com (Adam Sotona) Date: Wed, 28 Jun 2023 15:33:47 +0000 Subject: A list of issues about Classfile API In-Reply-To: References: Message-ID: From: classfile-api-dev on behalf of liangchenblue at gmail.com Date: Wednesday, 28 June 2023 8:33 To: classfile-api-dev Subject: A list of issues about Classfile API Hello, I just looked over the Classfile API and found a few design issues, aside from simple typos addressed in https://github.com/openjdk/jdk/pull/14686: Specific issues: 1.1. If CodeElement is only for streamable elements, then StackMapTableAttribute shouldn't be a CodeElement, as it's never delivered in code streams. StackMapTableAttribute is not delivered, however there is a strong case where user needs to create it manually and drop to CodeBuilder (with generation disabled). We probably forgot about this case and it is not tested, however it should work. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Wed Jun 28 15:37:31 2023 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 28 Jun 2023 11:37:31 -0400 Subject: A list of issues about Classfile API In-Reply-To: References: Message-ID: <4d34b302-fe8f-01fd-a372-eacb919f7ead@oracle.com> Thanks, Adam, this is a good point.? All the more reason why we need some better documentation on attribute handling, and especially on "special attributes"; not only are some attributes (e.g., BootstrapMethodsTable) treated specially, here StackMapTable can be treated either way. On 6/28/2023 11:33 AM, Adam Sotona wrote: > > *From: *classfile-api-dev on > behalf of liangchenblue at gmail.com > *Date: *Wednesday, 28 June 2023 8:33 > *To: *classfile-api-dev > *Subject: *A list of issues about Classfile API > > Hello, I just looked over the Classfile API and found a few design > issues, aside from simple typos addressed in > https://github.com/openjdk/jdk/pull/14686: > > Specific issues: > > 1.1. If CodeElement is only for streamable elements, then > StackMapTableAttribute shouldn't be a CodeElement, as it's never > delivered in code streams. > > StackMapTableAttributeis not delivered, however there is a strong case > where user needs to create it manually and drop to CodeBuilder (with > generation disabled). > > We probably forgot about this case and it is not tested, however it > should work. > -------------- next part -------------- An HTML attachment was scrubbed... URL: