Java FTP client libraries reviewed

Learn how the available libraries stack up against each other

Page 2 of 2

The n/ software IP*Works JavaBean design is event-based (for example, see the ipworks.Ftp.listDirectory() method). Although it remains synchronous and is perfectly safe, some programmers may find it odd or awkward in server-side applications.

Progress monitoring

Some libraries implement progress monitoring. Progress monitoring support makes it easy to implement event listeners that track any FTP transfer's progress. This feature is useful when developing a friendly user interface.

Transmission types

RFC959 section 3.1.1 specifies several transmission types, among which two are common: ASCII nonprint (default) and image (also called binary). Some libraries can be set in auto mode, according to the file extension. Such a method is rarely useful in modern information systems. Other transmission types have become obsolete and are not supported by any of the Java libraries.

Other criteria notes

All libraries run on at least JDK 1.2.x and later; most should run on JDK 1.1.x, and maybe JDK 1.0.x.

All libraries are pure Java.

The comparison matrix lists other obvious criteria.

Java FTP client libraries: Comparison matrix

Now comes the final comparison matrix. It displays libraries on top against criteria on the left. In cells, Y means Yes; other abbreviations are explained in the criterion lists above (see letters in bold) and in the table's key.

FTP Comparison Matrix

When choosing a library, I have a few recommendations:

  • For server-side applications, I recommend Jakarta Commons/Net library
  • I found JScape's iNetFactory the most easy-to-use library
  • /n software's IP*Works is part of a wide family of products, which includes encrypted FTP support
  • Java CoG Kit also implements GridFTP, an interesting new-generation file transfer system
  • At the time of this writing, I recommend not using IBM alphaWorks FTP Bean Suite and JavaShop JNetBeans in their current condition
  • Other libraries are absolutely decent and may suit your needs; please refer to the matrix

Change management

Most likely, at some point in our project, especially at the end when thorough testing occurs, we might want to change our library. Such a change affects all our calling code: our classes do not compile anymore, and some application parts must be recoded to match different method names and the new library's different design.

Since managing such a change can prove annoying, especially at a project's end when time is a critical resource, we should limit changes to one single class. Typically, we can apply the Façade pattern, with the FTP library as the back end, as illustrated in Figure 2.

Figure 2. The Façade pattern applied to an FTP library

A beneficial side effect of applying the Façade pattern to the FTP library is that we can add value to the library itself. For instance, we can write a Façade method that downloads an entire remote directory tree into a local zip file or a method that implements any basic feature lacking in the library.

Finally, two libraries that have the same signature do not necessarily have the same runtime behavior. Thus, switching from one library to another can also affect our application runtime. Such an impact is unpleasant and uncomfortable because discovering runtime differences is much more difficult, although detailed test cases can help.

Solutions for remaining problems

In the explanations of the above criteria, I briefly described several unsolved problems. In this section, I further discuss and address them; I suggest both long-term solutions and short-term workarounds.

Directory listing

The lack of any authoritative specification for the LIST response has led to many different FTP server implementations. This diversity is the biggest problem for FTP client programmers and is still an open issue.

As the problem's root lies in the protocol definition, I recommend that the concerned authoritative entity, the Internet Engineering Task Force (IETF), define the LIST response structure specification in a new reference document (an RFC).

This process can be long. In the meantime, the most flexible solution is to use a library offering a framework for pluggable format parsers.

File timestamp retrieval

As I discussed earlier, no method retrieves a remote file's last modification timestamp through FTP. I suggest two long-term solutions for transferring that timestamp from the server to the client:

  1. Include the precise and complete timestamp representation in the LIST response
  2. Standardize the MDTM command and response

For both solutions, server time zone should be considered in the communication.

Again, as the root of the problem lies in the protocol definition, I recommend that the IETF define one or both of the above solutions as an authoritative specification.

In the meantime, the most generic workaround is to use a library supporting both LIST and MDTM response parsing and exploit a combination of these two features.

Change management

In the related section above, I recommended the Façade pattern to reduce change effort in case of library replacement. As I mentioned, the pattern does not serve as a panacea, because the diversity in behaviors among libraries can still affect our entire application at runtime, which is difficult to control.

As this concern is a pure programming matter, I recommend that Sun publish a standard well-designed API, defining precise method signatures and behaviors. Anyone, including Sun, could implement it. Programmers could use the interface methods and back them up with their preferred implementation. And any switch from one library to another would have minimal impact on the rest of the application. JavaMail and JDBC (Java Database Connectivity) APIs are exemplary precedents.

The Java FTP API Standardization project aims to organize a consortium of users, developers, and providers to introduce a Request For Enhancement as a Java Specification Request in the Java Community Process. Your support would certainly be useful to this project, the homepage of which can be found in Resources.

Check out the best library for your needs

In this article, I explained how to write FTP client code in Java and presented FTP client support in the JDK and third-party libraries. I presented important criteria to consider when evaluating various libraries and compared the criteria across libraries. I hope decision-makers facing the choice of a Java FTP client library find useful indications in this objective study to make the best decision.

Finally, I presented different problems common to all FTP libraries and suggested short-term workarounds as well as long-term solutions that could be adopted by authoritative entities like IETF and Sun. I hope these leads and actions will help forge the future of Java FTP client libraries.

Jean-Pierre Norguet holds an engineering degree in computer science from the Universite Libre de Bruxelles and a Socrates European master's degree from the Ecole Centrale Paris. After three years of full-time Java development with IBM on mission-critical e-business applications, as team leader and coach, his areas of expertise grew to include the entire application development life cycle. He now works as a research fellow in Brussels, Belgium, writing a PhD thesis about Internet audience analysis. His outside interests include artistic drawing, French theater acting, and well-being massage.

Learn more about this topic

| 1 2 Page 2