JavaFTPクライアントライブラリのレビュー

FTPサーバーを実行しているリモートコンピューターからファイルをダウンロードする必要がある純粋なJavaアプリケーションを作成したい状況を想像してみましょう。また、名前、日付、サイズなどのリモートファイル情報に基づいてダウンロードをフィルタリングする必要があります。

FTPのプロトコルハンドラーを最初から作成することは可能であり、おそらく楽しいことですが、そうすることも難しく、長く、潜在的にリスクがあります。ハンドラーを自分で作成するために時間、労力、またはお金を費やしたくないので、代わりに既存のソフトウェアコンポーネントを再利用することをお勧めします。また、ワールドワイドウェブでは多くのライブラリを利用できます。FTPクライアントライブラリを使用すると、ファイルのダウンロードは次のようにJavaで記述できます。

FTPClient ftpClient = new FTPClient(); ftpClient.connect( "ftp.foo.com"、 "user01"、 "pass1234"); ftpClient.download( "C:\\ Temp \\"、 "README.txt"); //最終的にここで他の操作... ftpClient.disconnect();

私たちのニーズに合った高品質のJavaFTPクライアントライブラリを探すことは、思ったほど簡単ではありません。それはかなり苦痛になる可能性があります。JavaFTPクライアントライブラリを見つけるのに少し時間がかかります。次に、既存のライブラリをすべて見つけたら、どれを選択しますか?各ライブラリは、さまざまなニーズに対応しています。ライブラリの品質は等しくなく、デザインも根本的に異なります。それぞれが異なる機能セットを提供し、異なるタイプの専門用語を使用してそれらを説明します。

したがって、FTPクライアントライブラリの評価と比較は、困難で混乱を招く可能性があります。既存のコンポーネントを再利用することは称賛に値するプロセスですが、この場合、最初から始めるのは気が進まない可能性があります。そして、これは残念です。適切なFTPライブラリを選択した後、残りは日常的なものです。

この記事は、その選択プロセスを短く、簡単で、価値のあるものにすることを目的としています。まず、利用可能なすべてのFTPクライアントライブラリを一覧表示します。次に、ライブラリが何らかの方法で対処する必要がある関連基準のリストを定義して説明します。最後に、ライブラリが互いにどのようにスタックしているかをすばやく確認できる概要マトリックスを示します。このすべての情報は、迅速で信頼性が高く、長期的な意思決定を行うために必要なすべてのものを提供します。

JDKでのFTPサポート

FTPの参照仕様は、Request for Comments:959(RFC959)です。Sun MicrosystemsはJDKでRFC959実装を提供していますが、これは内部で文書化されておらず、ソースは提供されていません。RFC959は影の中にありますが、実際には、図1に示すように、URL仕様であるRFC1738を実装するパブリックインターフェイスのバックエンドです。

RFC1738の実装は、JDKで標準として提供されています。これは、基本的なFTP転送操作に適しています。これは公開され、文書化されており、ソースコードが提供されています。これを使用するには、次のように記述します。

URL url = new URL( "ftp:// user01:[email protected]/README.txt; type = i"); URLConnection urlc = url.openConnection(); InputStream is = urlc.getInputStream(); // OutputStreamをダウンロードするにはos = urlc.getOutputStream(); // アップロードする

JDKでのFTPクライアントのサポートは、標準の推奨事項に厳密に従いますが、いくつかの欠点があります。

  • これは、サードパーティのFTPクライアントライブラリとは根本的に異なります。これらはRFC1738ではなくRFC959を実装します。
  • RFC959は、ほとんどのデスクトップFTPクライアントツールに実装されています。多くのJavaプログラマーは、これらのツールを使用してFTPサーバーに接続します。好みの問題として、これらのツールはおそらくRFC959のようなライブラリを好みます。
  • 通信のためのクラスのみのオープンストリームを。構造化のための日のライブラリの提供なしストレートサポートは、より使いやすいのJavaへの生のFTPサーバの応答は次のようにオブジェクト、、、または。したがって、データをファイルに書き込んだり、ディレクトリリストを悪用したりするためだけに、さらにコードを記述する必要があります。URLURLConnectionStringFileRemoteFileCalendar
  • RFC1738のセクション3.2.5「最適化」で説明されているように、FTP URLでは、すべての操作の後に(制御)接続を閉じる必要があります。これは無駄であり、多くの小さなファイルを転送するには効率的ではありません。さらに、非常に制限の厳しいFTPサーバーは、このような通信オーバーヘッドを悪意のあるネットワーク攻撃または悪用と見なし、それ以上のサービスを拒否する場合があります。
  • 最後に、いくつかの便利な機能がありません。

これらの理由のすべてまたはいずれかのために、サードパーティのライブラリを使用することをお勧めします。次のセクションでは、利用可能なサードパーティの代替案を示します。

