Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing netty and vert.x Reflective Classes #13

Open
dgrove-oss opened this issue Jan 20, 2023 · 4 comments
Open

Missing netty and vert.x Reflective Classes #13

dgrove-oss opened this issue Jan 20, 2023 · 4 comments

Comments

@dgrove-oss
Copy link
Contributor

dgrove-oss commented Jan 20, 2023

There's an annoyingly long and ad-hoc list of reflective classes that we've discovered by trial and error (ie, running quarkus and getting an exception) listed in https://github.com/qbicc/quarkus-qbicc/blob/main/deployment/src/main/resources/qbicc-feature.yaml.

We really should be getting this information from Quarkus during the build process. We need to determine which of the following is true:

  1. The information is available to us at build time, but we aren't processing it (or are processing it incorrectly).
  2. The information is available, but there's something in the configuration of knative-bench that is causing Quarkus to not tell us about it (missing extension???).
  3. There's some assumption being made in Quarkus about how GraalVM decides what classes/methods should be made reflectively available that is different than what qbicc is doing.
@dmlloyd
Copy link
Contributor

dmlloyd commented Jan 20, 2023

One thing is that I think we are missing some steps that are (incorrectly, in my opinion) annotated with onlyIf = NativeOrNativeSourcesBuild.class. For example NativeImageConfigBuildStep#reinitHostNameUtil is likely a direct cause for needing to manually list org.wildfly.common.net.HostName.

Another possible explanation is lack of support for GraalVM substitutions, though I didn't find any direct examples in my quick search of these classes.

@dgrove-oss
Copy link
Contributor Author

dgrove-oss commented Jan 20, 2023

I should note that there are still a few things that Quarkus is telling us that we are ignoring. Most of them are related to resources, but I think that HostName might be showing up as one of two classes listed in RuntimeReinitializedClassBuildItem, which we are currently dropping on the floor. Arguably we should at least be putting those classes into the RuntimeClasses list automatically.

@dgrove-oss
Copy link
Contributor Author

Check facts before writing... here's what we ignoring that actually pops up in knative-bench sleep:

[INFO] --- quarkus-maven-plugin:2.14.0.Final:build (default) @ sleep ---
TODO: QbiccProcessor: ignored runtime reinitialized class io.quarkus.netty.runtime.graal.Holder_io_netty_util_concurrent_ScheduledFutureTask
TODO: QbiccProcessor: ignored runtime reinitialized class sun.security.ssl.SSLLogger
TODO: QbiccProcessor: ignored resource exclude pattern: META-INF/quarkus-native-resources.txt
TODO: QbiccProcessor: ignored resource bundle sun.security.util.Resources

@dmlloyd
Copy link
Contributor

dmlloyd commented Jan 20, 2023

For runtime-reinitialized classes, it might work to set (using the patcher) a single initializer for all of the static fields of the class that is a duplicate of the class initializer. We might even be able to get away with using same initializer element.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants