As discussed in my previous JavaWorld article "Java FTP Client Libraries Reviewed" (April 2003), FTP support in the JDK does not fully implement the FTP specification (Request for Comments 959). For example, the JDK does not allow the creation of directories on the server or permit the FTP connection to remain open between two file transfers. Thus, when RFC959-compliance is needed, the JDK proves unsatisfying. In addition, when using the JDK's FTP support, FTP server responses are returned as raw strings instead of convenient Java objects. To get complete RFC959-compliant support and convenient methods, Java developers must turn to the third-party libraries available on the market.
Many Java FTP libraries exist and are available on the Internet. These libraries include:
- JScape's Secure FTP Factory
- Enterprise Distributed Technologies' FTPj
- JFtp
- Jakarta Commons/Net
- Sun JDK
- Florent Cueto's JavaFTP API
- Bea Petrovicova's jvFTP
- The Globus Alliance's Java CoG Kit
- Glub Tech's Secure FTP Bean
- Calvin Tai's FtpBean
This list is quite long, and comparing the libraries is not straightforward. Indeed, all these libraries implement different features, at various prices, with diverse levels of quality and license terms. Therefore, selecting the right library with regard to specific needs can prove difficult. To help decision-makers choose a library that suits their needs, this article compares and evaluates these libraries.
The comparison involves a number of criteria, including features supported, commercial aspects with regard to the library provider, and file transfer performance. I covered some of this criteria in "Java FTP Client Libraries Reviewed"—please refer to that article for a review. New criteria for this evaluation are security support and file transfer performance. The security support criterion indicates whether the library implements the security extensions for FTP. The performance criterion compares the libraries' transfer speeds.
The security extensions for FTP are defined in the Internet Engineering Task Force's reference document RFC2228. According to the recommendation, secure FTP extensions can be of two types: implicit and explicit. Implicit secure FTP is actually FTP over Secure Socket Layer, using a direct SSL connection, typically over port 990. Explicit secure FTP is FTP over SSL, but instead of using a direct SSL connection as in implicit connection, it first connects to the server using a plain-text FTP connection and then switches to SSL mode using the AUTH SSL or AUTH TLS command to switch to a secure SSL connection. Both implicit SSL and explicit SSL are typically referred to as FTPS (FTP over SSL). FTP security can also be implemented as a subprotocol of SSH (Secure Shell). This kind of implementation is referred to as SFTP. Although the protocols have similar names and functions, they are completely different. This comparison identifies what kinds of SFTP and FTPS secure FTP transfers are supported by each library.
The libraries' performance comparison is based on two measures of transfer speeds. The first measure represents the transfer speed of one large file and indicates how fast the library transfers data over a network. The second measures the transfer speed of many small files and indicates how fast the library operates the communication protocol with the server. These two measures should help in selecting which library is best suited for the target application's specific needs. For example, a library for video transfer over a network should score high at transferring large files, whereas a library for an application that involves many interactions with the FTP server should score high at transferring many small files.
Experiments
The experimental protocol used to obtain these measures was conducted as follows: One large file and many small files were created on the FTP server. The large and small files were used to measure the large-file and small-file transfer speeds, respectively. The files' numbers and sizes were designed to measure the same data volumes. The transfer occurred between two similar machines connected by a TCP/IP network. To keep the measures clean, any external transfer on the network segment was excluded during the measures. Also, to smooth any incidents, I took 10 versions of the measures and calculated the median average.
The experimental settings were set as follows: The transfer data volume was 10 Mb. As a consequence, the large-file size was 10 Mb. The small-file size was 1 Kb, and the number of small files, 10,000. The measurement network was a 10 Mbits/s Ethernet network. The Java Virtual Machine on the client was IBM VisualAge for Java 4.0 and the client operating system, Windows XP. The server operating system was RedHat Linux Fedora Core 2. The FTP server software was vsFTDd for Linux. Finally, the benchmark code is specific to this article and can be downloaded from Resources.
To reproduce the experiments, you can perform the following operations: Download the benchmark code, Benchmark.java, from Resources. The benchmark code is implemented in the Benchmark class. This class contains many inner classes. Each inner class implements the file transfer operations for each of the libraries. To run the benchmark, compile and execute the Benchmark class with the various libraries in your classpath. The execution takes one argument, the working directory path. This directory must contain a main.config file with the configuration parameters. A sample configuration file, main.config, can be downloaded from Resources. After execution, the measures are produced in a comma-separated file, which can be found in the working directory. This file can be opened and visualized in a spreadsheet program like Microsoft Excel. With these operations, you should receive results similar to the ones produced for this article.
The results
Using the experimental protocol and settings, I obtained two sets of measures for large-file and small-file transfers. Each set of measures is represented in a separate graph, with all the libraries on the left and their transfer speed appearing as a horizontal bar on the right. To provide an absolute scale of measure, the transfer speed was obtained by inversing the transfer time and multiplying by the shortest transfer time. This way, a 100 score is given to the fastest library, with the other scores falling between 0 and 100. As a reference, I also showed the transfer speed of the Windows XP FTP command.
In the large-file transfer graph (Figure 1), you can see that many libraries share high transfer speeds, with little differences among them. Therefore, many libraries are available for transferring large files. Note that the libraries were benchmarked without any kind of tuning. Some libraries' transfer speeds might indeed benefit from tuning operations. A typical tuning operation would set the input/output buffer size of the communication connections. Libraries in optimal tuning conditions should therefore transfer large files at similar speeds.
The small-file transfer graph (Figure 2) shows that EnterpriseDT's edtFTPj, Calvin Tai's FtpBean, and Glub Tech's Secure FTP Bean exhibit better performance than the others—even the Windows XP FTP command. The notable exception is the Sun JDK. After about 200 downloads, the JDK has given up the transfers, raising memory errors. In the graph, I extrapolated the average transfer speed from the first 200 downloads. The weak score can be explained by the fact that each download requires the opening and closing of a new control connection. This introduces communication overhead between each file transfer. In conclusion, the JDK is appropriate for downloading a limited number of files only.
For a review of each library's features, click here for the comparison matrix. The library names display at the top; the criteria appear on the left. Abbreviations in the cells are explained in the table's key.
Conclusion
This article builds upon my previous JavaWorld article "Java FTP Client Libraries Reviewed" and follows up on the FTP support issues in the Java platform. In terms of performance, most libraries compare similarly for large-file transfers. For many small transfers, EnterpriseDT's edtFTPj, Calvin Tai's FtpBean, and Glub Tech's Secure FTP Bean are the best options, while the Sun JDK should be avoided for more than 200 downloads. For other characteristics, please refer to the comparison matrix.
With the number of third-party libraries implementing RFC959 FTP support, developers should have sufficient choices for their specific file-transfer needs. However, using a third-party component introduces additional complexity in applications. For example, an applet deployed onto the client would require additional download from the server. This additional complexity would not be implied if the JDK completely supported FTP.
To achieve complete FTP support in the JDK, a Request for Enhancement (RFE) has been introduced in the Sun Developer Network Bug Database. After 30 months of continuous support from a growing community, the number of votes for this RFE has increased from 8 to 88, propelling it into one of the top 25 RFEs. However, by the time of this writing, Sun engineers have not completed the RFE and have not communicated any schedule.
In the meantime, the Java FTP API Standardization Project supports the FTP RFE. This project aims to gather a community of members supporting the RFE for the wealth of the Java platform. The project also strives to assemble a group of experts for submitting a Java Specification Request (JSR) to the Java Community Process (JCP). This JSR would establish an RFC959-compliant FTP implementation as a standard in the Java platform. However, the group of experts has yet to be formed, and the time required for the JSR to become a standard recommendation is unclear. In conclusion, the future of FTP support in the Java platform remains to be defined.
This story, "Update: Java FTP libraries benchmarked" was originally published by JavaWorld.