ライブラリの比較

以下のリストは、この記事全体で比較するライブラリの概要を示しています。それらはすべてリファレンスFTP仕様に従います。以下に、プロバイダー名とライブラリー名(イタリック体)について説明します。リソースには、各製品のWebサイトへのリンクが含まれています。ライブラリの使用をすぐに開始するために、メインのFTPクライアントクラスについても説明します。

  1. JScape、iNetファクトリーcom.jscape.inet.ftp.Ftp
  2. / nソフトウェア、IP * Worksipworks.Ftp
  3. Enterprise Distributed Technologies、Java FTPクライアントライブラリcom.enterprisedt.net.ftp.FTPClient
  4. IBM alphaWorks、FTP Bean Suitecom.ibm.network.ftp.protocol.FTPProtocol
  5. SourceForge、JFtpnet.sf.jftp.net.FtpConnection
  6. ジャカルタプロジェクト、ジャカルタコモンズ/ネットorg.apache.commons.net.ftp.FTPClient
  7. JavaShop JNetBeansjshop.jnet.FTPClient
  8. Sun、JDKsun.net.ftp.FtpClient
  9. Florent Cueto、JavaFTP APIcom.cqs.ftp.FTP
  10. Bea Petrovicova、jFTPcz.dhl.ftp.Ftp
  11. Globusプロジェクト、Java CoGキットorg.globus.io.ftp.FTPClient

ノート:

  • この記事の執筆時点で、IBMは自社のWebサイトでalphaWorks FTP BeanSuiteを提供することの適合性を評価しています。現在、すべてのユーザーのダウンロードは締め切られています。
  • Jakarta Commons / Netは、現在開発されていないSavareseNetComponentsのドロップイン代替品です。
  • JavaShopJNetBeansは放棄されたようです。この記事の執筆時点では、サイトは1か月以上オフラインになっており、サポートリクエストに対する回答を受け取ったことはありません。

基準

これまで、コンテキストを紹介し、利用可能なライブラリをリストしました。ここで、各ライブラリが評価される関連基準をリストします。最終的な比較マトリックスで使用される略語(太字)とともに、各基準の可能な値を列挙します。

製品サポート

ライブラリは、製品ドキュメント、コンパイルされたJavadoc、サンプルコード、およびコメントと説明を含めることができるサンプルアプリケーションを通じてユーザーにサポートを提供します。追加のサポートは、フォーラム、メーリングリスト、連絡先の電子メールアドレス、またはオンラインのバグ追跡システムを通じてユーザーに提供できます。/ nソフトウェアは、追加料金で広範なサポートを提供します。

