-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Netty PlatformDependent0.<init> uses DirectByteBuffer
reflectively
#37628
Netty PlatformDependent0.<init> uses DirectByteBuffer
reflectively
#37628
Conversation
Since we moved `io.netty.util.internal.PlatformDependent`'s and `io.netty.util.internal.PlatformDependent0`' initialization at runtime we need to register `java.nio.DirectByteBuffer`'s constructors for reflective access to avoid miss-configurations due to not being able to access the constructor in https://github.com/netty/netty/blob/5db037beedca8aa5b6a486fa515cc6af013ced74/common/src/main/java/io/netty/util/internal/PlatformDependent0.java#L290-L292 More classes and methods need to be registered as discussed in quarkusio#37626 Closes Karm/mandrel-integration-tests#236
FWIW setting See Karm/mandrel-integration-tests#236 (comment) Interestingly DirectByteBuffer's constructor is not reachable in JVM-mode, but it doesn't seem to cause any issues:
and the reason is that "Reflective setAccessible(true)" is disabled, which is what I would expect |
Switching to draft since I need to better understand what's going on. |
In quarkusio#37347 we moved `PlatformDependent` and `PlatformDependent0` classes to run-time-initialization as they are platform-dependent and thus need to be initialized on the target platform. It looks like there are more classes like these that need to be runtime initialized as they transitively rely on platform dependent values. Closes Karm/mandrel-integration-tests#236 Supersedes quarkusio#37628
Superseded by #37633 |
In quarkusio#37347 we moved `PlatformDependent` and `PlatformDependent0` classes to run-time-initialization as they are platform-dependent and thus need to be initialized on the target platform. It looks like there are more classes like these that need to be runtime initialized as they transitively rely on platform dependent values. Closes Karm/mandrel-integration-tests#236 Supersedes quarkusio#37628
In quarkusio#37347 we moved `PlatformDependent` and `PlatformDependent0` classes to run-time-initialization as they are platform-dependent and thus need to be initialized on the target platform. It looks like there are more classes like these that need to be runtime initialized as they transitively rely on platform dependent values. Closes Karm/mandrel-integration-tests#236 Supersedes quarkusio#37628 (cherry picked from commit 72d7b79)
Since we moved
io.netty.util.internal.PlatformDependent
's andio.netty.util.internal.PlatformDependent0
' initialization at runtime we need to registerjava.nio.DirectByteBuffer
's constructors for reflective access to avoid miss-configurations due to not being able to access the constructor inhttps://github.com/netty/netty/blob/5db037beedca8aa5b6a486fa515cc6af013ced74/common/src/main/java/io/netty/util/internal/PlatformDependent0.java#L290-L292
More classes and methods might need to be registered as discussed in #37626
Closes Karm/mandrel-integration-tests#236
Note this is not a complete fix for #37626, it only partially solves the problem and unblocks our (mandrel team) CI.