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.
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.
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.
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
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.
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.
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:
- Include the precise and complete timestamp representation in the
- Standardize the
MDTMcommand 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
MDTM response parsing and exploit a combination of these two features.
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.
Learn more about this topic
- The Java FTP API standardization project homepage
- Learn more about the Java Community Process
- The IETF official Website
- RFC959 (FTP)
- RFC1738 (URL)
- RFC1928 (Socks 5)
- Some complete and clear explanations about Socks
- Hummingbird Socks
- Learn more about the JavaBeans component architecture
- Sun suggests commendable Java coding conventions
- "Why Developers Should Not Write Programs That Call 'Sun' Packages" (Sun Microsystems, 1996)
- A short overview of the Façade pattern in Java
- Learn more about patterns in Java, including the Façade patternPatterns in Java, Volume 1, Second Edition, Mark Grand (John Wiley & Sons, 2002; ISBN 0471227293)
- The bible about patterns in other languages, including the Façade patternDesign Patterns, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, (Addison-Wesley, 1995; ISBN 0201633612)
- The Globus Toolkit Public License
- Learn more about GridFTP
- iNet Factory, JScape
- IP*Works, /n software
- Java FTP Client Library, Enterprise Distributed Technologies
- FTP Bean Suite, IBM alphaWorks
- JFtp, SourceForge
- Jakarta Commons/Net, the Jakarta Project
- JNetBeans, JavaShop
- Sun FTP API
- JavaFTP API, Florent Cueto
- jFTP, Bea Petrovicova
- Java CoG Kit, the Globus Project
- Savarese NetComponents
- Jean-Pierre Norguet also authored Websphere Version 4 Application Development Handbook with Ueli Wahli, Alex Matthews, Paula Coll Lapido, Paula Call Lapido (Prentice Hall PTR, 2002; ISBN 0130092258)
- Browse JavaWorld's Product Reviews index page
- Speak out in the JavaWorld Forum
- Sign up for JavaWorld's free weekly email newsletters
- You'll find a wealth of IT-related articles from our sister publications at IDG.net