Provide a separate server implementation of Channel (server service) which runs as a separate process, plus a client stub (RemoteChannel, implementing Channel) which communicates with the service.

The communication is across pipes/sockets/shared memory (TBD) and assumes servers and clients are on the same host. Most method calls of Channel need to be supported.

Advantages

Fast replacement

The server process could be replaced on the fly with a different server process, e.g. using a different configuration.
If compiled down to a native image (using GraalVM), this would take only a few milliseconds.
This could move the config permutations (UDP/TCP/NIO/PING/TCPPING/KUBE_PING/DNS_PING etc) from Infinispan into the separate server process.

Rolling upgrades

We could have a Channel implementation, which communicates with multiple remote JGroups servers, sending messages to both and receiving messages from both servers.
One server could be running 3.6. Later, a 4.x server could be added and when all members have a dual-channel, the 3.6 channels could be shut down, effectively performing a rolling upgrade of JGroups from a version to a different version.

Disadvantages

This would be much slower, because of the serialization overhead. Perhaps shared memory could be used on the same host to avoid that...