From adam.sotona at oracle.com Tue Apr 2 11:11:13 2024 From: adam.sotona at oracle.com (Adam Sotona) Date: Tue, 2 Apr 2024 11:11:13 +0000 Subject: RFR: 8329099: Undocumented exception thrown by Instruction factory methods accepting Opcode In-Reply-To: References: Message-ID: Please review following PR and related CSR. Thank you! Adam `IllegalArgumentException` thrown by some static factory methods of the following `java.lang.classfile.instruction` interfaces are not documented: - `ArrayLoadInstruction` - `ArrayStoreInstruction` - `BranchInstruction` - `ConvertInstruction` - `DiscontinuedInstruction` - `FieldInstruction` - `InvokeInstruction` - `LoadInstruction` - `MonitorInstruction` - `NewPrimitiveArrayInstruction` - `OperatorInstruction` - `ReturnInstruction` - `StackInstruction` - `StoreInstruction` - `TypeCheckInstruction` `NewPrimitiveArrayInstruction::of` factory method also does not perform the check for invalid argument. This patch adds all the missing `@throws` Javadoc tags and fixes `NewPrimitiveArrayInstruction::of` factory method to perform the argument check. Please review. Thank you, Adam ------------- Commit messages: - 8329099: Undocumented exception thrown by Instruction factory methods accepting Opcode Changes: https://git.openjdk.org/jdk/pull/18578/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18578&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8329099 Stats: 36 lines in 15 files changed: 36 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/18578.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18578/head:pull/18578 PR: https://git.openjdk.org/jdk/pull/18578 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Wed Apr 3 08:54:46 2024 From: adam.sotona at oracle.com (Adam Sotona) Date: Wed, 3 Apr 2024 08:54:46 +0000 Subject: RFR: 8329527: Opcode.IFNONNULL.primaryTypeKind() is not ReferenceType In-Reply-To: References: Message-ID: `Opcode.IFNONNULL.primaryTypeKind()` wrongly returned `IntType` instead of the right `ReferenceType`. Primary type kinds of `BRANCH` opcodes have yet no functional effect in the Class-File API. This simple patch fixes the typo. Please review. Thank you, Adam ------------- Commit messages: - 8329527: Opcode.IFNONNULL.primaryTypeKind() is not ReferenceType Changes: https://git.openjdk.org/jdk/pull/18593/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18593&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8329527 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18593.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18593/head:pull/18593 PR: https://git.openjdk.org/jdk/pull/18593 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Wed Apr 3 08:55:07 2024 From: adam.sotona at oracle.com (Adam Sotona) Date: Wed, 3 Apr 2024 08:55:07 +0000 Subject: RFR: 8325371: Missing ClassFile.Option in package summary In-Reply-To: References: Message-ID: Some of the Class-File API options were not mentioned in the package summary and one exception mentioned `ClassFile.DeadLabelsOption` javadoc was wrong. This patch fixes the javadoc. Please review. Thank you, Adam ------------- Commit messages: - 8325371: Missing ClassFile.Option in package summary Changes: https://git.openjdk.org/jdk/pull/18594/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18594&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325371 Stats: 23 lines in 2 files changed: 12 ins; 6 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/18594.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18594/head:pull/18594 PR: https://git.openjdk.org/jdk/pull/18594 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david32768 at btinternet.com Sat Apr 6 07:49:59 2024 From: david32768 at btinternet.com (david32768@btinternet.com david32768@btinternet.com) Date: Sat, 6 Apr 2024 08:49:59 +0100 (BST) Subject: Stand alone CodeBuilder Message-ID: <39d733a2.ee27.18eb262c041.Webtop.94@btinternet.com> It is possible to write a stand alone CodeBuilder but it would help if user Labels were supported so that a List of CodeElements could be used. More generally could there be a static method Instruction.of(Opcode opcode1) where opcode1 size is 1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Tue Apr 9 14:06:05 2024 From: adam.sotona at oracle.com (Adam Sotona) Date: Tue, 9 Apr 2024 14:06:05 +0000 Subject: RFR: Class-File API patches Message-ID: Hi, I'm looking for volunteers to review following PRs: 8329955: Class-File API ClassPrinter does not print bootstrap methods arguments 8325371: Missing ClassFile.Option in package summary 8329099: Undocumented exception thrown by Instruction factory methods accepting Opcode + CSR review 8320396: Class-File API ClassModel::verify should include checks from hotspot/share/classfile/classFileParser.cpp Thank you! Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Tue Apr 23 11:09:33 2024 From: adam.sotona at oracle.com (Adam Sotona) Date: Tue, 23 Apr 2024 11:09:33 +0000 Subject: RFR: 8330684: ClassFile API runs into StackOverflowError while parsing certain class' bytes In-Reply-To: <0Gzd_4mBh3F1iF4kqUkC6o_nopREpMCuw4vxdef77EI=.232b6168-6487-458b-8245-3ff7680dd053@github.com> References: <0Gzd_4mBh3F1iF4kqUkC6o_nopREpMCuw4vxdef77EI=.232b6168-6487-458b-8245-3ff7680dd053@github.com> Message-ID: ClassFile API dives into the nested constant pool entries without type restrictions, while parsing a class file. Validation of the entry is performed post-parsing. Specifically corrupted constant pool entry may cause infinite loop during parsing and throws SOE. This patch resolves the issue by providing specific implementations for the nested CP entries parsing, instead of sharing the common (post-checking) code. Added test simulates the situation on inner-looped method reference entry. Please review. Thank you, Adam ------------- Commit messages: - added bug# - 8330684: ClassFile API runs into StackOverflowError while parsing certain class' bytesactory.java Changes: https://git.openjdk.org/jdk/pull/18907/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18907&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8330684 Stats: 84 lines in 2 files changed: 60 ins; 5 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/18907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18907/head:pull/18907 PR: https://git.openjdk.org/jdk/pull/18907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Tue Apr 23 13:05:57 2024 From: adam.sotona at oracle.com (Adam Sotona) Date: Tue, 23 Apr 2024 13:05:57 +0000 Subject: RFR: 8325373: Improve StackCounter error reporting for bad switch cases In-Reply-To: References: Message-ID: ClassFile API `StackMapGenerator` attaches print or hex dump of the method to an error message. However there is no such attachment when the stack maps generation is turned off. This patch moves class print/dump to `impl.Util::dumpMethod`, so it is shared by `StackMapGenerator` and `StackCounter` to provide the same level of details in case of an error. Please review. Thank you, Adam ------------- Commit messages: - 8325373: Improve StackCounter error reporting for bad switch cases Changes: https://git.openjdk.org/jdk/pull/18914/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18914&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325373 Stats: 97 lines in 3 files changed: 56 ins; 31 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/18914.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18914/head:pull/18914 PR: https://git.openjdk.org/jdk/pull/18914 -------------- next part -------------- An HTML attachment was scrubbed... URL: From o.myhre at gmail.com Sun Apr 28 10:52:48 2024 From: o.myhre at gmail.com (=?UTF-8?Q?=C3=98ystein_Myhre_Andersen?=) Date: Sun, 28 Apr 2024 12:52:48 +0200 Subject: Got: IllegalArgumentException: Could not resolve class Message-ID: I'm writing a compiler for Simula (the very first oo language). Simula is block-oriented with nested blocks and each block is compiled into a classFile. At a certain level in the hierarchy I get an exception at the end of the classfile building. Exception in thread "main" java.lang.IllegalArgumentException: Could not resolve class adHoc000_adHoc000_PBLK39_Floor_activateIdleLift at java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.resolve(ClassHierarchyImpl.java:75) at java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.isInterface(ClassHierarchyImpl.java:85) at java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeReferenceFrom(StackMapGenerator.java:1363) at java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeFrom(StackMapGenerator.java:1331) at java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.merge(StackMapGenerator.java:1193) at java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.checkAssignableTo(StackMapGenerator.java:1135) at java.base/jdk.internal.classfile.impl.StackMapGenerator.checkJumpTarget(StackMapGenerator.java:280) at java.base/jdk.internal.classfile.impl.StackMapGenerator.processExceptionHandlerTargets(StackMapGenerator.java:678) at java.base/jdk.internal.classfile.impl.StackMapGenerator.processBlock(StackMapGenerator.java:667) at java.base/jdk.internal.classfile.impl.StackMapGenerator.processMethod(StackMapGenerator.java:440) at java.base/jdk.internal.classfile.impl.StackMapGenerator.generate(StackMapGenerator.java:317) at java.base/jdk.internal.classfile.impl.StackMapGenerator.(StackMapGenerator.java:243) at java.base/jdk.internal.classfile.impl.StackMapGenerator.of(StackMapGenerator.java:156) at java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.generateStackMaps(DirectCodeBuilder.java:331) at java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.tryGenerateStackMaps(DirectCodeBuilder.java:340) at java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.writeBody(DirectCodeBuilder.java:382) at java.base/jdk.internal.classfile.impl.UnboundAttribute$AdHocAttribute.writeTo(UnboundAttribute.java:914) at java.base/jdk.internal.classfile.impl.AttributeHolder.writeTo(AttributeHolder.java:56) at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.writeTo(DirectMethodBuilder.java:156) at java.base/jdk.internal.classfile.impl.BufWriterImpl.writeList(BufWriterImpl.java:207) at java.base/jdk.internal.classfile.impl.DirectClassBuilder.build(DirectClassBuilder.java:181) at java.base/jdk.internal.classfile.impl.ClassFileImpl.build(ClassFileImpl.java:114) ... ... Is this a known problem? What am I doing wrong? I am attaching a file with an edited trace leading up to the exception. - ?ystein Myhre Andersen -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- Begin buildClassFile: ClassDesc[adHoc000] public class simulaTestPrograms.adHoc000 extends simula.runtime.RTS_Drawing flags: (0x0021) ACC_PUBLIC, ACC_SUPER this_class: #2 // simulaTestPrograms/adHoc000 super_class: #4 // simula/runtime/RTS_Drawing interfaces: 0, fields: 12, methods: 4, attributes: 1 Constant pool: ... ... Begin buildClassFile: ClassDesc[adHoc000_PBLK39] public class simulaTestPrograms.adHoc000_PBLK39 extends simula.runtime.RTS_Simulation flags: (0x0021) ACC_PUBLIC, ACC_SUPER this_class: #2 // simulaTestPrograms/adHoc000_PBLK39 super_class: #4 // simula/runtime/RTS_Simulation interfaces: 0, fields: 16, methods: 4, attributes: 1 Constant pool: ... ... Begin buildClassFile: ClassDesc[adHoc000_adHoc000_PBLK39_Person] public class simulaTestPrograms.adHoc000_adHoc000_PBLK39_Person extends simula.runtime.RTS_Process flags: (0x0021) ACC_PUBLIC, ACC_SUPER this_class: #2 // simulaTestPrograms/adHoc000_adHoc000_PBLK39_Person super_class: #4 // simula/runtime/RTS_Process interfaces: 0, fields: 7, methods: 3, attributes: 1 Constant pool: ... ... Begin buildClassFile: ClassDesc[adHoc000_adHoc000_PBLK39_Person_getLiftGoingUp] public final class simulaTestPrograms.adHoc000_adHoc000_PBLK39_Person_getLiftGoingUp extends simula.runtime.RTS_PROCEDURE flags: (0x0031) ACC_PUBLIC, ACC_FINAL, ACC_SUPER this_class: #2 // simulaTestPrograms/adHoc000_adHoc000_PBLK39_Person_getLiftGoingUp super_class: #4 // simula/runtime/RTS_PROCEDURE interfaces: 0, fields: 2, methods: 3, attributes: 1 Constant pool: ... ... ClassFile written to: adHoc000_adHoc000_PBLK39_Person_getLiftGoingUp.class nBytes=1229 ClassFile written to: adHoc000_adHoc000_PBLK39_Person.class nBytes=1113 Begin buildClassFile: ClassDesc[adHoc000_adHoc000_PBLK39_Elevator] public class simulaTestPrograms.adHoc000_adHoc000_PBLK39_Elevator extends simula.runtime.RTS_Process flags: (0x0021) ACC_PUBLIC, ACC_SUPER this_class: #2 // simulaTestPrograms/adHoc000_adHoc000_PBLK39_Elevator super_class: #4 // simula/runtime/RTS_Process interfaces: 0, fields: 7, methods: 3, attributes: 1 Constant pool: ... ... ClassFile written to: adHoc000_adHoc000_PBLK39_Elevator.class nBytes=1382 Begin buildClassFile: ClassDesc[adHoc000_adHoc000_PBLK39_Floor] public class simulaTestPrograms.adHoc000_adHoc000_PBLK39_Floor extends simula.runtime.RTS_CLASS flags: (0x0021) ACC_PUBLIC, ACC_SUPER this_class: #2 // simulaTestPrograms/adHoc000_adHoc000_PBLK39_Floor super_class: #4 // simula/runtime/RTS_CLASS interfaces: 0, fields: 5, methods: 2, attributes: 1 Constant pool: ... ... Begin buildClassFile: ClassDesc[adHoc000_adHoc000_PBLK39_Floor_activateIdleLift] public final class simulaTestPrograms.adHoc000_adHoc000_PBLK39_Floor_activateIdleLift extends simula.runtime.RTS_PROCEDURE flags: (0x0031) ACC_PUBLIC, ACC_FINAL, ACC_SUPER this_class: #2 // simulaTestPrograms/adHoc000_adHoc000_PBLK39_Floor_activateIdleLift super_class: #4 // simula/runtime/RTS_PROCEDURE interfaces: 0, fields: 2, methods: 2, attributes: 1 Constant pool: ... ... Begin buildClassFile: ClassDesc[adHoc000$THUNK$1] public class simulaTestPrograms.adHoc000$THUNK$1 extends simula.runtime.RTS_NAME flags: (0x0031) ACC_PUBLIC, ACC_FINAL, ACC_SUPER this_class: #2 // simulaTestPrograms/adHoc000$THUNK$1 super_class: #4 // simula/runtime/RTS_NAME interfaces: 0, fields: 0, methods: 4, attributes: 2 Constant pool: ... ... ClassFile written to: adHoc000$THUNK$1.class NOTE: THUNK2-5 very like THUNK1 Begin buildClassFile: ClassDesc[adHoc000$THUNK$2] ClassFile written to: adHoc000$THUNK$2.class Begin buildClassFile: ClassDesc[adHoc000$THUNK$3] ClassFile written to: adHoc000$THUNK$3.class Begin buildClassFile: ClassDesc[adHoc000$THUNK$4] ClassFile written to: adHoc000$THUNK$4.class Begin buildClassFile: ClassDesc[adHoc000$THUNK$5] ClassFile written to: adHoc000$THUNK$5.class NOTE: When the classFile Builder is closing: adHoc000_adHoc000_PBLK39_Floor_activateIdleLift I got an exception: Exception in thread "main" java.lang.IllegalArgumentException: Could not resolve class adHoc000_adHoc000_PBLK39_Floor_activateIdleLift at java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.resolve(ClassHierarchyImpl.java:75) at java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.isInterface(ClassHierarchyImpl.java:85) at java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeReferenceFrom(StackMapGenerator.java:1363) at java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeFrom(StackMapGenerator.java:1331) at java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.merge(StackMapGenerator.java:1193) at java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.checkAssignableTo(StackMapGenerator.java:1135) at java.base/jdk.internal.classfile.impl.StackMapGenerator.checkJumpTarget(StackMapGenerator.java:280) at java.base/jdk.internal.classfile.impl.StackMapGenerator.processExceptionHandlerTargets(StackMapGenerator.java:678) at java.base/jdk.internal.classfile.impl.StackMapGenerator.processBlock(StackMapGenerator.java:667) at java.base/jdk.internal.classfile.impl.StackMapGenerator.processMethod(StackMapGenerator.java:440) at java.base/jdk.internal.classfile.impl.StackMapGenerator.generate(StackMapGenerator.java:317) at java.base/jdk.internal.classfile.impl.StackMapGenerator.(StackMapGenerator.java:243) at java.base/jdk.internal.classfile.impl.StackMapGenerator.of(StackMapGenerator.java:156) at java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.generateStackMaps(DirectCodeBuilder.java:331) at java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.tryGenerateStackMaps(DirectCodeBuilder.java:340) at java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.writeBody(DirectCodeBuilder.java:382) at java.base/jdk.internal.classfile.impl.UnboundAttribute$AdHocAttribute.writeTo(UnboundAttribute.java:914) at java.base/jdk.internal.classfile.impl.AttributeHolder.writeTo(AttributeHolder.java:56) at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.writeTo(DirectMethodBuilder.java:156) at java.base/jdk.internal.classfile.impl.BufWriterImpl.writeList(BufWriterImpl.java:207) at java.base/jdk.internal.classfile.impl.DirectClassBuilder.build(DirectClassBuilder.java:181) at java.base/jdk.internal.classfile.impl.ClassFileImpl.build(ClassFileImpl.java:114) at java.base/java.lang.classfile.ClassFile.build(ClassFile.java:332) at simula.compiler.syntaxClass.declaration.ProcedureDeclaration.buildClassFile(ProcedureDeclaration.java:585) at simula.compiler.syntaxClass.declaration.BlockDeclaration.createJavaClassFile(BlockDeclaration.java:386) at simula.compiler.syntaxClass.declaration.ProcedureDeclaration.buildField(ProcedureDeclaration.java:991) at simula.compiler.syntaxClass.declaration.ClassDeclaration.lambda$0(ClassDeclaration.java:1251) at java.base/jdk.internal.classfile.impl.ClassFileImpl.build(ClassFileImpl.java:113) at java.base/java.lang.classfile.ClassFile.build(ClassFile.java:332) at simula.compiler.syntaxClass.declaration.ClassDeclaration.buildClassFile(ClassDeclaration.java:1241) at simula.compiler.syntaxClass.declaration.BlockDeclaration.createJavaClassFile(BlockDeclaration.java:386) at simula.compiler.syntaxClass.declaration.ClassDeclaration.buildField(ClassDeclaration.java:1426) at simula.compiler.syntaxClass.declaration.PrefixedBlockDeclaration.lambda$0(PrefixedBlockDeclaration.java:305) at java.base/jdk.internal.classfile.impl.ClassFileImpl.build(ClassFileImpl.java:113) at java.base/java.lang.classfile.ClassFile.build(ClassFile.java:332) at simula.compiler.syntaxClass.declaration.PrefixedBlockDeclaration.buildClassFile(PrefixedBlockDeclaration.java:296) at simula.compiler.syntaxClass.declaration.BlockDeclaration.createJavaClassFile(BlockDeclaration.java:386) at simula.compiler.syntaxClass.declaration.PrefixedBlockDeclaration.buildByteCode(PrefixedBlockDeclaration.java:252) at simula.compiler.syntaxClass.statement.BlockStatement.buildByteCode(BlockStatement.java:130) at simula.compiler.syntaxClass.declaration.ClassDeclaration.buildStatementsAfterInner(ClassDeclaration.java:1523) at simula.compiler.syntaxClass.declaration.ClassDeclaration.build_STM_BODY(ClassDeclaration.java:1478) at simula.compiler.syntaxClass.declaration.BlockDeclaration.buildMethod_STM(BlockDeclaration.java:491) at simula.compiler.syntaxClass.declaration.PrefixedBlockDeclaration.lambda$2(PrefixedBlockDeclaration.java:324) at java.base/jdk.internal.classfile.impl.DirectCodeBuilder.build(DirectCodeBuilder.java:110) at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.withCode(DirectMethodBuilder.java:125) at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.withCode(DirectMethodBuilder.java:132) at java.base/java.lang.classfile.ClassBuilder.lambda$withMethodBody$2(ClassBuilder.java:249) at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.run(DirectMethodBuilder.java:146) at java.base/jdk.internal.classfile.impl.DirectClassBuilder.withMethod(DirectClassBuilder.java:108) at java.base/java.lang.classfile.ClassBuilder.withMethodBody(ClassBuilder.java:249) at java.base/java.lang.classfile.ClassBuilder.withMethodBody(ClassBuilder.java:284) at simula.compiler.syntaxClass.declaration.PrefixedBlockDeclaration.lambda$0(PrefixedBlockDeclaration.java:323) at java.base/jdk.internal.classfile.impl.ClassFileImpl.build(ClassFileImpl.java:113) at java.base/java.lang.classfile.ClassFile.build(ClassFile.java:332) at simula.compiler.syntaxClass.declaration.PrefixedBlockDeclaration.buildClassFile(PrefixedBlockDeclaration.java:296) at simula.compiler.syntaxClass.declaration.BlockDeclaration.createJavaClassFile(BlockDeclaration.java:386) at simula.compiler.syntaxClass.statement.ProgramModule.createJavaClassFile(ProgramModule.java:175) at simula.compiler.SimulaCompiler.doCompile(SimulaCompiler.java:309) at make.RunClassFileTest.main(RunClassFileTest.java:358) From adam.sotona at oracle.com Mon Apr 29 07:54:42 2024 From: adam.sotona at oracle.com (Adam Sotona) Date: Mon, 29 Apr 2024 07:54:42 +0000 Subject: Got: IllegalArgumentException: Could not resolve class In-Reply-To: References: Message-ID: Your compiler reached the complexity where you reference generated classes from other generated classes. Class-File API in certain circumstances needs to know some information about the classes referenced from the generated bytecode. Such information is provided in ClassHierarchyInfo using functional interface ClassHierarchyResolver. By default is the information obtained from system class loader. However, the classes you generate are probably not yet known to the system class loader. You should specify a custom ClassHierarchyResolver for your compiler as a Class-File API option `ClassFile.of(ClassFile.ClassHierarchyResolverOption.of(...))`. Here you have multiple options how to provide the missing information using combinations of ClassHierarchyResolver factory methods and custom code: For example, if the required classes have been already generated and you can provide a physical access to them, you can compose the ClassHierarchyResolver this way: `ClassHierarchyResolver.defaultResolver().orElse(ClassHierarchyResolver. ofResourceParsing(Function).cached())` Or if you know all the generated classes in advance, you can provide the missing info about the generated classes in a set and map form: `ClassHierarchyResolver.defaultResolver().orElse(ClassHierarchyResolver. of(Collection interfaces, Map classToSuperClass))` Or in a form of dynamic direct implementation of the ClassHierarchyResolver: `ClassHierarchyResolver.defaultResolver().orElse(classDesc -> isInterface ? : ClassHierarchyInfo.ofInterface() : ClassHierarchyInfo.ofClass(ClassDesc superClass))` From: classfile-api-dev on behalf of ?ystein Myhre Andersen Date: Sunday, 28 April 2024 at 12:53 To: classfile-api-dev at openjdk.org Subject: Got: IllegalArgumentException: Could not resolve class I'm writing a compiler for Simula (the very first oo language). Simula is block-oriented with nested blocks and each block is compiled into a classFile. At a certain level in the hierarchy I get an exception at the end of the classfile building. Exception in thread "main" java.lang.IllegalArgumentException: Could not resolve class adHoc000_adHoc000_PBLK39_Floor_activateIdleLift at java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.resolve(ClassHierarchyImpl.java:75) at java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.isInterface(ClassHierarchyImpl.java:85) at java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeReferenceFrom(StackMapGenerator.java:1363) at java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeFrom(StackMapGenerator.java:1331) at java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.merge(StackMapGenerator.java:1193) at java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.checkAssignableTo(StackMapGenerator.java:1135) at java.base/jdk.internal.classfile.impl.StackMapGenerator.checkJumpTarget(StackMapGenerator.java:280) at java.base/jdk.internal.classfile.impl.StackMapGenerator.processExceptionHandlerTargets(StackMapGenerator.java:678) at java.base/jdk.internal.classfile.impl.StackMapGenerator.processBlock(StackMapGenerator.java:667) at java.base/jdk.internal.classfile.impl.StackMapGenerator.processMethod(StackMapGenerator.java:440) at java.base/jdk.internal.classfile.impl.StackMapGenerator.generate(StackMapGenerator.java:317) at java.base/jdk.internal.classfile.impl.StackMapGenerator.(StackMapGenerator.java:243) at java.base/jdk.internal.classfile.impl.StackMapGenerator.of(StackMapGenerator.java:156) at java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.generateStackMaps(DirectCodeBuilder.java:331) at java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.tryGenerateStackMaps(DirectCodeBuilder.java:340) at java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.writeBody(DirectCodeBuilder.java:382) at java.base/jdk.internal.classfile.impl.UnboundAttribute$AdHocAttribute.writeTo(UnboundAttribute.java:914) at java.base/jdk.internal.classfile.impl.AttributeHolder.writeTo(AttributeHolder.java:56) at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.writeTo(DirectMethodBuilder.java:156) at java.base/jdk.internal.classfile.impl.BufWriterImpl.writeList(BufWriterImpl.java:207) at java.base/jdk.internal.classfile.impl.DirectClassBuilder.build(DirectClassBuilder.java:181) at java.base/jdk.internal.classfile.impl.ClassFileImpl.build(ClassFileImpl.java:114) ... ... Is this a known problem? What am I doing wrong? I am attaching a file with an edited trace leading up to the exception. - ?ystein Myhre Andersen -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Mon Apr 29 11:54:25 2024 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 29 Apr 2024 07:54:25 -0400 Subject: Got: IllegalArgumentException: Could not resolve class In-Reply-To: References: Message-ID: In addition, we should look into making the error mode more obvious; an IAE like this one looks very much like an internal bug.? It would be good if the exception was (a) a more specific type of exception, and (b) had more detail of the sort "I needed class hierarchy information for X but it wasn't provided." On 4/29/2024 3:54 AM, Adam Sotona wrote: > > Your compiler reached the complexity where you reference generated > classes from other generated classes. > > Class-File API in certain circumstances needs to know some information > about the classes referenced from the generated bytecode. > > Such information is provided in ClassHierarchyInfo > > using functional interface ClassHierarchyResolver > . > > By default > > is the information obtained from system class loader. However, the > classes you generate are probably not yet known to the system class > loader. > > You should specify a custom ClassHierarchyResolver > > for your compiler as a Class-File API option > `ClassFile.of(ClassFile.ClassHierarchyResolverOption.of(...))`. > > Here you have multiple options how to provide the missing information > using combinations of ClassHierarchyResolver factory methods and > custom code: > > For example, if the required classes have been already generated and > you can provide a physical access to them, you can compose the > ClassHierarchyResolver this way: > > `ClassHierarchyResolver.defaultResolver().orElse(ClassHierarchyResolver. > ofResourceParsing(Function).cached())` > > Or if you know all the generated classes in advance, you can provide > the missing info about the generated classes in a set and map form: > > `ClassHierarchyResolver.defaultResolver().orElse(ClassHierarchyResolver. > of(Collection interfaces, Map > classToSuperClass))` > > Or in a form of dynamic direct implementation of the > ClassHierarchyResolver: > > `ClassHierarchyResolver.defaultResolver().orElse(classDesc -> > isInterface ? : ClassHierarchyInfo.ofInterface() : > ClassHierarchyInfo.ofClass(ClassDesc superClass))` > > *From: *classfile-api-dev on > behalf of ?ystein Myhre Andersen > *Date: *Sunday, 28 April 2024 at 12:53 > *To: *classfile-api-dev at openjdk.org > *Subject: *Got: IllegalArgumentException: Could not resolve class > > I'm writing a compiler for Simula (the very first oo language). > Simula is block-oriented with nested blocks and each block is compiled > into a classFile. > At a certain level in the hierarchy I get an exception at the end of > the classfile building. > > Exception in thread "main" java.lang.IllegalArgumentException: > ? ? ? ? ? ? ?Could not resolve class > adHoc000_adHoc000_PBLK39_Floor_activateIdleLift > > at > java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.resolve(ClassHierarchyImpl.java:75) > at > java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.isInterface(ClassHierarchyImpl.java:85) > at > java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeReferenceFrom(StackMapGenerator.java:1363) > at > java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeFrom(StackMapGenerator.java:1331) > at > java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.merge(StackMapGenerator.java:1193) > at > java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.checkAssignableTo(StackMapGenerator.java:1135) > at > java.base/jdk.internal.classfile.impl.StackMapGenerator.checkJumpTarget(StackMapGenerator.java:280) > at > java.base/jdk.internal.classfile.impl.StackMapGenerator.processExceptionHandlerTargets(StackMapGenerator.java:678) > at > java.base/jdk.internal.classfile.impl.StackMapGenerator.processBlock(StackMapGenerator.java:667) > at > java.base/jdk.internal.classfile.impl.StackMapGenerator.processMethod(StackMapGenerator.java:440) > at > java.base/jdk.internal.classfile.impl.StackMapGenerator.generate(StackMapGenerator.java:317) > at > java.base/jdk.internal.classfile.impl.StackMapGenerator.(StackMapGenerator.java:243) > at > java.base/jdk.internal.classfile.impl.StackMapGenerator.of(StackMapGenerator.java:156) > at > java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.generateStackMaps(DirectCodeBuilder.java:331) > at > java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.tryGenerateStackMaps(DirectCodeBuilder.java:340) > at > java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.writeBody(DirectCodeBuilder.java:382) > at > java.base/jdk.internal.classfile.impl.UnboundAttribute$AdHocAttribute.writeTo(UnboundAttribute.java:914) > at > java.base/jdk.internal.classfile.impl.AttributeHolder.writeTo(AttributeHolder.java:56) > at > java.base/jdk.internal.classfile.impl.DirectMethodBuilder.writeTo(DirectMethodBuilder.java:156) > at > java.base/jdk.internal.classfile.impl.BufWriterImpl.writeList(BufWriterImpl.java:207) > at > java.base/jdk.internal.classfile.impl.DirectClassBuilder.build(DirectClassBuilder.java:181) > at > java.base/jdk.internal.classfile.impl.ClassFileImpl.build(ClassFileImpl.java:114) > > ... ... > > > Is this a known problem? > > What am I doing wrong? > > I am attaching a file with an edited trace leading up to the exception. > > - ?ystein Myhre Andersen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liangchenblue at gmail.com Mon Apr 29 11:56:55 2024 From: liangchenblue at gmail.com (-) Date: Mon, 29 Apr 2024 06:56:55 -0500 Subject: Got: IllegalArgumentException: Could not resolve class In-Reply-To: References: Message-ID: I think a compiler should avoid the use of defaultResolver() in the resolver chain, as it adds a dependency on the compiler's runtime, while the program may target another set of standard libraries (such as for an older Java release). The dynamic direct implementation usually is the most flexible if you may have unanticipated inputs, as ClassHierarchyResolver implementations throw exceptions when they receive erroneous input class descs. On Mon, Apr 29, 2024 at 2:54?AM Adam Sotona wrote: > Your compiler reached the complexity where you reference generated classes > from other generated classes. > > Class-File API in certain circumstances needs to know some information > about the classes referenced from the generated bytecode. > > Such information is provided in ClassHierarchyInfo > > using functional interface ClassHierarchyResolver > > . > > > > By default > > is the information obtained from system class loader. However, the classes > you generate are probably not yet known to the system class loader. > > You should specify a custom ClassHierarchyResolver > > for your compiler as a Class-File API option > `ClassFile.of(ClassFile.ClassHierarchyResolverOption.of(...))`. > > > > Here you have multiple options how to provide the missing information > using combinations of ClassHierarchyResolver factory methods and custom > code: > > > > For example, if the required classes have been already generated and you > can provide a physical access to them, you can compose the > ClassHierarchyResolver this way: > > `ClassHierarchyResolver.defaultResolver().orElse(ClassHierarchyResolver. ofResourceParsing(Function InputStream>).cached())` > > > > Or if you know all the generated classes in advance, you can provide the > missing info about the generated classes in a set and map form: > > `ClassHierarchyResolver.defaultResolver().orElse(ClassHierarchyResolver. of(Collection > interfaces, Map classToSuperClass))` > > > > Or in a form of dynamic direct implementation of the > ClassHierarchyResolver: > > `ClassHierarchyResolver.defaultResolver().orElse(classDesc -> isInterface > ? : ClassHierarchyInfo.ofInterface() : ClassHierarchyInfo.ofClass(ClassDesc > superClass))` > > > > > > > > *From: *classfile-api-dev on behalf > of ?ystein Myhre Andersen > *Date: *Sunday, 28 April 2024 at 12:53 > *To: *classfile-api-dev at openjdk.org > *Subject: *Got: IllegalArgumentException: Could not resolve class > > I'm writing a compiler for Simula (the very first oo language). > Simula is block-oriented with nested blocks and each block is compiled > into a classFile. > At a certain level in the hierarchy I get an exception at the end of the > classfile building. > > > > Exception in thread "main" java.lang.IllegalArgumentException: > Could not resolve class > adHoc000_adHoc000_PBLK39_Floor_activateIdleLift > > at > java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.resolve(ClassHierarchyImpl.java:75) > at > java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.isInterface(ClassHierarchyImpl.java:85) > at > java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeReferenceFrom(StackMapGenerator.java:1363) > at > java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeFrom(StackMapGenerator.java:1331) > at > java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.merge(StackMapGenerator.java:1193) > at > java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.checkAssignableTo(StackMapGenerator.java:1135) > at > java.base/jdk.internal.classfile.impl.StackMapGenerator.checkJumpTarget(StackMapGenerator.java:280) > at > java.base/jdk.internal.classfile.impl.StackMapGenerator.processExceptionHandlerTargets(StackMapGenerator.java:678) > at > java.base/jdk.internal.classfile.impl.StackMapGenerator.processBlock(StackMapGenerator.java:667) > at > java.base/jdk.internal.classfile.impl.StackMapGenerator.processMethod(StackMapGenerator.java:440) > at > java.base/jdk.internal.classfile.impl.StackMapGenerator.generate(StackMapGenerator.java:317) > at > java.base/jdk.internal.classfile.impl.StackMapGenerator.(StackMapGenerator.java:243) > at > java.base/jdk.internal.classfile.impl.StackMapGenerator.of(StackMapGenerator.java:156) > at > java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.generateStackMaps(DirectCodeBuilder.java:331) > at > java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.tryGenerateStackMaps(DirectCodeBuilder.java:340) > at > java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.writeBody(DirectCodeBuilder.java:382) > at > java.base/jdk.internal.classfile.impl.UnboundAttribute$AdHocAttribute.writeTo(UnboundAttribute.java:914) > at > java.base/jdk.internal.classfile.impl.AttributeHolder.writeTo(AttributeHolder.java:56) > at > java.base/jdk.internal.classfile.impl.DirectMethodBuilder.writeTo(DirectMethodBuilder.java:156) > at > java.base/jdk.internal.classfile.impl.BufWriterImpl.writeList(BufWriterImpl.java:207) > at > java.base/jdk.internal.classfile.impl.DirectClassBuilder.build(DirectClassBuilder.java:181) > at > java.base/jdk.internal.classfile.impl.ClassFileImpl.build(ClassFileImpl.java:114) > > ... ... > > > Is this a known problem? > > What am I doing wrong? > > > > I am attaching a file with an edited trace leading up to the exception. > > > > - ?ystein Myhre Andersen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From o.myhre at gmail.com Mon Apr 29 12:39:22 2024 From: o.myhre at gmail.com (=?UTF-8?Q?=C3=98ystein_Myhre_Andersen?=) Date: Mon, 29 Apr 2024 14:39:22 +0200 Subject: Got: IllegalArgumentException: Could not resolve class In-Reply-To: References: Message-ID: I solved my problem by using: `ClassHierarchyResolver.defaultResolver().orElse(ClassHierarchyResolver. of(Collection interfaces, Map classToSuperClass))` However; since I do not have any interfaces I got an error with interfaces == null. And the javadoc could state which ClassDesc argument to Map classToSuperClass) is the super. On Mon, Apr 29, 2024 at 1:57?PM - wrote: > I think a compiler should avoid the use of defaultResolver() in the > resolver chain, as it adds a dependency on the compiler's runtime, while > the program may target another set of standard libraries (such as for an > older Java release). The dynamic direct implementation usually is the most > flexible if you may have unanticipated inputs, as ClassHierarchyResolver > implementations throw exceptions when they receive erroneous input class > descs. > > On Mon, Apr 29, 2024 at 2:54?AM Adam Sotona > wrote: > >> Your compiler reached the complexity where you reference generated >> classes from other generated classes. >> >> Class-File API in certain circumstances needs to know some information >> about the classes referenced from the generated bytecode. >> >> Such information is provided in ClassHierarchyInfo >> >> using functional interface ClassHierarchyResolver >> >> . >> >> >> >> By default >> >> is the information obtained from system class loader. However, the classes >> you generate are probably not yet known to the system class loader. >> >> You should specify a custom ClassHierarchyResolver >> >> for your compiler as a Class-File API option >> `ClassFile.of(ClassFile.ClassHierarchyResolverOption.of(...))`. >> >> >> >> Here you have multiple options how to provide the missing information >> using combinations of ClassHierarchyResolver factory methods and custom >> code: >> >> >> >> For example, if the required classes have been already generated and you >> can provide a physical access to them, you can compose the >> ClassHierarchyResolver this way: >> >> `ClassHierarchyResolver.defaultResolver().orElse(ClassHierarchyResolver. ofResourceParsing(Function> InputStream>).cached())` >> >> >> >> Or if you know all the generated classes in advance, you can provide the >> missing info about the generated classes in a set and map form: >> >> `ClassHierarchyResolver.defaultResolver().orElse(ClassHierarchyResolver. of(Collection >> interfaces, Map classToSuperClass))` >> >> >> >> Or in a form of dynamic direct implementation of the >> ClassHierarchyResolver: >> >> `ClassHierarchyResolver.defaultResolver().orElse(classDesc -> isInterface >> ? : ClassHierarchyInfo.ofInterface() : ClassHierarchyInfo.ofClass(ClassDesc >> superClass))` >> >> >> >> >> >> >> >> *From: *classfile-api-dev on behalf >> of ?ystein Myhre Andersen >> *Date: *Sunday, 28 April 2024 at 12:53 >> *To: *classfile-api-dev at openjdk.org >> *Subject: *Got: IllegalArgumentException: Could not resolve class >> >> I'm writing a compiler for Simula (the very first oo language). >> Simula is block-oriented with nested blocks and each block is compiled >> into a classFile. >> At a certain level in the hierarchy I get an exception at the end of the >> classfile building. >> >> >> >> Exception in thread "main" java.lang.IllegalArgumentException: >> Could not resolve class >> adHoc000_adHoc000_PBLK39_Floor_activateIdleLift >> >> at >> java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.resolve(ClassHierarchyImpl.java:75) >> at >> java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.isInterface(ClassHierarchyImpl.java:85) >> at >> java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeReferenceFrom(StackMapGenerator.java:1363) >> at >> java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeFrom(StackMapGenerator.java:1331) >> at >> java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.merge(StackMapGenerator.java:1193) >> at >> java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.checkAssignableTo(StackMapGenerator.java:1135) >> at >> java.base/jdk.internal.classfile.impl.StackMapGenerator.checkJumpTarget(StackMapGenerator.java:280) >> at >> java.base/jdk.internal.classfile.impl.StackMapGenerator.processExceptionHandlerTargets(StackMapGenerator.java:678) >> at >> java.base/jdk.internal.classfile.impl.StackMapGenerator.processBlock(StackMapGenerator.java:667) >> at >> java.base/jdk.internal.classfile.impl.StackMapGenerator.processMethod(StackMapGenerator.java:440) >> at >> java.base/jdk.internal.classfile.impl.StackMapGenerator.generate(StackMapGenerator.java:317) >> at >> java.base/jdk.internal.classfile.impl.StackMapGenerator.(StackMapGenerator.java:243) >> at >> java.base/jdk.internal.classfile.impl.StackMapGenerator.of(StackMapGenerator.java:156) >> at >> java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.generateStackMaps(DirectCodeBuilder.java:331) >> at >> java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.tryGenerateStackMaps(DirectCodeBuilder.java:340) >> at >> java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.writeBody(DirectCodeBuilder.java:382) >> at >> java.base/jdk.internal.classfile.impl.UnboundAttribute$AdHocAttribute.writeTo(UnboundAttribute.java:914) >> at >> java.base/jdk.internal.classfile.impl.AttributeHolder.writeTo(AttributeHolder.java:56) >> at >> java.base/jdk.internal.classfile.impl.DirectMethodBuilder.writeTo(DirectMethodBuilder.java:156) >> at >> java.base/jdk.internal.classfile.impl.BufWriterImpl.writeList(BufWriterImpl.java:207) >> at >> java.base/jdk.internal.classfile.impl.DirectClassBuilder.build(DirectClassBuilder.java:181) >> at >> java.base/jdk.internal.classfile.impl.ClassFileImpl.build(ClassFileImpl.java:114) >> >> ... ... >> >> >> Is this a known problem? >> >> What am I doing wrong? >> >> >> >> I am attaching a file with an edited trace leading up to the exception. >> >> >> >> - ?ystein Myhre Andersen >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From o.myhre at gmail.com Mon Apr 29 13:23:24 2024 From: o.myhre at gmail.com (=?UTF-8?Q?=C3=98ystein_Myhre_Andersen?=) Date: Mon, 29 Apr 2024 15:23:24 +0200 Subject: Got: IllegalArgumentException: Could not resolve class In-Reply-To: References: Message-ID: Proposal: I defined a utility class: public abstract class ClassHierarchy { private static Map classToSuperClass = new HashMap(); private static Collection interfaces = new Vector(); public static ClassHierarchyResolver getResolver() { ClassHierarchyResolver res = ClassHierarchyResolver.defaultResolver() .orElse(ClassHierarchyResolver.of(interfaces, classToSuperClass)); return res; } public static void addClassToSuperClass(ClassDesc cld, ClassDesc sup) { classToSuperClass.put(cld, sup); } } And built my class files with a method like: public byte[] buildClassFile() { ClassDesc CD_ThisClass = ... ClassDesc CD_SuperClass = ... ClassHierarchy.addClassToSuperClass(CD_ThisClass, CD_SuperClass); byte[] bytes = ClassFile.of(ClassFile.ClassHierarchyResolverOption .of(ClassHierarchy.getResolver())).build(CD_ThisClass, classBuilder -> { classBuilder .withSuperclass(CD_SuperClass); ... ... This could perhaps have been done internally by letting .withSuperclass( CD_SuperClass); make a call ala ClassHierarchy.addClassToSuperClass(CD_ThisClass, CD_SuperClass); On Mon, Apr 29, 2024 at 2:39?PM ?ystein Myhre Andersen wrote: > I solved my problem by using: > `ClassHierarchyResolver.defaultResolver().orElse(ClassHierarchyResolver. > > of(Collection interfaces, Map > classToSuperClass))` > > However; since I do not have any interfaces I got an error with interfaces > == null. And the javadoc could state which ClassDesc argument to Map ClassDesc> classToSuperClass) is the super. > > On Mon, Apr 29, 2024 at 1:57?PM - wrote: > >> I think a compiler should avoid the use of defaultResolver() in the >> resolver chain, as it adds a dependency on the compiler's runtime, while >> the program may target another set of standard libraries (such as for an >> older Java release). The dynamic direct implementation usually is the most >> flexible if you may have unanticipated inputs, as ClassHierarchyResolver >> implementations throw exceptions when they receive erroneous input class >> descs. >> >> On Mon, Apr 29, 2024 at 2:54?AM Adam Sotona >> wrote: >> >>> Your compiler reached the complexity where you reference generated >>> classes from other generated classes. >>> >>> Class-File API in certain circumstances needs to know some information >>> about the classes referenced from the generated bytecode. >>> >>> Such information is provided in ClassHierarchyInfo >>> >>> using functional interface ClassHierarchyResolver >>> >>> . >>> >>> >>> >>> By default >>> >>> is the information obtained from system class loader. However, the classes >>> you generate are probably not yet known to the system class loader. >>> >>> You should specify a custom ClassHierarchyResolver >>> >>> for your compiler as a Class-File API option >>> `ClassFile.of(ClassFile.ClassHierarchyResolverOption.of(...))`. >>> >>> >>> >>> Here you have multiple options how to provide the missing information >>> using combinations of ClassHierarchyResolver factory methods and custom >>> code: >>> >>> >>> >>> For example, if the required classes have been already generated and you >>> can provide a physical access to them, you can compose the >>> ClassHierarchyResolver this way: >>> >>> `ClassHierarchyResolver.defaultResolver().orElse(ClassHierarchyResolver. ofResourceParsing(Function>> InputStream>).cached())` >>> >>> >>> >>> Or if you know all the generated classes in advance, you can provide the >>> missing info about the generated classes in a set and map form: >>> >>> `ClassHierarchyResolver.defaultResolver().orElse(ClassHierarchyResolver. of(Collection >>> interfaces, Map classToSuperClass))` >>> >>> >>> >>> Or in a form of dynamic direct implementation of the >>> ClassHierarchyResolver: >>> >>> `ClassHierarchyResolver.defaultResolver().orElse(classDesc -> >>> isInterface ? : ClassHierarchyInfo.ofInterface() : >>> ClassHierarchyInfo.ofClass(ClassDesc superClass))` >>> >>> >>> >>> >>> >>> >>> >>> *From: *classfile-api-dev on >>> behalf of ?ystein Myhre Andersen >>> *Date: *Sunday, 28 April 2024 at 12:53 >>> *To: *classfile-api-dev at openjdk.org >>> *Subject: *Got: IllegalArgumentException: Could not resolve class >>> >>> I'm writing a compiler for Simula (the very first oo language). >>> Simula is block-oriented with nested blocks and each block is compiled >>> into a classFile. >>> At a certain level in the hierarchy I get an exception at the end of the >>> classfile building. >>> >>> >>> >>> Exception in thread "main" java.lang.IllegalArgumentException: >>> Could not resolve class >>> adHoc000_adHoc000_PBLK39_Floor_activateIdleLift >>> >>> at >>> java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.resolve(ClassHierarchyImpl.java:75) >>> at >>> java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.isInterface(ClassHierarchyImpl.java:85) >>> at >>> java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeReferenceFrom(StackMapGenerator.java:1363) >>> at >>> java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeFrom(StackMapGenerator.java:1331) >>> at >>> java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.merge(StackMapGenerator.java:1193) >>> at >>> java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.checkAssignableTo(StackMapGenerator.java:1135) >>> at >>> java.base/jdk.internal.classfile.impl.StackMapGenerator.checkJumpTarget(StackMapGenerator.java:280) >>> at >>> java.base/jdk.internal.classfile.impl.StackMapGenerator.processExceptionHandlerTargets(StackMapGenerator.java:678) >>> at >>> java.base/jdk.internal.classfile.impl.StackMapGenerator.processBlock(StackMapGenerator.java:667) >>> at >>> java.base/jdk.internal.classfile.impl.StackMapGenerator.processMethod(StackMapGenerator.java:440) >>> at >>> java.base/jdk.internal.classfile.impl.StackMapGenerator.generate(StackMapGenerator.java:317) >>> at >>> java.base/jdk.internal.classfile.impl.StackMapGenerator.(StackMapGenerator.java:243) >>> at >>> java.base/jdk.internal.classfile.impl.StackMapGenerator.of(StackMapGenerator.java:156) >>> at >>> java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.generateStackMaps(DirectCodeBuilder.java:331) >>> at >>> java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.tryGenerateStackMaps(DirectCodeBuilder.java:340) >>> at >>> java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.writeBody(DirectCodeBuilder.java:382) >>> at >>> java.base/jdk.internal.classfile.impl.UnboundAttribute$AdHocAttribute.writeTo(UnboundAttribute.java:914) >>> at >>> java.base/jdk.internal.classfile.impl.AttributeHolder.writeTo(AttributeHolder.java:56) >>> at >>> java.base/jdk.internal.classfile.impl.DirectMethodBuilder.writeTo(DirectMethodBuilder.java:156) >>> at >>> java.base/jdk.internal.classfile.impl.BufWriterImpl.writeList(BufWriterImpl.java:207) >>> at >>> java.base/jdk.internal.classfile.impl.DirectClassBuilder.build(DirectClassBuilder.java:181) >>> at >>> java.base/jdk.internal.classfile.impl.ClassFileImpl.build(ClassFileImpl.java:114) >>> >>> ... ... >>> >>> >>> Is this a known problem? >>> >>> What am I doing wrong? >>> >>> >>> >>> I am attaching a file with an edited trace leading up to the exception. >>> >>> >>> >>> - ?ystein Myhre Andersen >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From liangchenblue at gmail.com Mon Apr 29 13:37:37 2024 From: liangchenblue at gmail.com (-) Date: Mon, 29 Apr 2024 08:37:37 -0500 Subject: Got: IllegalArgumentException: Could not resolve class In-Reply-To: References: Message-ID: Since ClassHierarchyResolver is not a sealed interface, you can make your own ClassHierarchy class non-utility and implement CHR and return the correct ClassHierarchyInfo or throw IAE. On Mon, Apr 29, 2024 at 8:23?AM ?ystein Myhre Andersen wrote: > Proposal: > > I defined a utility class: > > public abstract class ClassHierarchy { > > private static Map classToSuperClass = new > HashMap(); > > private static Collection interfaces = new Vector(); > > > public static ClassHierarchyResolver getResolver() { > > ClassHierarchyResolver res = ClassHierarchyResolver.defaultResolver() > > .orElse(ClassHierarchyResolver.of(interfaces, classToSuperClass)); > > return res; > > } > > > public static void addClassToSuperClass(ClassDesc cld, ClassDesc sup) { > > classToSuperClass.put(cld, sup); > > } > > } > > > And built my class files with a method like: > > public byte[] buildClassFile() { > > ClassDesc CD_ThisClass = ... > > ClassDesc CD_SuperClass = ... > > ClassHierarchy.addClassToSuperClass(CD_ThisClass, CD_SuperClass); > > byte[] bytes = ClassFile.of(ClassFile.ClassHierarchyResolverOption > > .of(ClassHierarchy.getResolver())).build(CD_ThisClass, > > classBuilder -> { > > classBuilder > > .withSuperclass(CD_SuperClass); > > ... ... > > > > This could perhaps have been done internally by letting > .withSuperclass(CD_SuperClass); > make a call ala ClassHierarchy.addClassToSuperClass(CD_ThisClass, > CD_SuperClass); > > On Mon, Apr 29, 2024 at 2:39?PM ?ystein Myhre Andersen > wrote: > >> I solved my problem by using: >> `ClassHierarchyResolver.defaultResolver().orElse(ClassHierarchyResolver. >> >> of(Collection interfaces, Map >> classToSuperClass))` >> >> However; since I do not have any interfaces I got an error with >> interfaces == null. And the javadoc could state which ClassDesc argument >> to Map classToSuperClass) is the super. >> >> On Mon, Apr 29, 2024 at 1:57?PM - wrote: >> >>> I think a compiler should avoid the use of defaultResolver() in the >>> resolver chain, as it adds a dependency on the compiler's runtime, while >>> the program may target another set of standard libraries (such as for an >>> older Java release). The dynamic direct implementation usually is the most >>> flexible if you may have unanticipated inputs, as ClassHierarchyResolver >>> implementations throw exceptions when they receive erroneous input class >>> descs. >>> >>> On Mon, Apr 29, 2024 at 2:54?AM Adam Sotona >>> wrote: >>> >>>> Your compiler reached the complexity where you reference generated >>>> classes from other generated classes. >>>> >>>> Class-File API in certain circumstances needs to know some information >>>> about the classes referenced from the generated bytecode. >>>> >>>> Such information is provided in ClassHierarchyInfo >>>> >>>> using functional interface ClassHierarchyResolver >>>> >>>> . >>>> >>>> >>>> >>>> By default >>>> >>>> is the information obtained from system class loader. However, the classes >>>> you generate are probably not yet known to the system class loader. >>>> >>>> You should specify a custom ClassHierarchyResolver >>>> >>>> for your compiler as a Class-File API option >>>> `ClassFile.of(ClassFile.ClassHierarchyResolverOption.of(...))`. >>>> >>>> >>>> >>>> Here you have multiple options how to provide the missing information >>>> using combinations of ClassHierarchyResolver factory methods and custom >>>> code: >>>> >>>> >>>> >>>> For example, if the required classes have been already generated and >>>> you can provide a physical access to them, you can compose the >>>> ClassHierarchyResolver this way: >>>> >>>> `ClassHierarchyResolver.defaultResolver().orElse(ClassHierarchyResolver. ofResourceParsing(Function>>> InputStream>).cached())` >>>> >>>> >>>> >>>> Or if you know all the generated classes in advance, you can provide >>>> the missing info about the generated classes in a set and map form: >>>> >>>> `ClassHierarchyResolver.defaultResolver().orElse(ClassHierarchyResolver. of(Collection >>>> interfaces, Map classToSuperClass))` >>>> >>>> >>>> >>>> Or in a form of dynamic direct implementation of the >>>> ClassHierarchyResolver: >>>> >>>> `ClassHierarchyResolver.defaultResolver().orElse(classDesc -> >>>> isInterface ? : ClassHierarchyInfo.ofInterface() : >>>> ClassHierarchyInfo.ofClass(ClassDesc superClass))` >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *From: *classfile-api-dev on >>>> behalf of ?ystein Myhre Andersen >>>> *Date: *Sunday, 28 April 2024 at 12:53 >>>> *To: *classfile-api-dev at openjdk.org >>>> *Subject: *Got: IllegalArgumentException: Could not resolve class >>>> >>>> I'm writing a compiler for Simula (the very first oo language). >>>> Simula is block-oriented with nested blocks and each block is compiled >>>> into a classFile. >>>> At a certain level in the hierarchy I get an exception at the end of >>>> the classfile building. >>>> >>>> >>>> >>>> Exception in thread "main" java.lang.IllegalArgumentException: >>>> Could not resolve class >>>> adHoc000_adHoc000_PBLK39_Floor_activateIdleLift >>>> >>>> at >>>> java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.resolve(ClassHierarchyImpl.java:75) >>>> at >>>> java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.isInterface(ClassHierarchyImpl.java:85) >>>> at >>>> java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeReferenceFrom(StackMapGenerator.java:1363) >>>> at >>>> java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeFrom(StackMapGenerator.java:1331) >>>> at >>>> java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.merge(StackMapGenerator.java:1193) >>>> at >>>> java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.checkAssignableTo(StackMapGenerator.java:1135) >>>> at >>>> java.base/jdk.internal.classfile.impl.StackMapGenerator.checkJumpTarget(StackMapGenerator.java:280) >>>> at >>>> java.base/jdk.internal.classfile.impl.StackMapGenerator.processExceptionHandlerTargets(StackMapGenerator.java:678) >>>> at >>>> java.base/jdk.internal.classfile.impl.StackMapGenerator.processBlock(StackMapGenerator.java:667) >>>> at >>>> java.base/jdk.internal.classfile.impl.StackMapGenerator.processMethod(StackMapGenerator.java:440) >>>> at >>>> java.base/jdk.internal.classfile.impl.StackMapGenerator.generate(StackMapGenerator.java:317) >>>> at >>>> java.base/jdk.internal.classfile.impl.StackMapGenerator.(StackMapGenerator.java:243) >>>> at >>>> java.base/jdk.internal.classfile.impl.StackMapGenerator.of(StackMapGenerator.java:156) >>>> at >>>> java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.generateStackMaps(DirectCodeBuilder.java:331) >>>> at >>>> java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.tryGenerateStackMaps(DirectCodeBuilder.java:340) >>>> at >>>> java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.writeBody(DirectCodeBuilder.java:382) >>>> at >>>> java.base/jdk.internal.classfile.impl.UnboundAttribute$AdHocAttribute.writeTo(UnboundAttribute.java:914) >>>> at >>>> java.base/jdk.internal.classfile.impl.AttributeHolder.writeTo(AttributeHolder.java:56) >>>> at >>>> java.base/jdk.internal.classfile.impl.DirectMethodBuilder.writeTo(DirectMethodBuilder.java:156) >>>> at >>>> java.base/jdk.internal.classfile.impl.BufWriterImpl.writeList(BufWriterImpl.java:207) >>>> at >>>> java.base/jdk.internal.classfile.impl.DirectClassBuilder.build(DirectClassBuilder.java:181) >>>> at >>>> java.base/jdk.internal.classfile.impl.ClassFileImpl.build(ClassFileImpl.java:114) >>>> >>>> ... ... >>>> >>>> >>>> Is this a known problem? >>>> >>>> What am I doing wrong? >>>> >>>> >>>> >>>> I am attaching a file with an edited trace leading up to the exception. >>>> >>>> >>>> >>>> - ?ystein Myhre Andersen >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Mon Apr 29 14:09:37 2024 From: adam.sotona at oracle.com (Adam Sotona) Date: Mon, 29 Apr 2024 14:09:37 +0000 Subject: [External] : Re: Got: IllegalArgumentException: Could not resolve class Message-ID: It is good point that information about thisClass and superClass should be implicitly forwarded to the class hierarchy resolution for thisClass build. Thank you, Adam From: ?ystein Myhre Andersen Date: Monday, 29 April 2024 at 15:23 To: liangchenblue at gmail.com Cc: Adam Sotona , classfile-api-dev at openjdk.org Subject: [External] : Re: Got: IllegalArgumentException: Could not resolve class Proposal: I defined a utility class: public abstract class ClassHierarchy { private static Map classToSuperClass = new HashMap(); private static Collection interfaces = new Vector(); public static ClassHierarchyResolver getResolver() { ClassHierarchyResolver res = ClassHierarchyResolver.defaultResolver() .orElse(ClassHierarchyResolver.of(interfaces, classToSuperClass)); return res; } public static void addClassToSuperClass(ClassDesc cld, ClassDesc sup) { classToSuperClass.put(cld, sup); } } And built my class files with a method like: public byte[] buildClassFile() { ClassDesc CD_ThisClass = ... ClassDesc CD_SuperClass = ... ClassHierarchy.addClassToSuperClass(CD_ThisClass, CD_SuperClass); byte[] bytes = ClassFile.of(ClassFile.ClassHierarchyResolverOption .of(ClassHierarchy.getResolver())).build(CD_ThisClass, classBuilder -> { classBuilder .withSuperclass(CD_SuperClass); ... ... This could perhaps have been done internally by letting .withSuperclass(CD_SuperClass); make a call ala ClassHierarchy.addClassToSuperClass(CD_ThisClass, CD_SuperClass); -------------- next part -------------- An HTML attachment was scrubbed... URL: From o.myhre at gmail.com Mon Apr 29 14:33:10 2024 From: o.myhre at gmail.com (=?UTF-8?Q?=C3=98ystein_Myhre_Andersen?=) Date: Mon, 29 Apr 2024 16:33:10 +0200 Subject: [External] : Re: Got: IllegalArgumentException: Could not resolve class In-Reply-To: References: Message-ID: Can you inform me if you incorporate this in the next release. - ?ystein On Mon, Apr 29, 2024 at 4:09?PM Adam Sotona wrote: > It is good point that information about thisClass and superClass should be > implicitly forwarded to the class hierarchy resolution for thisClass build. > > > > Thank you, > > Adam > > > > *From: *?ystein Myhre Andersen > *Date: *Monday, 29 April 2024 at 15:23 > *To: *liangchenblue at gmail.com > *Cc: *Adam Sotona , classfile-api-dev at openjdk.org > > *Subject: *[External] : Re: Got: IllegalArgumentException: Could not > resolve class > > Proposal: > > > > I defined a utility class: > > > > *public* *abstract* *class* ClassHierarchy { > > *private* *static* Map *classToSuperClass* = *new* > HashMap(); > > *private* *static* Collection *interfaces* = *new* > Vector(); > > > > *public* *static* ClassHierarchyResolver getResolver() { > > ClassHierarchyResolver res = ClassHierarchyResolver.*defaultResolver*() > > .orElse(ClassHierarchyResolver.*of*(*interfaces*, *classToSuperClass*)); > > *return* res; > > } > > > > *public* *static* *void* addClassToSuperClass(ClassDesc cld, ClassDesc sup) > { > > *classToSuperClass*.put(cld, sup); > > } > > } > > > > And built my class files with a method like: > > > > *public* *byte*[] buildClassFile() { > > ClassDesc CD_ThisClass = ... > > ClassDesc CD_SuperClass = ... > > ClassHierarchy.*addClassToSuperClass*(CD_ThisClass, CD_SuperClass); > > *byte*[] bytes = ClassFile.*of*(ClassFile.ClassHierarchyResolverOption > > .*of*(ClassHierarchy.*getResolver*())).build(CD_ThisClass, > > classBuilder -> { > > classBuilder > > .withSuperclass(CD_SuperClass); > > ... ... > > > > > > This could perhaps have been done internally by letting > .withSuperclass(CD_SuperClass); > > make a call ala ClassHierarchy.*addClassToSuperClass*(CD_ThisClass, > CD_SuperClass); > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Mon Apr 29 14:33:08 2024 From: adam.sotona at oracle.com (Adam Sotona) Date: Mon, 29 Apr 2024 14:33:08 +0000 Subject: Got: IllegalArgumentException: Could not resolve class In-Reply-To: References: Message-ID: FYI: For tracking I've created https://bugs.openjdk.org/browse/JDK-8331317 From: Brian Goetz Date: Monday, 29 April 2024 at 13:54 To: Adam Sotona , ?ystein Myhre Andersen , classfile-api-dev at openjdk.org Subject: Re: Got: IllegalArgumentException: Could not resolve class In addition, we should look into making the error mode more obvious; an IAE like this one looks very much like an internal bug. It would be good if the exception was (a) a more specific type of exception, and (b) had more detail of the sort "I needed class hierarchy information for X but it wasn't provided." On 4/29/2024 3:54 AM, Adam Sotona wrote: Your compiler reached the complexity where you reference generated classes from other generated classes. Class-File API in certain circumstances needs to know some information about the classes referenced from the generated bytecode. Such information is provided in ClassHierarchyInfo using functional interface ClassHierarchyResolver. By default is the information obtained from system class loader. However, the classes you generate are probably not yet known to the system class loader. You should specify a custom ClassHierarchyResolver for your compiler as a Class-File API option `ClassFile.of(ClassFile.ClassHierarchyResolverOption.of(...))`. Here you have multiple options how to provide the missing information using combinations of ClassHierarchyResolver factory methods and custom code: For example, if the required classes have been already generated and you can provide a physical access to them, you can compose the ClassHierarchyResolver this way: `ClassHierarchyResolver.defaultResolver().orElse(ClassHierarchyResolver. ofResourceParsing(Function).cached())` Or if you know all the generated classes in advance, you can provide the missing info about the generated classes in a set and map form: `ClassHierarchyResolver.defaultResolver().orElse(ClassHierarchyResolver. of(Collection interfaces, Map classToSuperClass))` Or in a form of dynamic direct implementation of the ClassHierarchyResolver: `ClassHierarchyResolver.defaultResolver().orElse(classDesc -> isInterface ? : ClassHierarchyInfo.ofInterface() : ClassHierarchyInfo.ofClass(ClassDesc superClass))` From: classfile-api-dev on behalf of ?ystein Myhre Andersen Date: Sunday, 28 April 2024 at 12:53 To: classfile-api-dev at openjdk.org Subject: Got: IllegalArgumentException: Could not resolve class I'm writing a compiler for Simula (the very first oo language). Simula is block-oriented with nested blocks and each block is compiled into a classFile. At a certain level in the hierarchy I get an exception at the end of the classfile building. Exception in thread "main" java.lang.IllegalArgumentException: Could not resolve class adHoc000_adHoc000_PBLK39_Floor_activateIdleLift -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Tue Apr 30 11:58:42 2024 From: adam.sotona at oracle.com (Adam Sotona) Date: Tue, 30 Apr 2024 11:58:42 +0000 Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot of static initializations In-Reply-To: References: Message-ID: Hi, During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers. One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers. I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class. Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23. Thank you, Adam ------------- Commit messages: - added impl comment - removed list of predefined attributes - move mappers implementations to AbstractAttributeMapper - 8331291: java.lang.classfile.Attributes class performs a lot of static initializations Changes: https://git.openjdk.org/jdk/pull/19006/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19006&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331291 CSR: https://bugs.openjdk.org/browse/JDK-8331414 Stats: 2029 lines in 47 files changed: 904 ins; 619 del; 506 mod Patch: https://git.openjdk.org/jdk/pull/19006.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19006/head:pull/19006 PR: https://git.openjdk.org/jdk/pull/19006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Tue Apr 30 12:44:34 2024 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 30 Apr 2024 08:44:34 -0400 Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot of static initializations In-Reply-To: References: Message-ID: <961c4780-756b-4793-b218-57efc0717b96@oracle.com> StableValue is coming soon, and the attributes is a great candidate for a lazy StableValue map. On 4/30/2024 7:58 AM, Adam Sotona wrote: > > Hi, > During performance optimization work on Class-File API as JDK lambda > generator we found some static initialization killers. > One of them is `java.lang.classfile.Attributes` with tens of static > fields initialized with individual attribute mappers, and common set > of all mappers, and static map from attribute names to the mappers. > > I propose to turn all the static fields into lazy-initialized static > methods and remove `PREDEFINED_ATTRIBUTES` and > `standardAttribute(Utf8Entry name)` static mapping method from the > `Attributes` API class. > > Please let me know your comments or objections and please review the > [PR](https://github.com/openjdk/jdk/pull/19006) and > [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it > into 23. > > Thank you, > Adam > > ------------- > > Commit messages: > ?- added impl comment > ?- removed list of predefined attributes > ?- move mappers implementations to AbstractAttributeMapper > ?- 8331291: java.lang.classfile.Attributes class performs a lot of > static initializations > > Changes: https://git.openjdk.org/jdk/pull/19006/files > ? Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19006&range=00 > > ? Issue: https://bugs.openjdk.org/browse/JDK-8331291 > > ?CSR: https://bugs.openjdk.org/browse/JDK-8331414 > ? Stats: 2029 lines in 47 files changed: 904 ins; 619 del; 506 mod > ? Patch: https://git.openjdk.org/jdk/pull/19006.diff > ? Fetch: git fetch https://git.openjdk.org/jdk.git > pull/19006/head:pull/19006 > > PR: https://git.openjdk.org/jdk/pull/19006 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.sotona at oracle.com Tue Apr 30 12:52:21 2024 From: adam.sotona at oracle.com (Adam Sotona) Date: Tue, 30 Apr 2024 12:52:21 +0000 Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot of static initializations In-Reply-To: <961c4780-756b-4793-b218-57efc0717b96@oracle.com> References: <961c4780-756b-4793-b218-57efc0717b96@oracle.com> Message-ID: Yes, we can replace currently proposed holder pattern implementation with StableValues when ready, without changes in the proposed Attributes class API. From: Brian Goetz Date: Tuesday, 30 April 2024 at 14:44 To: Adam Sotona , classfile-api-dev at openjdk.org Subject: Re: RFR: 8331291: java.lang.classfile.Attributes class performs a lot of static initializations StableValue is coming soon, and the attributes is a great candidate for a lazy StableValue map. On 4/30/2024 7:58 AM, Adam Sotona wrote: Hi, During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers. One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers. I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class. Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23. Thank you, Adam ------------- Commit messages: - added impl comment - removed list of predefined attributes - move mappers implementations to AbstractAttributeMapper - 8331291: java.lang.classfile.Attributes class performs a lot of static initializations Changes: https://git.openjdk.org/jdk/pull/19006/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19006&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331291 CSR: https://bugs.openjdk.org/browse/JDK-8331414 Stats: 2029 lines in 47 files changed: 904 ins; 619 del; 506 mod Patch: https://git.openjdk.org/jdk/pull/19006.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19006/head:pull/19006 PR: https://git.openjdk.org/jdk/pull/19006 -------------- next part -------------- An HTML attachment was scrubbed... URL: