About JSch open source project

There are many, many open source, pure java implementation for the SSH/SFTP protocol. However, in my opinion, there are two of them that can be taken seriously. One of them is JSch, the other one is Trilead SSH. I will talk about my experience on the former one while implementing the RemoteTools framework for the Parallel Tools Platform for Eclipse.

JSch is one of the few (if not the only one) open source, pure Java implementation with the a complete implementation of the SSH specification, covering both SSH versions. It also covers less common ssh use cases, like High Performance Enabled SSH/SCP (although I have not yet seen a SSH server willing to easily support this). The JSch maintainers are very careful to adhere strictly to the ssh specification. They even refuse to implement workarounds for known issues for common ssh servers. They reply: “Ask your ssh server provider for a fix”. And I tend to agree with them.

And JSch works with good performance, although written in pure Java and though spawning a large number of Java threads (probably, there would be better performance by spawing only one thread).

Other interesting point of JSch is its very flexible license. It is not surprising that the maintainers have chosen the Eclipse Public License, since they conveniently decided to cooperate with the Eclipse foundation to have JSch distributed by default with all Eclipse framework distributions. Therefore, many IBM Eclipse based products take advantage of JSch and its business friendly license.

Releases and bugfixes are frequent and the maintainers respond within short time to people reporting bugs and issues. The JSch library has become more and more stable.

The developer will notice that JSch provides a very low level library for the SSH protocol. It fits like a glove for the programmer who wants to have full control over the SSH connection. However, a lot of coding is required even for trivial tasks, like running a simple command on the remote host. The programmer has to take care of every minimal detail. Well, these are the classic pros/cons of a low level library.

JSch maintainers took the sentence “the source is the documentation” to the extreme. There is absolutely no comment in the code. There is no documentation of the APIs of the library. No, the API is very counterintuitive and does not follow any design to be expected. Once you have unzipped the source, you are one your own. Yes, at least, there are some examples.

But once you know all SSH specification documents by hard, JSch starts looking easier. The JSch library is very close to the specification. Classes match exactly entities described in the SSH specification. So do methods, that are named exactly as the operations from the specification. This is also true for parameters, return values, constants and exceptions.

After reading the JSch code, I can state that the maintainers really do not like Java. The code, although written in Java, looks like old style C. Jsch does not follow Java coding conventions. I wonder how JSch was accepted on the Eclipse community, considering its rigorous development conventions. Curiously, all code is written in “emacs”. I really cannot understand this. Why? If they developed JSch for the most powerful and complete Java IDE.

Furthermore, the maintainers do not feel like employing design patterns. Many issues arise on the design of the API. The poor class hierarchy prevents the programmer from writing good quality code while handling JSch objects. Visibility of methods is difficult to be understand, specially because they are only meaningful at certain points of the class hierarchy, but always visible and accessible.

Specially, the approach Jsch uses for authentication is completely misunderstood. Nobody can explain the purpose of all the methods in class that needs to implement to provide authentication information.
Even worse, the methods of this class are intended for interactions with user through GUI.

Unfortunately, the maintainers do not seem to like the open source community. Suggestions to improve JSch are redirected to /dev/null. People willing to help are discouraged by the maintainers. Contributions are silently ignored. Many good ideas and important improvements were lost due the egoism of the maintainers.

The JSch project does not use common open source tools, like bugzilla, wiki or forum. Although the bugzilla and forum are open for the community, they are never read by the maintainers. All communication is done through a strange mailing list with no useful feature (even searching for messages is not possible).

Error handling needs urgent improvement. The only approach for the application to recover from errors is parsing the message inside the exception, a very poor programming practice in Java. For example, this issue is very serious, because once the connection fails to establish, it is not possible to distinguish an unreachable host from invalid authentication.

Conclusion

JSch cannot be called “Open Source”, since the maintainer do not interact with the community. However, it has a great value of being the only implementation that follows strictly the SSH specification with a complete set of features.