ネットワーク機能リリースノート

Java^TM 2 SDK, Standard Edition, v1.4.2 での既知のバグおよびその他のネットワーク機能に関する問題を次に示します。

1.4.2 より前のリリースでは、new URL ("http://www.foo.com:-1/index.html") のような無効な URL インスタンスを作成できました。ポート番号に -1 を指定することは有効ではありませんが、以前のリリースでは、このような URL を HTTP コマンドで送信する際に、-1 が削除されていました。1.4.2 では、-1 が URL に残るため、一部の HTTP サーバやプロキシで問題となる可能性があります。アプリケーションでポート番号が -1 の URL インスタンスを作成しないでください。この例では、-1 はデフォルトポートを参照すると仮定していますが、この URL を作成するには、new URL ("http://www.foo.com/index.html") が正しい方法です。この注意は、単一の引数による URL コンストラクタにだけ適用されます。

Microsoft Windows 98/ME では、Socket.setSoTimeout を使用して設定した読み取りタイムアウトや、ServerSocket.setSoTimeout を使用して設定した受け入れタイムアウトでは、想定よりも 500 ms 後にタイムアウトする場合があります。この問題はすべての J2SE リリースで発生しますが、Microsoft Windows 98/ME のバグが原因です。Microsoft Windows 98/ME 用のパッチは、Microsoft Web サイトの http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q257821& から入手できます。

J2SE 1.4.1 より前では、java.net.InetAddress.getLocalHost() は、アプリケーションのセッション全体で、ローカルマシンの IP アドレスの検索内容をキャッシュしていました。この動作では、ダイアルアップ接続でインターネットに接続しているマシン上や、DHCP でアドレスを取得したマシン上で実行しているアプリケーションでは問題が発生します。1.4.1 で修正され、ローカル IP アドレスはキャッシュされなくなりました。InetAddress.getLocalHost() で、ダイアルアップ接続や DHCP の場合の正しい IP アドレスが返されます。バグ 4211819 を参照してください。

J2SE 1.4.1 より前では、http/https プロトコルハンドラは、http URL から https URL への (またはその逆の) リダイレクトを正しく行わず、元の URL スキームを使用してリダイレクトしようとしていました。1.4.1 では、そのようなリダイレクト (http から https、または https から http) に対するサーバ応答をアプリケーションに返すことで、この問題を修正しました。そのため、アプリケーションで、応答コードを確認し、そのコードがリダイレクトであることを識別しなければなりません。Location ヘッダフィールド値はリダイレクト情報としてチェック可能であるため、アプリケーションは新しいプロトコルを使用してリダイレクトを行うかどうかを決定する必要があります。バグ 4620571 を参照してください。

J2SE 1.4 より前、java.net.URLConnection クラスでは、http サーバからのエラーを一貫性なく処理していました。実際に、getInputStream やその他のメソッドでは、http サーバが 400 以下の応答コードを返す場合で、かつ要求が既知のファイルタイプのリソースである場合は、FileNotFoundException をスローしていました。
1.4 では修正され、サーバからの http エラーではすべて IOException がスローされ、リソースが見つからないとき (つまり、応答コードが 404 または 410 の場合) に、専用の例外 FileNotFoundExeption をスローします。この例外は、ファイルタイプに関係なくスローされます。
アプリケーションで、サーバから http エラーが返されたときに例外がスローされることを想定していた場合、そのようなアプリケーションは 1.4 でのこの変更を認識する必要があります。4160499 を参照してください。
この問題に関連して、http エラーがサーバから返されたときに http サーバからエラーページを読み取るために、HttpURLConnection.getErrorStream() メソッドを使えるようになりました。これまでの getErrorStream() は、常に null を返していました。

J2SE 1.4 より前は、InetAddress.toString() では、ホスト名がこれまで解決されていなかった場合に、ネームサービスを介して検索を実行していました。1.4 では変更され、toString はすぐに戻ります。ホスト名が解決されない場合、返される文字列には、ドットで区切られた形式の IP アドレスだけが含まれます。
アプリケーションで toString() が解決されたホスト名の文字列を返すことを前提としている場合、1.4 でこの変更がなされたことに注意してください。4239141 を参照してください。

J2SE 1.4 より前では、InetAddress.getByName でネームサービスに対する検索に失敗した場合、仮想マシンのライフタイム中は、そのホスト名に関する後続の検索すべてが失敗します。これは、ネガティブ検索が常にキャッシュされていたためです。1.4 ではデフォルトで、検索に失敗した場合でも、後続の検索は成功する可能性があるように変更されました。これは、ダイアルアップ環境や、ネームサービスの信頼性が低い環境では特に重要です。
後続の検索が常に失敗することを前提としたアプリケーションでは、この問題に注意する必要があります。4256129 を参照してください。また、ネガティブ検索をキャッシュするかどうかは、java.security ファイルの networkaddress.cache.negative.ttl プロパティで制御できます。

Java 2 Platform, Standard Edition, v1.4 では、新しい例外 java.net.PortUnreachableException が導入されました。この例外は、DatagramSocket が接続のメソッドを介して接続していて、かつリモートアプリケーションが実行中でないことを示す ICMP ポート到達不能を受信した場合、DatagramSocket.send または DatagramSocket.receive によってスローされる可能性があります。PortUnreachableException は、UDP ベースプロトコルの種類によっては便利な表示となります。
PortUnreachableException に関する既知の問題を次に示します。
1. Solaris 8 では IPv6 が有効な場合、IPv4 ホストからの ICMP ポート到達不能パケットは廃棄されたようにみえます。これは Solaris 8 のバグであり、バグ番号 4422658 として確認できます。
2. 一部の Microsoft Windows リリース (特に Windows 98 と Windows NT) では、ICMP ポート到達不能パケットは、オペレーティングシステムによって不適切に破棄されてしまうため、PortUnreachableException がスローされません。現時点では、この問題を修正するための Windows Sockets 更新が Microsoft からリリースされたことを確認していません。
3. Linux では UDP パケットがループバックアドレスに送信され、宛先ポートにバインドされた UDP アプリケーションがない場合は、ICMP ポート到達不能通知を受信しないため、PortUnreachableException はスローされません。これは Linux カーネルの問題であり、現時点ではパッチが提供されていることを確認していません。

多くの Linux インストールで、InetAddress.getLocalHost() はループバックアドレス (127.0.0.1) を示す InetAddress を返します。これは、ほとんどの Linux インストールで、ホスト名をループバックアドレスにマップするように /etc/hosts を構成しているのが原因です。ホストが静的 IP アドレスを使用している場合は、ホスト名をホストのアドレスにマップするように、/etc/hosts ファイルを修正してください。
DHCP と動的 DNS を併用している場合は、2 つの方法があります。(i) /etc/nsswitch.conf でネームサービスの検索順序を変更し、hosts ファイル (hosts: DNS ファイル) の前に DNS を使用してください。または (ii) デフォルトのプロバイダの代わりに DNS ネームサービスプロバイダを使用するように、InetAddress を構成してください (-Dsun.net.spi.nameservice.provider.1=dns,sun)。この問題は 4665037 で確認できます。