A multi-release jar seemed like the right approach for this but IDE support when targeting multiple versions in the same module isn't great. Happy to refactor if there are any suggestions for a better way to organize things. No issues building with maven on command line though.

I was able to successfully use this branch to bind a set of ipc server sockets that pyzmq can connect to. This is the motivation for implementing this feature (used for a jupyter kernel implementation on the jvm).

I started a work on providing network protocols as services, but never had time to finish it. It should be a good starting point.

@fbacchella Referring to networkprotocolserviceprovider? Could you elaborate a bit on what you mean? There is still the problem of picking the ipc implementation at runtime and building part of jeromq targeting java 16 from what I can tell. i.e. if working off that branch I would still take the same approach here just in a different place.

I don't think I could pick up where you left off on that branch but I also don't think these changes necessarily conflict either. That work would still be useful regardless of this PR.

It could be a simple jar dropped in the classpath. So no problem with java version and the need to use the module trick.

Thanks, ok so you'd prefer the new ipc implementation to be a separate artifact? Leave the existing one there and put both behind an SPI? This would be an extra maven dependency that consumers would need right?

yes, that’s exactly what I had in mind.

@fbacchella Switched to loading IpcImpl via service loader. In order to add the extra artifact I had to move the current maven module into jeromq/ and the top level pom is now just there to serve as the parent for that and a new jeromq-ipc module.

The new module reruns the ipc tests I could find against the new implementation. The old fake ipc implementation is in zmq.io.net.ipc.loopback and it is used by default unless a service provider is found. I removed IpcAddressMask and the associated ipcAcceptFilters option because they were unused (at least in this code base) and I'm not really sure what it's supposed to be used for.

Please take a look when you get a chance.

This PR is why I released 0.6.0 and launched 0.7.0-SNAPSHOT. Protocol will be provided as services. I need to investigate how to resolved the multi-release jar problem, but I think the way it’s handled in this PR is the good way.

@fbacchella I should update the description again because I got rid of the multi-release jar with the service oriented refactor but I'm kind of on the fence if it should be added again. i.e. still keeping the separate maven module and artifact but package that artifact as the multi-release jar, no idea how a service provider is declared with that packaging though.

For my use case I always want to use this new ipc implementation if running in jre >=16 and just not use ipc at all otherwise. So I would want to always include jeromq and jeromq-ipc on the classpath but ideally still work (just tcp) if running on java 11. Service provider with multi-release targeting 16 feels like the best option but please let me know your thoughts.

I also see you revived the protocol as a service branch (#974), I can try and rebase this PR based on that if the plan is to merge that PR as well. Please let me know and I can try and find some time this weekend :)

The multi release jar is a good solution to provide a simple way to use IPC. Once the PR is merged, I will create another PR to implement modulorisation. Then we will be able to merge your implementation.

The new multi module organisation has just been merged. If you agree I will create a branch with empty IPC socket module to demonstrate how I think this should be handled. Or I can implement it myself, stealing the ideas, but you will miss the glory of attribution

I have a working branch that could do the job that stole some of your ideas, see https://github.com/fbacchella/jeromq/tree/ipc_unix_socket.