[QUESTION] Should we collect GraalVM Reachability Metadata for shaded packages?

[linghengqian]

Describe the problem
A clear and concise description of what the problem is.

• In Disable the implementation of Etcd during the build of ShardingSphere Proxy Native apache/shardingsphere#28194 and Native image generation fails when adding a dependency with io.micronaut.gcp:micronaut-gcp-tracing  micronaut-projects/micronaut-gcp#532, there has been more than one issue that has resulted in a failure to build the GraalVM Native Image due to the lack of a GraalVM Reachability Metadata for io.grpc:grpc-netty-shaded.
• After Native image generation fails when adding a dependency with io.micronaut.gcp:micronaut-gcp-tracing  micronaut-projects/micronaut-gcp#532 (comment) , no friend mentioned whether GraalVM Reachability Metadata should be ingested for shaded packages like io.grpc:grpc-netty-shaded . I hope to have a clear response that will allow me to decide whether or not to submit a PR in question.
• More early investigations are located in Make ShardingSphere Proxy in GraalVM Native Image form available apache/shardingsphere#21347.

Additional context
Add any other context about the problem here.

• Refer to Native image generation fails when adding a dependency with io.micronaut.gcp:micronaut-gcp-tracing  micronaut-projects/micronaut-gcp#532 .

• Refer to Disable the implementation of Etcd during the build of ShardingSphere Proxy Native apache/shardingsphere#28194.

• Update in 2024.01.17: I completed nativeTest verification of io.grpc:grpc-netty:1.50.2 at Add GraalVM Reachability Metadata and corresponding nativeTest for Etcd integration apache/shardingsphere#29755. Fixing nativeTest on the ShardingSphere side actually only requires the GraalVM Reachability Metadata of io.netty:netty-transport-classes-epoll:4.1.99.Final. I've opened Add support for io.netty:netty-transport-classes-epoll:4.1.99.Final #437 for this. Resolved current issue on the ShardingSphere side by avoiding the use of io.grpc:grpc-netty-shaded. Refer to Improve jetcd and grpc dependency apache/shardingsphere#28780 .

System Info (please complete the following information):

• OS: [e.g. Windows] Ubuntu 22.04.3 LTS
• GraalVM Version [e.g. 22.0 CE] 17.0.8
• Java Version [e.g. 17] 17
• Plugin version [e.g. native-gradle-plugin:0.9.10] native-gradle-plugin:0.9.24

To Reproduce
If possible please attach a complete reproducer here (either as a zip file or as a link to public repository/branch).

• This does not require an additional reproduction process.

[vjovanov]

At the moment the answer is yes, we need to collect shaded data. We are looking for a solution to avoid duplication but it is not complete yet.

We will likely perform JSON transformation in the build tools before the project is built.

Thank you for raising this concern!

[linghengqian]

• According to further investigation at Add GraalVM native compilation support apache/logging-log4j2#1539 (comment), io.grpc:grpc-netty-shaded also requires a series of --initialize-at-run-time definitions in native-image.properties which are not actually GraalVM Reachability Metadata.

Args=--initialize-at-run-time=\
    io.grpc.netty.shaded.io.netty.channel.ChannelHandlerMask,\
    io.grpc.netty.shaded.io.netty.channel.nio.AbstractNioChannel,\
    io.grpc.netty.shaded.io.netty.channel.socket.nio.SelectorProviderUtil,\
    io.grpc.netty.shaded.io.netty.util.concurrent.DefaultPromise,\
    io.grpc.netty.shaded.io.netty.util.internal.MacAddressUtil,\
    io.grpc.netty.shaded.io.netty.util.internal.SystemPropertyUtil,\
    io.grpc.netty.shaded.io.netty.util.NetUtilInitializations,\
    io.grpc.netty.shaded.io.netty.channel.AbstractChannel,\
    io.grpc.netty.shaded.io.netty.util.NetUtil,\
    io.grpc.netty.shaded.io.netty.util.internal.PlatformDependent,\
    io.grpc.netty.shaded.io.netty.util.internal.PlatformDependent0,\
    io.grpc.netty.shaded.io.netty.channel.DefaultChannelPipeline,\
    io.grpc.netty.shaded.io.netty.channel.DefaultChannelId,\
    io.grpc.netty.shaded.io.netty.util.ResourceLeakDetector,\
    io.grpc.netty.shaded.io.netty.channel.AbstractChannelHandlerContext,\
    io.grpc.netty.shaded.io.netty.channel.ChannelOutboundBuffer,\
    io.grpc.netty.shaded.io.netty.util.internal.InternalThreadLocalMap,\
    io.grpc.netty.shaded.io.netty.util.internal.CleanerJava9,\
    io.grpc.netty.shaded.io.netty.util.internal.StringUtil,\
    io.grpc.netty.shaded.io.netty.util.internal.CleanerJava6,\
    io.grpc.netty.shaded.io.netty.buffer.ByteBufUtil$HexUtil,\
    io.grpc.netty.shaded.io.netty.buffer.AbstractByteBufAllocator,\
    io.grpc.netty.shaded.io.netty.util.concurrent.FastThreadLocalThread,\
    io.grpc.netty.shaded.io.netty.buffer.PoolArena,\
    io.grpc.netty.shaded.io.netty.buffer.EmptyByteBuf,\
    io.grpc.netty.shaded.io.netty.buffer.PoolThreadCache,\
    io.grpc.netty.shaded.io.netty.util.AttributeKey

• The humorous thing about this issue is that if Native Image support: Switch netty to runtime initialization by default netty/netty#12601 is merged, downstream modules, whether shaded netty or not, actually don't need native-image.properties at all. Netty 4 comes with a large number of native-image.properties, which forces downstream modules to change their behavior.

• @chrisvest @gradinac For Netty 4 and Native Image support: Switch netty to runtime initialization by default netty/netty#12601 (comment) , can we create a separate CI for GraalVM Native Image on a branch of Netty 4 to work with CentOS with a higher version of gcc? This will remove a lot of native-image.properties for the Netty 4 branch. I really don't believe that anyone has compiled a GraalVM Native Image with Netty 4 on CentOS 6.