Incompatibility with `com.digitalpetri.modbus:modbus-tcp`

[cmdjulian]

Hey,

thanks for your two awesome libraries.
We have an application which uses both com.digitalpetri.modbus:modbus-tcp:2.1.0 and org.eclipse.milo:sdk-client:0.6.15, org.eclipse.milo:sdk-server:0.6.15 respectively.

When starting my application, I get a few errors in the log:

2025-04-08T17:07:58.412+02:00 ERROR 94651 --- [application] [d-thread-pool-1] o.eclipse.milo.opcua.stack.core.Stack    : Uncaught Throwable on shared stack ExecutorService thread!

java.lang.AbstractMethodError: Receiver class org.eclipse.milo.opcua.stack.client.transport.uasc.ClientChannelFsm$ClientChannelActions does not define or inherit an implementation of the resolved method 'abstract java.util.concurrent.CompletableFuture connect(com.digitalpetri.fsm.FsmContext)' of interface com.digitalpetri.netty.fsm.ChannelActions.
	at com.digitalpetri.netty.fsm.ChannelFsmFactory.lambda$connect$54(ChannelFsmFactory.java:565) ~[netty-channel-fsm-1.0.0.jar:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[na:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[na:na]
	at java.base/java.lang.Thread.run(Thread.java:1583) ~[na:na]

The error seems to stem from the fact, that both of these dependencies use different versions of netty-channel-fsm, modbus uses version 1.0.0 and milo seems to rely on 0.9.0. This causes some incompatibility which makes using both dependencies in the same project unusable though.

Is there a way to fix that or even better to bump the dependency on the milo side to 1.0.0 as well?
I'm open to submitting a PR.

cheers!

[kevinherron]

This has come up a couple times now:

• Application using milo and modbus-tcp #1360
• Compatibility issues when used with Eclipse Milo digitalpetri/modbus#103

Unfortunately the only solution is to start using the dev/1.0 branch of Milo.

I looked into updating netty-channel-fsm and found that it cannot be done in the 0.6.x branch: #1360 (comment)

[cmdjulian]

Ah okay, thx for the context!
Is this branch considered production ready?

Otherwise I guess I would go for the shading approach.

[kevinherron]

It's getting close to release. There have been occasional breaking changes, but what's implemented is generally production ready.

We're using it at work in our upcoming release. I periodically publish "pinned" release versions to our internal Nexus repository so that we're not developing against a -SNAPSHOT version that may suddenly change and introduce a breaking change. Whether you do the same is up to you.

There are breaking API changes between 0.6.x and 1.0; you may as well get a start on handling them.