[GR-53706] Behaviour of Class#getPackage()
in Native Image is different than Java for Proxy classes
#8796
Labels
Class#getPackage()
in Native Image is different than Java for Proxy classes
#8796
Describe the issue
If
Class#getPackage()
is called when a proxy class's classloader is null, Native Image creates and returns a newPackage
.Class#getPackage()
-->BootLoader#definePackage(Class<?> )
-->Target_jdk_internal_loader_BootLoader#getDefinedPackage(String)
-->Target_java_lang_Package(name, null, null, null,null, null, null, null, null);
However, in regular Java mode, if
Class#getPackage()
is called and the class's classloader isn't set, a package isn't necessarily returned.Steps to reproduce the issue
See here for a simple reproducer: https://github.com/roberttoyonaga/ProxyReproducer/tree/main
Describe GraalVM and your environment:
GraalVM for JDK 22 CE linux amd x64
More info
When
Class#getPackage()
is called on proxy classes in Java mode, a package is sometimes returned if the class's classloader has been set.This difference in behaviour is a problem for JFR because if
Class#getPackage()
returns null in hosted mode, that package will not be registered and will be excluded from the image heap. TheJfrSymbolRepository
relies on symbol strings residing in the image heap and having immovable addresses. At Native Image runtime, SubstrateVM may construct a package instance for a class that otherwise wouldn't have one in Java mode. JFR will then treat that package instance normally and assume it is in the image heap, when it may actually not be.The text was updated successfully, but these errors were encountered: