1 Random Observation & 1 Repo Question

[peterfranciscook]

    artifacts = [
        "org.eclipse.milo:milo-sdk-client:1.0.3",
        "org.eclipse.milo:milo-stack-core:1.0.3",
    ],

(tl;dr no major milo problems with compiling to native-image!).
I did an experimental run and smoke test of compiling my (milo-dependent) app with graalVM's native-image compiler. Before compiling I instrumented graalVM to capture reflection usage and it flagged several milo classes in reflect-config.

[
{
  "name":"[Lorg.eclipse.milo.opcua.stack.core.types.structured.BrowseResult;"
},
{
  "name":"[Lorg.eclipse.milo.opcua.stack.core.types.structured.EndpointDescription;"
},
{
  "name":"[Lorg.eclipse.milo.opcua.stack.core.types.structured.EnumField;"
},
{
  "name":"[Lorg.eclipse.milo.opcua.stack.core.types.structured.MonitoredItemCreateResult;"
},
{
  "name":"[Lorg.eclipse.milo.opcua.stack.core.types.structured.MonitoredItemNotification;"
},
{
  "name":"[Lorg.eclipse.milo.opcua.stack.core.types.structured.ReferenceDescription;"
},
{
  "name":"[Lorg.eclipse.milo.opcua.stack.core.types.structured.StructureField;"
},
{
  "name":"[Lorg.eclipse.milo.opcua.stack.core.types.structured.UserTokenPolicy;"
},
{
  "name":"com.digitalpetri.netty.fsm.ChannelFsmFactory$1",
  "methods":[{"name":"channelInactive","parameterTypes":["io.netty.channel.ChannelHandlerContext"] }, {"name":"exceptionCaught","parameterTypes":["io.netty.channel.ChannelHandlerContext","java.lang.Throwable"] }, {"name":"userEventTriggered","parameterTypes":["io.netty.channel.ChannelHandlerContext","java.lang.Object"] }]
},
{
  "name":"org.eclipse.milo.opcua.stack.core.StatusCodes",
  "allPublicFields":true
},
{
  "name":"org.eclipse.milo.opcua.stack.core.encoding.json.OpcUaDefaultJsonEncoding"
},
{
  "name":"org.eclipse.milo.opcua.stack.core.encoding.xml.OpcUaDefaultXmlEncoding"
},
{
  "name":"org.eclipse.milo.opcua.stack.transport.client.tcp.OpcTcpClientTransport$ClientChannelActions$1"
},
{
  "name":"org.eclipse.milo.opcua.stack.transport.client.tcp.OpcTcpClientTransport$ClientChannelActions$2",
  "methods":[{"name":"channelInactive","parameterTypes":["io.netty.channel.ChannelHandlerContext"] }]
},
{
  "name":"org.eclipse.milo.opcua.stack.transport.client.uasc.InboundUascResponseHandler",
  "methods":[{"name":"channelInactive","parameterTypes":["io.netty.channel.ChannelHandlerContext"] }, {"name":"userEventTriggered","parameterTypes":["io.netty.channel.ChannelHandlerContext","java.lang.Object"] }]
},
{
  "name":"org.eclipse.milo.opcua.stack.transport.client.uasc.InboundUascResponseHandler$DelegatingUascResponseHandler"
},
{
  "name":"org.eclipse.milo.opcua.stack.transport.client.uasc.UascClientAcknowledgeHandler",
  "methods":[{"name":"channelActive","parameterTypes":["io.netty.channel.ChannelHandlerContext"] }, {"name":"exceptionCaught","parameterTypes":["io.netty.channel.ChannelHandlerContext","java.lang.Throwable"] }]
},
{
  "name":"org.eclipse.milo.opcua.stack.transport.client.uasc.UascClientMessageHandler",
  "methods":[{"name":"channelInactive","parameterTypes":["io.netty.channel.ChannelHandlerContext"] }, {"name":"exceptionCaught","parameterTypes":["io.netty.channel.ChannelHandlerContext","java.lang.Throwable"] }, {"name":"userEventTriggered","parameterTypes":["io.netty.channel.ChannelHandlerContext","java.lang.Object"] }]
}
]
// ... and a bunch of netty stuff

graalVM is "smart" enough to capture the reflection usage and make it work, but I thought you might find this information potentially useful as I know you try to minimize reflection in milo @kevinherron .

Repo question:
(Mostly just curious here) Guava is a fairly heavy library, what's the reasoning behind shipping a separate copy of it in org/eclipse/milo/shaded? Avoid version conflicts in uber jars downstream of milo by pinning the guava classes used in milo to a specific release? Would "un-shading" it (to a guava version like 33.4.8) with jar-jar break anything you're aware of?

[kevinherron]

Avoid version conflicts in uber jars downstream of milo by pinning the guava classes used in milo to a specific release?

Yes, to avoid version conflicts, and I also minimize it to reduce the size. Some day I'd like to get rid of it entirely but there's a few really convenient data structures with no alternative in the stdlib that I don't want to implement myself.

[peterfranciscook]

It's hard to avoid guava in a java app (I lean heavily on it in my own work). The flipside is because of its ubiquity, most java libraries on maven central have a transitive dependency on guava, and it creates work for build tools to shade in just one version.

[kevinherron]

I don't know what the graal JSON means... surprised to see a lot of those classes mentioned. Is it flagging calls to getClass() used in equals() impls?

[peterfranciscook]

graal's reflect-config is the output of a process that catalogs classes that are loaded onto the JVM reflectively, and it can generally work with it. I searched the milo repo for things that looked like reflection for those specific classes and for most of them its just access like BrowseResult.getClass().getSimpleName() which isn't usually considered reflection; it could also be the class cast in stream expressions. There are some ...getInstance() calls and a few other outliers.

[peterfranciscook]

I also don't have "hard" numbers to share (I've got a TODO to capture some better data) at the moment, but according to my smoke test log, bootstrapping my (milo-based) OpcUa services went from the hundreds of milliseconds to the tens of milliseconds with the native-image-compiled milo; kind of surprised I didn't knock my S7-1500 over with that request throughput.