Additional graalvm native-image flag needed since 4.1.108.Final
pylight opened this issue · 3 comments
I'm using netty with graalvm native-image build in a project and I experienced build failures like this when trying to update to netty 4.1.108.Final or newer (with graalvm ce 17 or 21):
Error: Classes that should be initialized at run time got initialized during image building:
io.netty.buffer.PooledByteBufAllocator the class was requested to be initialized at run time (from 'META-INF/native-image/io.netty/netty-buffer/native-image.properties' in 'file:///...jar' with 'io.netty.buffer.PooledByteBufAllocator'). To see why io.netty.buffer.PooledByteBufAllocator got initialized use --trace-class-initialization=io.netty.buffer.PooledByteBufAllocatorio.netty.buffer.ByteBufUtil the class was requested to be initialized at run time (from 'META-INF/native-image/io.netty/netty-buffer/native-image.properties' in 'file:/...jar' with 'io.netty.buffer.ByteBufUtil'). To see why io.netty.buffer.ByteBufUtil got initialized use --trace-class-initialization=io.netty.buffer.ByteBufUtil
io.netty.buffer.UnpooledHeapByteBuf the class was requested to be initialized at run time (subtype of io.netty.buffer.AbstractReferenceCountedByteBuf). To see why io.netty.buffer.UnpooledHeapByteBuf got initialized use --trace-class-initialization=io.netty.buffer.UnpooledHeapByteBuf
io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf the class was requested to be initialized at run time (subtype of io.netty.buffer.AbstractReferenceCountedByteBuf). To see why io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf got initialized use --trace-class-initialization=io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf
io.netty.buffer.UnpooledUnsafeHeapByteBuf the class was requested to be initialized at run time (subtype of io.netty.buffer.AbstractReferenceCountedByteBuf). To see why io.netty.buffer.UnpooledUnsafeHeapByteBuf got initialized use --trace-class-initialization=io.netty.buffer.UnpooledUnsafeHeapByteBuf
io.netty.buffer.AbstractReferenceCountedByteBuf the class was requested to be initialized at run time (from 'META-INF/native-image/io.netty/netty-buffer/native-image.properties' in 'file:///....jar' with 'io.netty.buffer.AbstractReferenceCountedByteBuf'). To see why io.netty.buffer.AbstractReferenceCountedByteBuf got initialized use --trace-class-initialization=io.netty.buffer.AbstractReferenceCountedByteBuf
io.netty.buffer.UnpooledDirectByteBuf the class was requested to be initialized at run time (subtype of io.netty.buffer.AbstractReferenceCountedByteBuf). To see why io.netty.buffer.UnpooledDirectByteBuf got initialized use --trace-class-initialization=io.netty.buffer.UnpooledDirectByteBuf
io.netty.buffer.UnpooledUnsafeDirectByteBuf the class was requested to be initialized at run time (subtype of io.netty.buffer.AbstractReferenceCountedByteBuf). To see why io.netty.buffer.UnpooledUnsafeDirectByteBuf got initialized use --trace-class-initialization=io.netty.buffer.UnpooledUnsafeDirectByteBuf
io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeDirectByteBuf the class was requested to be initialized at run time (subtype of io.netty.buffer.AbstractReferenceCountedByteBuf). To see why io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeDirectByteBuf got initialized use --trace-class-initialization=io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeDirectByteBuf
To see how the classes got initialized, use --trace-class-initialization=io.netty.buffer.PooledByteBufAllocator,io.netty.buffer.ByteBufUtil,io.netty.buffer.UnpooledHeapByteBuf,io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf,io.netty.buffer.UnpooledUnsafeHeapByteBuf,io.netty.buffer.AbstractReferenceCountedByteBuf,io.netty.buffer.UnpooledDirectByteBuf,io.netty.buffer.UnpooledUnsafeDirectByteBuf,io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeDirectByteBuf
When adding the --trace-class-initialization flag as mentioned above I saw that the class JdkSslServerContext was the reason for these errors. Adding --initialize-at-run-time=io.netty.handler.ssl.JdkSslServerContext fixes the issue on my side but I still wanted to bring the topic up here because I'm not sure if it is ideal that this has to be set? Probably the static-block in the class is the reason for this, right? Maybe this can be improved or otherwise the required native-image flag could be part of netty's native-image.properties file?
=> see also related quarkus issue and the commit that fixed it: quarkusio/quarkus#39819 and quarkusio/quarkus@b35ae00 (they also added JdkSslClientContext, not sure if/why that was necessary)
Let me know if a reproducer project is needed. Then I could put some additional effort into creation of a minimal project for this.
/cc @vietj @violetagg
In Spring Framework we remove all Netty's configurations (as this was the old way of configuration) and use the one provided by https://github.com/oracle/graalvm-reachability-metadata/tree/master/metadata/io.netty
More about it here #13596 (comment)