From o.myhre at gmail.com Fri Oct 18 07:39:58 2024 From: o.myhre at gmail.com (=?UTF-8?Q?=C3=98ystein_Myhre_Andersen?=) Date: Fri, 18 Oct 2024 09:39:58 +0200 Subject: I got Exception: Could not resolve class Message-ID: Below is a snippet of my code: public byte[] buildClassFile() { ClassDesc CD_ThisClass = currentClassDesc(); ClassDesc CD_SuperClass = superClassDesc(); ClassHierarchy.addClassToSuperClass(CD_ThisClass, CD_SuperClass); try { byte[] bytes = ClassFile.of(ClassFile.ClassHierarchyResolverOption.of(ClassHierarchy.getResolver())).build(CD_ThisClass, ... return(bytes); } catch(Throwable e) { ClassHierarchyResolver resolver = ClassHierarchy.getResolver(); ClassDesc desc = ClassDesc.of("simulaFEC.CLASS_CHECKER1_semchecker1_exp"); System.out.println("classInfo("+desc+") = " + resolver.getClassInfo(desc)); e.printStackTrace(); return null; } } When I run this code I get: classInfo(ClassDesc[CLASS_CHECKER1_semchecker1_exp]) = ClassHierarchyInfoImpl[superClass=ClassDesc[RTS_CLASS], isInterface=false] java.lang.IllegalArgumentException: Could not resolve class CLASS_CHECKER1_semchecker1_exp at java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.resolve(ClassHierarchyImpl.java:76) at java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.isInterface(ClassHierarchyImpl.java:86) at java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeReferenceFrom(StackMapGenerator.java:1334) ..... I use my own 'resolver' which answers that 'CLASS_CHECKER1_semchecker1_exp' is a subclass of 'RTS_CLASS'. I don't understand this. - ?ystein Myhre Andersen -------------- next part -------------- An HTML attachment was scrubbed... URL: From liangchenblue at gmail.com Fri Oct 18 07:51:30 2024 From: liangchenblue at gmail.com (Chen Liang) Date: Fri, 18 Oct 2024 02:51:30 -0500 Subject: I got Exception: Could not resolve class In-Reply-To: References: Message-ID: Hi ?ystein, can you share a link to your ClassHierarchy code? ClassFile API has a layer of caching for the ClassHierarchyResolver it uses, which can lead to it not updating to the latest information in your ClassHierarchy. Chen On Fri, Oct 18, 2024 at 2:40?AM ?ystein Myhre Andersen wrote: > Below is a snippet of my code: > > > public byte[] buildClassFile() { > > ClassDesc CD_ThisClass = currentClassDesc(); > > ClassDesc CD_SuperClass = superClassDesc(); > > ClassHierarchy.addClassToSuperClass(CD_ThisClass, CD_SuperClass); > > try { > > byte[] bytes = > ClassFile.of(ClassFile.ClassHierarchyResolverOption.of(ClassHierarchy.getResolver())).build(CD_ThisClass, > > > ... > > return(bytes); > > } catch(Throwable e) { > > ClassHierarchyResolver resolver = ClassHierarchy.getResolver(); > > ClassDesc desc = ClassDesc.of("simulaFEC.CLASS_CHECKER1_semchecker1_exp"); > > System.out.println("classInfo("+desc+") = " + resolver.getClassInfo(desc > )); > > > e.printStackTrace(); > > return null; > > } > > } > > When I run this code I get: > > > classInfo(ClassDesc[CLASS_CHECKER1_semchecker1_exp]) = > ClassHierarchyInfoImpl[superClass=ClassDesc[RTS_CLASS], isInterface=false] > > java.lang.IllegalArgumentException: Could not resolve class > CLASS_CHECKER1_semchecker1_exp > > at > java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.resolve(ClassHierarchyImpl.java:76) > > at > java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.isInterface(ClassHierarchyImpl.java:86) > > at > java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeReferenceFrom(StackMapGenerator.java:1334) > > ..... > > I use my own 'resolver' which answers that 'CLASS_CHECKER1_semchecker1_exp' > is a subclass of 'RTS_CLASS'. > > I don't understand this. > > > - ?ystein Myhre Andersen > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From o.myhre at gmail.com Fri Oct 18 08:02:27 2024 From: o.myhre at gmail.com (=?UTF-8?Q?=C3=98ystein_Myhre_Andersen?=) Date: Fri, 18 Oct 2024 10:02:27 +0200 Subject: I got Exception: Could not resolve class In-Reply-To: References: Message-ID: Here is the link: https://github.com/portablesimula/SimulaCompiler2/blob/main/Simula/src/simula/compiler/utilities/ClassHierarchy.java I use: openjdk version "24-ea" 2025-03-18 OpenJDK Runtime Environment (build 24-ea+16-1800) OpenJDK 64-Bit Server VM (build 24-ea+16-1800, mixed mode, sharing) - ?ystein On Fri, Oct 18, 2024 at 9:51?AM Chen Liang wrote: > Hi ?ystein, can you share a link to your ClassHierarchy code? ClassFile > API has a layer of caching for the ClassHierarchyResolver it uses, which > can lead to it not updating to the latest information in your > ClassHierarchy. > > Chen > > On Fri, Oct 18, 2024 at 2:40?AM ?ystein Myhre Andersen > wrote: > >> Below is a snippet of my code: >> >> >> public byte[] buildClassFile() { >> >> ClassDesc CD_ThisClass = currentClassDesc(); >> >> ClassDesc CD_SuperClass = superClassDesc(); >> >> ClassHierarchy.addClassToSuperClass(CD_ThisClass, CD_SuperClass); >> >> try { >> >> byte[] bytes = >> ClassFile.of(ClassFile.ClassHierarchyResolverOption.of(ClassHierarchy.getResolver())).build(CD_ThisClass, >> >> >> ... >> >> return(bytes); >> >> } catch(Throwable e) { >> >> ClassHierarchyResolver resolver = ClassHierarchy.getResolver(); >> >> ClassDesc desc = ClassDesc.of("simulaFEC.CLASS_CHECKER1_semchecker1_exp >> "); >> >> System.out.println("classInfo("+desc+") = " + resolver.getClassInfo(desc >> )); >> >> >> e.printStackTrace(); >> >> return null; >> >> } >> >> } >> >> When I run this code I get: >> >> >> classInfo(ClassDesc[CLASS_CHECKER1_semchecker1_exp]) = >> ClassHierarchyInfoImpl[superClass=ClassDesc[RTS_CLASS], isInterface=false] >> >> java.lang.IllegalArgumentException: Could not resolve class >> CLASS_CHECKER1_semchecker1_exp >> >> at >> java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.resolve(ClassHierarchyImpl.java:76) >> >> at >> java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.isInterface(ClassHierarchyImpl.java:86) >> >> at >> java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeReferenceFrom(StackMapGenerator.java:1334) >> >> ..... >> >> I use my own 'resolver' which answers that 'CLASS_CHECKER1_semchecker1_ >> exp' is a subclass of 'RTS_CLASS'. >> >> I don't understand this. >> >> >> - ?ystein Myhre Andersen >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From chen.l.liang at oracle.com Fri Oct 18 13:46:33 2024 From: chen.l.liang at oracle.com (Chen Liang) Date: Fri, 18 Oct 2024 13:46:33 +0000 Subject: I got Exception: Could not resolve class In-Reply-To: References: Message-ID: Thanks for sharing Oystein. The problem is that ClassHierarchyResolver.of(Collection, Map) takes the immediate values in the argument and ignores subsequent updates, which is how most ClassFile APIs work, unfortunately. (The same thing happens if you try to do so for AnnotationValue.OfArray or RuntimeVisibleAnnotationsAttribute) I recommend you return a ClassHierarchyResolver implementation of your own, that returns the real-time results from your ClassHierarchy static fields. Regards, Chen ________________________________ From: classfile-api-dev on behalf of ?ystein Myhre Andersen Sent: Friday, October 18, 2024 3:02 AM To: Chen Liang Cc: classfile-api-dev Subject: Re: I got Exception: Could not resolve class Here is the link: https://github.com/portablesimula/SimulaCompiler2/blob/main/Simula/src/simula/compiler/utilities/ClassHierarchy.java I use: openjdk version "24-ea" 2025-03-18 OpenJDK Runtime Environment (build 24-ea+16-1800) OpenJDK 64-Bit Server VM (build 24-ea+16-1800, mixed mode, sharing) - ?ystein On Fri, Oct 18, 2024 at 9:51?AM Chen Liang > wrote: Hi ?ystein, can you share a link to your ClassHierarchy code? ClassFile API has a layer of caching for the ClassHierarchyResolver it uses, which can lead to it not updating to the latest information in your ClassHierarchy. Chen On Fri, Oct 18, 2024 at 2:40?AM ?ystein Myhre Andersen > wrote: Below is a snippet of my code: public byte[] buildClassFile() { ClassDesc CD_ThisClass = currentClassDesc(); ClassDesc CD_SuperClass = superClassDesc(); ClassHierarchy.addClassToSuperClass(CD_ThisClass, CD_SuperClass); try { byte[] bytes = ClassFile.of(ClassFile.ClassHierarchyResolverOption.of(ClassHierarchy.getResolver())).build(CD_ThisClass, ... return(bytes); } catch(Throwable e) { ClassHierarchyResolver resolver = ClassHierarchy.getResolver(); ClassDesc desc = ClassDesc.of("simulaFEC.CLASS_CHECKER1_semchecker1_exp"); System.out.println("classInfo("+desc+") = " + resolver.getClassInfo(desc)); e.printStackTrace(); return null; } } When I run this code I get: classInfo(ClassDesc[CLASS_CHECKER1_semchecker1_exp]) = ClassHierarchyInfoImpl[superClass=ClassDesc[RTS_CLASS], isInterface=false] java.lang.IllegalArgumentException: Could not resolve class CLASS_CHECKER1_semchecker1_exp at java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.resolve(ClassHierarchyImpl.java:76) at java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.isInterface(ClassHierarchyImpl.java:86) at java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeReferenceFrom(StackMapGenerator.java:1334) ..... I use my own 'resolver' which answers that 'CLASS_CHECKER1_semchecker1_exp' is a subclass of 'RTS_CLASS'. I don't understand this. - ?ystein Myhre Andersen -------------- next part -------------- An HTML attachment was scrubbed... URL: From o.myhre at gmail.com Sat Oct 19 05:44:56 2024 From: o.myhre at gmail.com (=?UTF-8?Q?=C3=98ystein_Myhre_Andersen?=) Date: Sat, 19 Oct 2024 07:44:56 +0200 Subject: I got Exception: Could not resolve class In-Reply-To: References: Message-ID: I tried to implement 'ClassHierarchyInfo' but I got "Sealed type ClassHierarchyInfo cannot be super type of MyClassHierarchyInfo as it is from a different package or split package or module" I misses a method to instantiate 'ClassHierarchyInfo' to deliver the result from 'getClassInfo' May be you should add a method like: 'static ClassHierarchyInfo of(ClassDesc subClass, ClassDesc superClass, boolean isInterface)' to the 'ClassHierarchyInfo' - ?ystein On Fri, Oct 18, 2024 at 3:46?PM Chen Liang wrote: > Thanks for sharing Oystein. The problem is that > ClassHierarchyResolver.of(Collection, Map) takes the immediate values in > the argument and ignores subsequent updates, which is how most ClassFile > APIs work, unfortunately. (The same thing happens if you try to do so for > AnnotationValue.OfArray or RuntimeVisibleAnnotationsAttribute) > > I recommend you return a ClassHierarchyResolver implementation of your > own, that returns the real-time results from your ClassHierarchy static > fields. > > Regards, Chen > ------------------------------ > *From:* classfile-api-dev on behalf > of ?ystein Myhre Andersen > *Sent:* Friday, October 18, 2024 3:02 AM > *To:* Chen Liang > *Cc:* classfile-api-dev > *Subject:* Re: I got Exception: Could not resolve class > > Here is the link: > > https://github.com/portablesimula/SimulaCompiler2/blob/main/Simula/src/simula/compiler/utilities/ClassHierarchy.java > > I use: > openjdk version "24-ea" 2025-03-18 > OpenJDK Runtime Environment (build 24-ea+16-1800) > OpenJDK 64-Bit Server VM (build 24-ea+16-1800, mixed mode, sharing) > > - ?ystein > > On Fri, Oct 18, 2024 at 9:51?AM Chen Liang > wrote: > > Hi ?ystein, can you share a link to your ClassHierarchy code? ClassFile > API has a layer of caching for the ClassHierarchyResolver it uses, which > can lead to it not updating to the latest information in your > ClassHierarchy. > > Chen > > On Fri, Oct 18, 2024 at 2:40?AM ?ystein Myhre Andersen > wrote: > > Below is a snippet of my code: > > > public byte[] buildClassFile() { > > ClassDesc CD_ThisClass = currentClassDesc(); > > ClassDesc CD_SuperClass = superClassDesc(); > > ClassHierarchy.addClassToSuperClass(CD_ThisClass, CD_SuperClass); > > try { > > byte[] bytes = > ClassFile.of(ClassFile.ClassHierarchyResolverOption.of(ClassHierarchy.getResolver())).build(CD_ThisClass, > > > ... > > return(bytes); > > } catch(Throwable e) { > > ClassHierarchyResolver resolver = ClassHierarchy.getResolver(); > > ClassDesc desc = ClassDesc.of("simulaFEC.CLASS_CHECKER1_semchecker1_exp"); > > System.out.println("classInfo("+desc+") = " + resolver.getClassInfo(desc > )); > > > e.printStackTrace(); > > return null; > > } > > } > > When I run this code I get: > > > classInfo(ClassDesc[CLASS_CHECKER1_semchecker1_exp]) = > ClassHierarchyInfoImpl[superClass=ClassDesc[RTS_CLASS], isInterface=false] > > java.lang.IllegalArgumentException: Could not resolve class > CLASS_CHECKER1_semchecker1_exp > > at > java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.resolve(ClassHierarchyImpl.java:76) > > at > java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.isInterface(ClassHierarchyImpl.java:86) > > at > java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeReferenceFrom(StackMapGenerator.java:1334) > > ..... > > I use my own 'resolver' which answers that 'CLASS_CHECKER1_semchecker1_exp' > is a subclass of 'RTS_CLASS'. > > I don't understand this. > > > - ?ystein Myhre Andersen > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From o.myhre at gmail.com Sat Oct 19 06:04:02 2024 From: o.myhre at gmail.com (=?UTF-8?Q?=C3=98ystein_Myhre_Andersen?=) Date: Sat, 19 Oct 2024 08:04:02 +0200 Subject: I got Exception: Could not resolve class In-Reply-To: References: Message-ID: I think I can solve the problem with a 're-try loop'. Something like this: boolean done = false; while(! done) { try { byte[] bytes = ClassFile.of(ClassFile.ClassHierarchyResolverOption.of(ClassHierarchy.getResolver())).build(CD_ThisClass, ... done = true; return(bytes); } catch(Throwable e) {} } On Sat, Oct 19, 2024 at 7:44?AM ?ystein Myhre Andersen wrote: > I tried to implement 'ClassHierarchyInfo' but I got "Sealed type > ClassHierarchyInfo cannot be super type > of MyClassHierarchyInfo as it is from a different package or split package > or module" > > > I misses a method to instantiate 'ClassHierarchyInfo' to deliver the > result from 'getClassInfo' > > > May be you should add a method like: > > > 'static ClassHierarchyInfo of(ClassDesc subClass, ClassDesc superClass, > boolean isInterface)' > > > to the 'ClassHierarchyInfo' > > > - ?ystein > > On Fri, Oct 18, 2024 at 3:46?PM Chen Liang > wrote: > >> Thanks for sharing Oystein. The problem is that >> ClassHierarchyResolver.of(Collection, Map) takes the immediate values in >> the argument and ignores subsequent updates, which is how most ClassFile >> APIs work, unfortunately. (The same thing happens if you try to do so for >> AnnotationValue.OfArray or RuntimeVisibleAnnotationsAttribute) >> >> I recommend you return a ClassHierarchyResolver implementation of your >> own, that returns the real-time results from your ClassHierarchy static >> fields. >> >> Regards, Chen >> ------------------------------ >> *From:* classfile-api-dev on behalf >> of ?ystein Myhre Andersen >> *Sent:* Friday, October 18, 2024 3:02 AM >> *To:* Chen Liang >> *Cc:* classfile-api-dev >> *Subject:* Re: I got Exception: Could not resolve class >> >> Here is the link: >> >> https://github.com/portablesimula/SimulaCompiler2/blob/main/Simula/src/simula/compiler/utilities/ClassHierarchy.java >> >> I use: >> openjdk version "24-ea" 2025-03-18 >> OpenJDK Runtime Environment (build 24-ea+16-1800) >> OpenJDK 64-Bit Server VM (build 24-ea+16-1800, mixed mode, sharing) >> >> - ?ystein >> >> On Fri, Oct 18, 2024 at 9:51?AM Chen Liang >> wrote: >> >> Hi ?ystein, can you share a link to your ClassHierarchy code? ClassFile >> API has a layer of caching for the ClassHierarchyResolver it uses, which >> can lead to it not updating to the latest information in your >> ClassHierarchy. >> >> Chen >> >> On Fri, Oct 18, 2024 at 2:40?AM ?ystein Myhre Andersen >> wrote: >> >> Below is a snippet of my code: >> >> >> public byte[] buildClassFile() { >> >> ClassDesc CD_ThisClass = currentClassDesc(); >> >> ClassDesc CD_SuperClass = superClassDesc(); >> >> ClassHierarchy.addClassToSuperClass(CD_ThisClass, CD_SuperClass); >> >> try { >> >> byte[] bytes = >> ClassFile.of(ClassFile.ClassHierarchyResolverOption.of(ClassHierarchy.getResolver())).build(CD_ThisClass, >> >> >> ... >> >> return(bytes); >> >> } catch(Throwable e) { >> >> ClassHierarchyResolver resolver = ClassHierarchy.getResolver(); >> >> ClassDesc desc = ClassDesc.of("simulaFEC.CLASS_CHECKER1_semchecker1_exp >> "); >> >> System.out.println("classInfo("+desc+") = " + resolver.getClassInfo(desc >> )); >> >> >> e.printStackTrace(); >> >> return null; >> >> } >> >> } >> >> When I run this code I get: >> >> >> classInfo(ClassDesc[CLASS_CHECKER1_semchecker1_exp]) = >> ClassHierarchyInfoImpl[superClass=ClassDesc[RTS_CLASS], isInterface=false] >> >> java.lang.IllegalArgumentException: Could not resolve class >> CLASS_CHECKER1_semchecker1_exp >> >> at >> java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.resolve(ClassHierarchyImpl.java:76) >> >> at >> java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.isInterface(ClassHierarchyImpl.java:86) >> >> at >> java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeReferenceFrom(StackMapGenerator.java:1334) >> >> ..... >> >> I use my own 'resolver' which answers that 'CLASS_CHECKER1_semchecker1_ >> exp' is a subclass of 'RTS_CLASS'. >> >> I don't understand this. >> >> >> - ?ystein Myhre Andersen >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From o.myhre at gmail.com Sat Oct 19 06:16:08 2024 From: o.myhre at gmail.com (=?UTF-8?Q?=C3=98ystein_Myhre_Andersen?=) Date: Sat, 19 Oct 2024 08:16:08 +0200 Subject: I got Exception: Could not resolve class In-Reply-To: References: Message-ID: But, it wasn't that simple ! On Sat, Oct 19, 2024 at 8:04?AM ?ystein Myhre Andersen wrote: > I think I can solve the problem with a 're-try loop'. > Something like this: > > boolean done = false; > > while(! done) { > > try { > > byte[] bytes = > ClassFile.of(ClassFile.ClassHierarchyResolverOption.of(ClassHierarchy.getResolver())).build(CD_ThisClass, > > > ... > > done = true; > > return(bytes); > > } catch(Throwable e) {} > > } > > On Sat, Oct 19, 2024 at 7:44?AM ?ystein Myhre Andersen > wrote: > >> I tried to implement 'ClassHierarchyInfo' but I got "Sealed type >> ClassHierarchyInfo cannot be super type >> of MyClassHierarchyInfo as it is from a different package or split >> package or module" >> >> >> I misses a method to instantiate 'ClassHierarchyInfo' to deliver the >> result from 'getClassInfo' >> >> >> May be you should add a method like: >> >> >> 'static ClassHierarchyInfo of(ClassDesc subClass, ClassDesc superClass, >> boolean isInterface)' >> >> >> to the 'ClassHierarchyInfo' >> >> >> - ?ystein >> >> On Fri, Oct 18, 2024 at 3:46?PM Chen Liang >> wrote: >> >>> Thanks for sharing Oystein. The problem is that >>> ClassHierarchyResolver.of(Collection, Map) takes the immediate values in >>> the argument and ignores subsequent updates, which is how most ClassFile >>> APIs work, unfortunately. (The same thing happens if you try to do so for >>> AnnotationValue.OfArray or RuntimeVisibleAnnotationsAttribute) >>> >>> I recommend you return a ClassHierarchyResolver implementation of your >>> own, that returns the real-time results from your ClassHierarchy static >>> fields. >>> >>> Regards, Chen >>> ------------------------------ >>> *From:* classfile-api-dev on >>> behalf of ?ystein Myhre Andersen >>> *Sent:* Friday, October 18, 2024 3:02 AM >>> *To:* Chen Liang >>> *Cc:* classfile-api-dev >>> *Subject:* Re: I got Exception: Could not resolve class >>> >>> Here is the link: >>> >>> https://github.com/portablesimula/SimulaCompiler2/blob/main/Simula/src/simula/compiler/utilities/ClassHierarchy.java >>> >>> I use: >>> openjdk version "24-ea" 2025-03-18 >>> OpenJDK Runtime Environment (build 24-ea+16-1800) >>> OpenJDK 64-Bit Server VM (build 24-ea+16-1800, mixed mode, sharing) >>> >>> - ?ystein >>> >>> On Fri, Oct 18, 2024 at 9:51?AM Chen Liang >>> wrote: >>> >>> Hi ?ystein, can you share a link to your ClassHierarchy code? ClassFile >>> API has a layer of caching for the ClassHierarchyResolver it uses, which >>> can lead to it not updating to the latest information in your >>> ClassHierarchy. >>> >>> Chen >>> >>> On Fri, Oct 18, 2024 at 2:40?AM ?ystein Myhre Andersen < >>> o.myhre at gmail.com> wrote: >>> >>> Below is a snippet of my code: >>> >>> >>> public byte[] buildClassFile() { >>> >>> ClassDesc CD_ThisClass = currentClassDesc(); >>> >>> ClassDesc CD_SuperClass = superClassDesc(); >>> >>> ClassHierarchy.addClassToSuperClass(CD_ThisClass, CD_SuperClass); >>> >>> try { >>> >>> byte[] bytes = >>> ClassFile.of(ClassFile.ClassHierarchyResolverOption.of(ClassHierarchy.getResolver())).build(CD_ThisClass, >>> >>> >>> ... >>> >>> return(bytes); >>> >>> } catch(Throwable e) { >>> >>> ClassHierarchyResolver resolver = ClassHierarchy.getResolver(); >>> >>> ClassDesc desc = ClassDesc.of("simulaFEC.CLASS_CHECKER1_semchecker1_exp >>> "); >>> >>> System.out.println("classInfo("+desc+") = " + resolver.getClassInfo(desc >>> )); >>> >>> >>> e.printStackTrace(); >>> >>> return null; >>> >>> } >>> >>> } >>> >>> When I run this code I get: >>> >>> >>> classInfo(ClassDesc[CLASS_CHECKER1_semchecker1_exp]) = >>> ClassHierarchyInfoImpl[superClass=ClassDesc[RTS_CLASS], isInterface=false] >>> >>> java.lang.IllegalArgumentException: Could not resolve class >>> CLASS_CHECKER1_semchecker1_exp >>> >>> at >>> java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.resolve(ClassHierarchyImpl.java:76) >>> >>> at >>> java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.isInterface(ClassHierarchyImpl.java:86) >>> >>> at >>> java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeReferenceFrom(StackMapGenerator.java:1334) >>> >>> ..... >>> >>> I use my own 'resolver' which answers that 'CLASS_CHECKER1_semchecker1_ >>> exp' is a subclass of 'RTS_CLASS'. >>> >>> I don't understand this. >>> >>> >>> - ?ystein Myhre Andersen >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From o.myhre at gmail.com Sat Oct 19 08:15:24 2024 From: o.myhre at gmail.com (=?UTF-8?Q?=C3=98ystein_Myhre_Andersen?=) Date: Sat, 19 Oct 2024 10:15:24 +0200 Subject: I got Exception: Could not resolve class In-Reply-To: References: Message-ID: It was possible to implement a re-try loop solution. But it did not turn out very pretty. I would prefer a solution with implementing or instantiation of 'ClassHierarchyInfo'. Here is the snippet code: int count = 5; while((count--) > 0) { try { byte[] bytes = ClassFile.of(ClassFile.ClassHierarchyResolverOption .of(ClassHierarchy.getResolver())).build(CD_ThisClass, ... ... ... ); return(bytes); } catch(IllegalArgumentException e) { boolean feasibleToReTry = false; String msg = e.getMessage(); if(msg.startsWith("Could not resolve class")) { String classID = msg.substring(24); ClassDesc CD = ClassHierarchy.getClassDesc(classID); if(CD != null) { ClassHierarchyResolver resolver = ClassHierarchy.getResolver(); ClassHierarchyInfo classInfo = resolver.getClassInfo(CD); feasibleToReTry = classInfo != null; } } if(count <= 0 || !feasibleToReTry) throw e; } On Sat, Oct 19, 2024 at 8:16?AM ?ystein Myhre Andersen wrote: > But, it wasn't that simple ! > > On Sat, Oct 19, 2024 at 8:04?AM ?ystein Myhre Andersen > wrote: > >> I think I can solve the problem with a 're-try loop'. >> Something like this: >> >> boolean done = false; >> >> while(! done) { >> >> try { >> >> byte[] bytes = >> ClassFile.of(ClassFile.ClassHierarchyResolverOption.of(ClassHierarchy.getResolver())).build(CD_ThisClass, >> >> >> ... >> >> done = true; >> >> return(bytes); >> >> } catch(Throwable e) {} >> >> } >> >> On Sat, Oct 19, 2024 at 7:44?AM ?ystein Myhre Andersen >> wrote: >> >>> I tried to implement 'ClassHierarchyInfo' but I got "Sealed type >>> ClassHierarchyInfo cannot be super type >>> of MyClassHierarchyInfo as it is from a different package or split >>> package or module" >>> >>> >>> I misses a method to instantiate 'ClassHierarchyInfo' to deliver the >>> result from 'getClassInfo' >>> >>> >>> May be you should add a method like: >>> >>> >>> 'static ClassHierarchyInfo of(ClassDesc subClass, ClassDesc superClass, >>> boolean isInterface)' >>> >>> >>> to the 'ClassHierarchyInfo' >>> >>> >>> - ?ystein >>> >>> On Fri, Oct 18, 2024 at 3:46?PM Chen Liang >>> wrote: >>> >>>> Thanks for sharing Oystein. The problem is that >>>> ClassHierarchyResolver.of(Collection, Map) takes the immediate values in >>>> the argument and ignores subsequent updates, which is how most ClassFile >>>> APIs work, unfortunately. (The same thing happens if you try to do so for >>>> AnnotationValue.OfArray or RuntimeVisibleAnnotationsAttribute) >>>> >>>> I recommend you return a ClassHierarchyResolver implementation of your >>>> own, that returns the real-time results from your ClassHierarchy static >>>> fields. >>>> >>>> Regards, Chen >>>> ------------------------------ >>>> *From:* classfile-api-dev on >>>> behalf of ?ystein Myhre Andersen >>>> *Sent:* Friday, October 18, 2024 3:02 AM >>>> *To:* Chen Liang >>>> *Cc:* classfile-api-dev >>>> *Subject:* Re: I got Exception: Could not resolve class >>>> >>>> Here is the link: >>>> >>>> https://github.com/portablesimula/SimulaCompiler2/blob/main/Simula/src/simula/compiler/utilities/ClassHierarchy.java >>>> >>>> I use: >>>> openjdk version "24-ea" 2025-03-18 >>>> OpenJDK Runtime Environment (build 24-ea+16-1800) >>>> OpenJDK 64-Bit Server VM (build 24-ea+16-1800, mixed mode, sharing) >>>> >>>> - ?ystein >>>> >>>> On Fri, Oct 18, 2024 at 9:51?AM Chen Liang >>>> wrote: >>>> >>>> Hi ?ystein, can you share a link to your ClassHierarchy code? ClassFile >>>> API has a layer of caching for the ClassHierarchyResolver it uses, which >>>> can lead to it not updating to the latest information in your >>>> ClassHierarchy. >>>> >>>> Chen >>>> >>>> On Fri, Oct 18, 2024 at 2:40?AM ?ystein Myhre Andersen < >>>> o.myhre at gmail.com> wrote: >>>> >>>> Below is a snippet of my code: >>>> >>>> >>>> public byte[] buildClassFile() { >>>> >>>> ClassDesc CD_ThisClass = currentClassDesc(); >>>> >>>> ClassDesc CD_SuperClass = superClassDesc(); >>>> >>>> ClassHierarchy.addClassToSuperClass(CD_ThisClass, CD_SuperClass); >>>> >>>> try { >>>> >>>> byte[] bytes = >>>> ClassFile.of(ClassFile.ClassHierarchyResolverOption.of(ClassHierarchy.getResolver())).build(CD_ThisClass, >>>> >>>> >>>> ... >>>> >>>> return(bytes); >>>> >>>> } catch(Throwable e) { >>>> >>>> ClassHierarchyResolver resolver = ClassHierarchy.getResolver(); >>>> >>>> ClassDesc desc = ClassDesc.of("simulaFEC.CLASS_CHECKER1_semchecker1_exp >>>> "); >>>> >>>> System.out.println("classInfo("+desc+") = " + resolver.getClassInfo( >>>> desc)); >>>> >>>> >>>> e.printStackTrace(); >>>> >>>> return null; >>>> >>>> } >>>> >>>> } >>>> >>>> When I run this code I get: >>>> >>>> >>>> classInfo(ClassDesc[CLASS_CHECKER1_semchecker1_exp]) = >>>> ClassHierarchyInfoImpl[superClass=ClassDesc[RTS_CLASS], isInterface=false] >>>> >>>> java.lang.IllegalArgumentException: Could not resolve class >>>> CLASS_CHECKER1_semchecker1_exp >>>> >>>> at >>>> java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.resolve(ClassHierarchyImpl.java:76) >>>> >>>> at >>>> java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.isInterface(ClassHierarchyImpl.java:86) >>>> >>>> at >>>> java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeReferenceFrom(StackMapGenerator.java:1334) >>>> >>>> ..... >>>> >>>> I use my own 'resolver' which answers that 'CLASS_CHECKER1_semchecker1_ >>>> exp' is a subclass of 'RTS_CLASS'. >>>> >>>> I don't understand this. >>>> >>>> >>>> - ?ystein Myhre Andersen >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafael.wth at gmail.com Thu Oct 24 06:33:20 2024 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Thu, 24 Oct 2024 08:33:20 +0200 Subject: Stack size miscalculated with try-catch blocks Message-ID: Hello, when testing a recent build of the JDK with my bridge to ASM, I encountered some test failures. This is related to the stack size of a method being calculated with an additional, unnecessary slot. This can be reproduced using https://github.com/raphw/asm-jdk-bridge This can also be reproduced by inspecting the computed stack for: void c() { try { throw new RuntimeException(); } catch (RuntimeException e) { } } which will be computed as 3 and not 2. Best regards, Rafael -------------- next part -------------- An HTML attachment was scrubbed... URL: From david32768 at btinternet.com Wed Oct 30 01:55:53 2024 From: david32768 at btinternet.com (david32768@btinternet.com david32768@btinternet.com) Date: Wed, 30 Oct 2024 01:55:53 +0000 (GMT) Subject: Stack size miscalculated with try-catch blocks In-Reply-To: References: Message-ID: <31060b98.1ba.192db22f3d7.Webtop.22@btinternet.com> The problem is in StackMapGenerate. The original method name of Frame.CheckStack is misleading as it adds 1 to index. The recent changes assume it does not but there are still calls which assume this. ? testcode ``` import module java.base; public class MaxStack ?{ ? ?private static void build(CodeBuilder cob) { ? ? ? ?cob ? ? ? ? ? .iload(0) ? ? ? ? ? .i2l() ? ? ? ? ? .lreturn(); ? ?} ? ?public static void main(String[] args) throws IOException { ? ? ? ?ClassFile cf = ClassFile.of(ClassFile.StackMapsOption.GENERATE_STACK_MAPS); // MaxStack = 3 // ? ? ? ?ClassFile cf = ClassFile.of(); // MaxStack = 2 ? ? ? ?byte[] bytes = cf ? ? ? ? ? ? ? ?.build(ClassDesc.of("TestMaxStack"), ? ? ? ? ? ?clb -> clb.withFlags(ClassFile.ACC_PUBLIC ?| ClassFile.ACC_SUPER) ????????.withVersion(49,0) ? ? ? ? ? ? ? ?.withMethodBody("Table", MethodTypeDesc.ofDescriptor("(I)J"), ? ? ? ? ? ? ? ? ? ? ClassFile.ACC_STATIC, ???????? ? ? MaxStack::build)); ? ? ? ?cf = ClassFile.of(); ? ? ? ?ClassModel cm = cf.parse(bytes); ? ? ? ?cm.methods().stream() ? ? ? ? ? ? ? ?.flatMap(m -> m.attributes().stream()) ????????.filter(attr -> attr instanceof CodeAttribute) ????????.map(attr -> ((CodeAttribute)attr).maxStack()) ????????.map(sz -> "MaxStack = " + sz) ? ? ? ? ? ? ? ?.forEach(System.out::println); ? ?} } ``` ? ------ Original Message ------ From: rafael.wth at gmail.com To: classfile-api-dev at openjdk.org Sent: Thursday, October 24th 2024, 07:33 Subject: Stack size miscalculated with try-catch blocks ? Hello, ? when testing a recent build of the JDK with my bridge to ASM, I encountered some test failures. This is related to the stack size of a method being calculated with an additional, unnecessary slot. This can be reproduced using https://github.com/raphw/asm-jdk-bridge ? This can also be reproduced by inspecting the computed stack for: void c() { try { throw new RuntimeException(); } catch (RuntimeException e) { } } which will be computed as 3 and not 2. ? Best regards, Rafael ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Wed Oct 30 09:19:00 2024 From: adam.sotona at oracle.com (Adam Sotona) Date: Wed, 30 Oct 2024 09:19:00 +0000 Subject: Stack size miscalculated with try-catch blocks In-Reply-To: References: Message-ID: Hi Rafael, Please update to the latest codebase, maxstack of the provided test case is correctly calculated now. Thanks, Adam From: classfile-api-dev on behalf of Rafael Winterhalter Date: Thursday, 24 October 2024 at 8:33 To: classfile-api-dev Subject: Stack size miscalculated with try-catch blocks Hello, when testing a recent build of the JDK with my bridge to ASM, I encountered some test failures. This is related to the stack size of a method being calculated with an additional, unnecessary slot. This can be reproduced using https://github.com/raphw/asm-jdk-bridge This can also be reproduced by inspecting the computed stack for: void c() { try { throw new RuntimeException(); } catch (RuntimeException e) { } } which will be computed as 3 and not 2. Best regards, Rafael -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Wed Oct 30 09:29:53 2024 From: adam.sotona at oracle.com (Adam Sotona) Date: Wed, 30 Oct 2024 09:29:53 +0000 Subject: Stack size miscalculated with try-catch blocks In-Reply-To: <31060b98.1ba.192db22f3d7.Webtop.22@btinternet.com> References: <31060b98.1ba.192db22f3d7.Webtop.22@btinternet.com> Message-ID: Hi David, Provided test case also calculates the maxstack correctly for me (with the recent codebase). Thanks, Adam From: classfile-api-dev on behalf of david32768 at btinternet.com david32768 at btinternet.com Date: Wednesday, 30 October 2024 at 2:56 To: classfile-api-dev at openjdk.org Subject: Re: Stack size miscalculated with try-catch blocks The problem is in StackMapGenerate. The original method name of Frame.CheckStack is misleading as it adds 1 to index. The recent changes assume it does not but there are still calls which assume this. testcode ``` import module java.base; public class MaxStack { private static void build(CodeBuilder cob) { cob .iload(0) .i2l() .lreturn(); } public static void main(String[] args) throws IOException { ClassFile cf = v; // MaxStack = 3 // ClassFile cf = v; // MaxStack = 2 byte[] bytes = cf .build(ClassDesc.of("TestMaxStack"), clb -> clb.withFlags(ClassFile.ACC_PUBLIC | ClassFile.ACC_SUPER) .withVersion(49,0) .withMethodBody("Table", MethodTypeDesc.ofDescriptor("(I)J"), ClassFile.ACC_STATIC, MaxStack::build)); cf = ClassFile.of(); ClassModel cm = cf.parse(bytes); cm.methods().stream() .flatMap(m -> m.attributes().stream()) .filter(attr -> attr instanceof CodeAttribute) .map(attr -> ((CodeAttribute)attr).maxStack()) .map(sz -> "MaxStack = " + sz) .forEach(System.out::println); } } ``` ------ Original Message ------ From: rafael.wth at gmail.com To: classfile-api-dev at openjdk.org Sent: Thursday, October 24th 2024, 07:33 Subject: Stack size miscalculated with try-catch blocks Hello, when testing a recent build of the JDK with my bridge to ASM, I encountered some test failures. This is related to the stack size of a method being calculated with an additional, unnecessary slot. This can be reproduced using https://github.com/raphw/asm-jdk-bridge This can also be reproduced by inspecting the computed stack for: void c() { try { throw new RuntimeException(); } catch (RuntimeException e) { } } which will be computed as 3 and not 2. Best regards, Rafael -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafael.wth at gmail.com Wed Oct 30 10:41:05 2024 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Wed, 30 Oct 2024 11:41:05 +0100 Subject: Stack size miscalculated with try-catch blocks In-Reply-To: References: Message-ID: Is this pushed to master? I still experience these errors on multiple test cases. Am Mi., 30. Okt. 2024 um 10:19 Uhr schrieb Adam Sotona < adam.sotona at oracle.com>: > Hi Rafael, > > Please update to the latest codebase, maxstack of the provided test case > is correctly calculated now. > > > > Thanks, > > Adam > > > > > > *From: *classfile-api-dev on behalf > of Rafael Winterhalter > *Date: *Thursday, 24 October 2024 at 8:33 > *To: *classfile-api-dev > *Subject: *Stack size miscalculated with try-catch blocks > > Hello, > > > > when testing a recent build of the JDK with my bridge to ASM, I > encountered some test failures. This is related to the stack size of a > method being calculated with an additional, unnecessary slot. This can be > reproduced using https://github.com/raphw/asm-jdk-bridge > > > > This can also be reproduced by inspecting the computed stack for: > > void c() { > try { > throw new RuntimeException(); > } catch (RuntimeException e) { > } > } > > which will be computed as 3 and not 2. > > > > Best regards, Rafael > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafael.wth at gmail.com Wed Oct 30 10:44:23 2024 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Wed, 30 Oct 2024 11:44:23 +0100 Subject: Plan to replace offsets with labels in attributes Message-ID: Hei, I was wondering if there is still a plan to replace offsets with labels in attributes, and to allow for custom mappings of labels to offsets and vice versa when reading/writing attributes. As I understand it, the release is planned for JDK 24, so I was hoping this is still considered. Thanks, Rafael -------------- next part -------------- An HTML attachment was scrubbed... URL: