Got: IllegalArgumentException: Could not resolve class

[Brian Goetz]

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 
> <https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/classfile/ClassHierarchyResolver.ClassHierarchyInfo.html> 
> using functional interface ClassHierarchyResolver 
> <https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/classfile/ClassHierarchyResolver.html>.
>
> By default 
> <https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/classfile/ClassHierarchyResolver.html#defaultResolver()> 
> 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 
> <https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/classfile/ClassHierarchyResolver.html> 
> 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<ClassDesc, 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<ClassDesc> interfaces, Map<ClassDesc, ClassDesc> 
> 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 <classfile-api-dev-retn at openjdk.org> on 
> behalf of Øystein Myhre Andersen <o.myhre at gmail.com>
> *Date: *Sunday, 28 April 2024 at 12:53
> *To: *classfile-api-dev at openjdk.org <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.<init>(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: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20240429/81c407ca/attachment.htm>