サポート管理者のモチベーションは、迅速なサポートのための重要な要素です。サポート管理者は次のようになります。

  • 自発的な個人(
  • 自主グループ(G
  • サポートを提供するために支払われる専門家(P

ライセンス

商業プロジェクトの場合、製品ライセンスは最初から考慮すべき重要な問題です。一部のライブラリは商用製品で自由に再配布できますが、他のライブラリはできません。たとえば、GPL(GNU General Public License)は強力な制限付きライセンスですが、Apacheソフトウェアライセンスは再配布された製品でのみ言及する必要があります。

商用ライセンスは、ライブラリを使用してプログラミングする開発ワークステーションの数を制限しますが、ライブラリ自体の配布は制限されません。

非営利プロジェクトの場合、ライセンスは哲学の問題です。無料の製品はかなりのものです。

ライセンスは次のとおりです。

  • コマーシャル(C
  • GPL(G
  • 無料(F); ただし、制限については無料ライセンスを確認してください

一部のライブラリプロバイダーは、オンデマンドで代替の制限の少ないライセンスを提供します。

提供されたソースコード

クローズドソースのブラックボックスソフトウェアライブラリはイライラする可能性があります。次の理由により、ソースコードを使用する方が快適です。

  • アプリケーションコードの実行をデバッグする場合、ライブラリコードソースにステップインすると、ライブラリの動作を理解するのに役立ちます
  • ソースコードには役立つコメントがあります
  • ソースコードは、特別なニーズに合わせてすばやく調整できます
  • 例示的なソースコードは刺激的である可能性があります

年齢

ライブラリは、最初の公開リリース以降、テスト、デバッグ、およびサポートされています。バージョン番号はライブラリによって異なるため、この基準は最初の公開リリースの年に基づいています。

ディレクトリリストのサポート

Retrieving remote file information (name, size, date) from the server is important in most applications. The FTP protocol offers the NLST command to retrieve the file names only; the NLST command is explicitly designed to be exploited by programs. The LIST command offers more file information; as RFC959 notes, "Since the information on a file may vary widely from system to system, this information may be hard to use automatically in a program, but may be quite useful to a human user." No other standard method retrieves file information; therefore, client libraries try to exploit the LIST response. But this is not an easy task: since no authoritative recommendation is available for the LIST response format, FTP servers have adopted various formats:

  • Unix style: drwxr-xr-x 1 user01 ftp 512 Jan 29 23:32 prog
  • Alternate Unix style: drwxr-xr-x 1 user01 ftp 512 Jan 29 1997 prog
  • Alternate Unix style: drwxr-xr-x 1 1 1 512 Jan 29 23:32 prog
  • A symbolic link in Unix style: lrwxr-xr-x 1 user01 ftp 512 Jan 29 23:32 prog -> prog2000
  • Weird Unix style (no space between user and group): drwxr-xr-x 1 usernameftp 512 Jan 29 23:32 prog
  • MS-DOS style: 01-29-97 11:32PM prog
  • Macintosh style: drwxr-xr-x folder 0 Jan 29 23:32 prog
  • OS/2 style: 0 DIR 01-29-97 23:32 PROG

Unix style, then MS-DOS style, are the most widespread formats.

Java FTP client libraries try to understand and auto-detect as many formats as possible. In addition, they offer various alternatives for handling unexpected format answers:

  • An additional method returning a raw FTP response as one string (S)
  • An additional method returning a collection of raw strings, one string per line/file (C)
  • A framework supporting pluggable parsers (P)

Most libraries parse LIST responses and structure raw file information into Java objects. For example, with JScape iNet Factory, the following code retrieves and exploits file information received in a directory listing:

java.util.Enumeration files = ftpClient.getDirListing(); while (files.hasMoreElements()) { FtpFile ftpFile = (FtpFile) files.nextElement(); System.out.println(ftpFile.getFilename()); System.out.println(ftpFile.getFilesize()); // etc. other helpful methods are detailed in Javadoc } 

Section "Solutions for Remaining Problems" further considers directory listings.

Timestamp retrieval

In many cases, we are interested in a remote file's latest modification timestamp. Unfortunately, no RFC introduces a standard FTP command to retrieve this information. Two de facto methods exist:

  1. Retrieve this information from the LIST response by parsing the server answer. Unfortunately, as you learned in the previous section, the LIST response varies among FTP servers, and the timestamp information is sometimes incomplete. In the Unix format, imprecision occurs when the remote file is more than one year old: only the date and year, but not hours or minutes are given.
  2. Use the nonstandard MDTM command, which specifically retrieves a remote file's last modification timestamp. Unfortunately, not all FTP servers implement this command.

An intricate alternative to MDTM command support is to send a raw MDTM command and parse the response. Most libraries provide a method for sending a raw FTP command, something like:

String timeStampString = ftpClient.command("MDTM README.txt"); 

Another possible concern is that FTP servers return time information in GMT (Greenwich Mean Time). If the server time zone is known apart from FTP communication, the java.util.TimeZone.getOffset() method can help adjust a date between time zones. See JDK documentation for further information about this method.

Section "Solutions for Remaining Problems" further considers file timestamp retrieval.

Firewalls

Typically, a firewall is placed between a private enterprise network and a public network such as the Internet. Access is managed from the private network to the public network, but access is denied from the public network to the private network.

Socks is a publicly available protocol developed for use as a firewall gateway for the Internet. The JDK supports Socks 4 and Socks 5 proxies, which can be controlled by some of the libraries. As an alternative, the JVM command line can set the Socks proxy parameters: java -DsocksProxyPort=1080 -DsocksProxyHost=socks.foo.com -Djava.net.socks.username=user01 -Djava.net.socks.password=pass1234 ...

Another common alternative to Socks proxy support is to "socksify" the underlying TCP/IP layer on the client machine. A product like Hummingbird can do that job.

The JDK also supports HTTP tunnels. These widespread proxies do not allow FTP uploads. /n software's IP*Works allows you to set HTTP tunnel parameters.

ほとんどのライブラリは、アクティブ接続とパッシブ接続の両方をサポートしています。パッシブ接続は、クライアントがファイアウォールの背後にあり、上位ポートへの着信接続を禁止している場合に役立ちます。RFC1579では、このファイアウォールに適した機能について詳しく説明しています。一部の製品のドキュメントでは、アクティブ接続とパッシブ接続をそれぞれPORTおよびPASVコマンドと呼んでいます。

並列転送

デスクトップアプリケーションでは、メインのシングルスレッドで転送が開始されると、すべてがフリーズします。一部のライブラリは、個別のスレッドでの並列転送のイベントループを自動的に処理するため、独自のスレッドを作成して管理する必要はありません。

JavaBean仕様のサポート

一部のライブラリはJavaBean仕様を実装しています。JavaBean準拠により、主要なJavaIDEに搭載されているビジュアルプログラミングが可能になります。