Support for sshj as an alternative to jsch

[sylvlecl]

Hi there,

First thanks for providing jsch-nio, that we leverage in the open source powsybl project.

We encounter some issues with the JSCH SSH implementation and (very closed) API, in particular with concurrent use: for example the API makes it almost impossible to limit the number of open channels per session, since there is no listener mechanism nor any possibility to inject custom implementations to alter the behaviour.

Therefore, I was thinking that the UnixSshFileSystem could actually use another "SSH backend", since it seems to rely almost only on the possibility to run unix commands, and not so much on JSCH itself.
(actually strictly speaking it could maybe rely on something completely independent from SSH, the only requirement being to be able to execute commands)

In particular, sshj seems to be very active and to exhibit a more flexible and powerful API.

A generic CommandRunner interface could then have 2 implementations:

• One for JSCH as today
• A new one for SSHJ

Any opinion about:

• the interest for such a feature for the java ecosystem ?
• its technical feasibility ?

[lucastheisen]

the interest for such a feature for the java ecosystem ?

I cant really say. I built this one because i needed the ability to watch a remote filesystem for changes and didn't see anything else that fit the bill. I figured if i needed that single use case i may as well implement the java fileystem API while i was at it. So I definitely had the need but if others did, they either hadn't opened up their implementation or i didn't find it in my initial investigation.

its technical feasibility ?

I see no reason why it wouldn't be feasible. The actual command running API is pretty separate from the fileystem API implementation logic. I think it could be done but I haven't looked at the source in a while (it just works for me as is).