Java
Java SE
JDKリリース・ノート一覧(US) JDK 8リリース・ノート
ここでは、このリリースの既知の問題について説明します。このリリースで解決された旧リリースの問題についても説明されています。
旧バージョンのJRE RPMが以前にインストールされたLinuxホストに1.8.0 JRE RPMをインストールすると、問題が発生する場合があります。JREの旧リリースのファイルおよびディレクトリが残っており、これらが1.8.0 RPMのファイルおよびディレクトリと競合して次のようなエラーが発生する可能性があります。
file /etc/init.d/jexec from install of jre-1.8.0-fcs.x86_64 conflicts with file from package jre-1.6.0_10-beta.x86_64
パッケージとファイルの競合を無視する--forceフラグを使用して、この動作をオーバーライドできます。
構文:rpm <rpm commands> --force <rpm-package-name>.rpm
例:rpm -i --force jre-1.8.0-fcs.x86_64.rpm
SolarisにUNWj8rtとSUNWj8devのパッケージをインストールしているときに、次のようなチェックサム・エラーが発生し、部分的にインストールが失敗する可能性があります。
ERROR: content verification of <file> failed
file cksum <11517> expected <10771> actual
{...}
Installation of <SUNWj8dev> partially failed.
他の理由で正式なチェックサム・エラーがスローされる場合がありますが、上記のエラーはほとんど存在しないと思われる特定のネットワーク構成に限られます。
このエラーはコア機能には影響を及ぼしません。インストールは正常に完了しています。
32ビットのJREバージョン7u6以降が存在する場合でも、64ビットのJRE 8がアンインストールされると、"Enable Java Access Bridge"チェック・ボックスがコントロール・パネル(コントロール パネル→コンピューターの簡単操作センター→コンピューターを画面なしで使用します)から削除されます。回避策として、既存の32ビットのJREをアンインストールしてから、再度インストールする方法があります。32ビットのJREバージョン7u6以降がインストールされると、"Enable Java Access Bridge"チェック・ボックスが表示されます。
RMIを使用するアプリケーションが制限された環境(つまり、Java Plug-in、Java Web Start)で実行すると、動作しない場合があります。特に、RMIコールバックのUIを実行すると、多くの場合NullPointerExceptionがスローされます。
バージョン1.7のJREを1.8にアップグレードすると、Javaコントロール・パネルで、JREプラットフォームのバージョンが1.8ではなく1.7として報告される場合があります。このことがWindowsまたはLinuxのユーザーに影響を及ぼすことはありませんが、Mac OS Xユーザーには影響を及ぼす可能性があります。JNLPファイルまたはHTMLアプレット・タグでアプレットによりバージョン1.8が要求された場合、アプレットでエラーが発生するか、意図したものよりも古いJREのリソースがロードされます。この問題を回避するには、deployment.propertiesファイルを削除するか、deployment.propertiesファイルを編集してJREエントリを削除します。
OS X 10.9上で、管理権限が必要なJavaコントロール・パネルの特定のアクションを実行すると、正しく機能しません。現在この問題は、Java Plug-inの無効化と自動更新チェックの無効化の2つの機能に影響を及ぼします。認証ダイアログがキャンセルされると、現在のユーザーに対してプラグインが無効になります。そのためユーザーは、引き続きそのプラグインを無効化できますが、システムのそれぞれのユーザーが個別に無効化する必要があります。自動更新チェックの無効化については、既知の回避策はありません。
アプレットのロードをトリガーするファミリCLSIDを、JREファミリの特定のバージョンと共に使用すると、機能しません。
アプレットのロードをトリガーするファミリCLSIDを、JREファミリの特定のバージョンと共に使用した場合、ファミリCLISDが無視され、代わりにシステムにインストールされた最新バージョンのJREを使用して、アプレットがロードされます。ファミリCLSIDはInternet Explorerに固有です。回避策として、代わりにjava_versionアプレット・パラメータまたはJNLPファイルのJava要素のversion属性を使用する方法があります。
リグレッション:7uのjarsignerを使用すると、JARSigningException例外がスローされます。
Java SE 1.4以前のバージョンのjarsignerで署名されるJARファイルで、META-INFにライセンスのドキュメントやイメージなどのリソース・ファイルが含まれている場合、JARファイルが適切に署名されません。
セキュリティ保護のため、それらのJARは有効に署名されたとは見なされません。現在、これらのJARを使用するアプレットでは、エンドユーザーに原因が示されることなくロードに失敗します。
唯一の回避策として、最新バージョンのjarsignerでJARを再度署名する方法があります。
署名済みのJARにマニフェスト属性"Permissions"がない場合、アプリケーション・エラー(つまりブロックされる)ダイアログの前でもセキュリティ警告ダイアログが表示されます。
署名済みのメインのJARファイルで、マニフェスト・ファイルに必須の"Permissions"属性が含まれていない場合、アプリケーションがブロックされます。しかし、セキュリティ・ダイアログが最初に表示され、アプリケーションがブロックされる前に、アプリケーションを実行するためのユーザーのアクセス権が要求されます。
ユーザーがJDK 7の使用時にdeployment.security.levelプロパティをMEDIUMに設定した場合、デプロイメント・コードの実行に初めてJDK 8が使用されたときに、プロパティが自動的にHIGHにアップグレードされます。ただし、deployment.security.levelプロパティに対して、システム構成も設定されている場合は、HIGHへのアップグレードは行われません。Javaコントロール・パネルを使用すると、プロパティを手動でアップグレードできます。
"証明書失効サイトにアクセスできないこと"によって発生する複数回のクリックが必要なダイアログに同意した後にアプリケーションをロードするのは、非常に時間がかかります。
サンドボックス・アプリケーションでは、セキュリティ・ダイアログに同意した後で、2回目の証明書失効チェックが毎回実行されます。ユーザーがすでに証明書を受け入れているという事実は無視されます。プロキシがオフになっている場合など、ネットワーク接続の問題が発生している場合は、java.net.SocketTimeoutExceptionがスローされる前に失効チェックで非常に時間がかかる場合があります。
回避策:
Javaコントロール・パネルを使用して、ユーザーが証明書失効チェックを無効化できます。
「Advanced」タブを選択します。
Performs certificate revocation checks onというオプションを見つけます。
そのオプションをDo not check (not recommended)に設定します。
アプリケーションをオンラインで起動できない場合に、Javawsをオフラインのアプリケーション実行モードに切り替えることはできません。
システムがオフラインのときは、アプリケーションのJNLPファイルで<offline-allowed>要素が指定されている場合でも、コマンドjavaws <jnlp_url>ではキャッシュ済みアプリケーションを起動できません。回避策として、ユーザーは次のいずれかを実行できます。
コマンドjavaws -offline <jnlp_url>を使用して明示的にJavawsを起動する
Javaキャッシュ・ビューアを使用してキャッシュ済みアプリケーションを起動する
java.lang.reflect JVMTIやjava.lang.instrumentのクラスを使用してクラスが再定義されている場合、そのクラスまたはクラスのメンバーのTypeアノテーションが破棄されます。
java.lang.reflect Class.getMethods()メソッドから返される配列に、クラスのメンバーではないメソッドが含まれる場合があります。この配列には、スーパーインタフェースからのメソッドが含まれますが、別のスーパーインタフェースでこのメソッドがより詳細に一致する場合があります。
java.lang.reflect ある状況下において、Class.getMethods()メソッドに対する呼出しから返された配列に、クラスのメンバーではないデフォルトのメソッドが含まれる場合があります。具体的には、さらに詳細に一致するメソッドがあるにもかかわらず、そのスーパーインタフェースのデフォルトのメソッドが含まれる場合があります。
現在、JDI APIを使用する方法では、デフォルトのインタフェース・メソッドをプログラムで起動できません。デフォルトのインタフェース・メソッドはJDK 8の新機能であり、まだJDIの仕様がこの機能に対応するように更新されていません。
java.swing Mac OS Xでは、ComboBoxコントロールが[Esc]キーと[Enter]キーを消費します。ダイアログ・ボックスのComboBoxがフォーカスされているときに、キーボードを使用してダイアログ・ボックスを閉じることはできません。
SwingNodeクラスは高DPIディスプレイをサポートしていません。
JavaFXパッケージャ・ツールにより、Windows x64に有効な.exeインストーラと共に無効な.msiインストーラが生成される場合があります。
次の場合のように、編集できないコンボ・ボックスで、マウスを使用しないトラバーサル機能が期待どおりに機能しません。
コンボ・ボックスがフォーカスされて、右側に隣接するコントロールがある場合、右矢印キーを押すと元のコンボ・ボックスのフォーカスは解除されますが、対象のコンボ・ボックスがフォーカスされません。対象のコンボ・ボックスがフォーカスされるようにするには、右矢印キーを2回押す必要があります。
いずれかのコンボ・ボックスが選択されている場合、トラバース・モードにするために上矢印キーまたは下矢印キーを押すと、インタラクティブ・モードになります。
マシンが一時停止状態の後でアクティブ化された場合、LinuxのScene Builderに再描画の問題が発生します。
jarファイルが署名されているが、署名者の証明書にコード署名を許可しないKeyUsageの拡張が含まれる場合、jarsignerが警告を出力するように設計されていましたが、引き続きファイルが署名されたものとして処理されます。実際には、JarFile解析内でKeyUsageチェックが実行されるため、現在はjarsignerによって、単にファイルが署名されていないものとして処理され、警告も表示されません。
javax.crypto/SolarisAES/GCM/NoPaddingの暗号化にOracleUcryptoプロバイダを使用すると、Solaris 11以降のリリースで予期しないIllegalBlockSizeExceptionがスローされる場合があります。
次の回避策を使用できます。
プロバイダの構成ファイル(<java-home>/lib/security/ucrypto-solaris.cfgなど)にあるdisabledServicesセクションに"Cipher.AES/GCM/NoPadding"の文字列を追加して、OracleUcryptoプロバイダからのGCM実装を無効化します。
OracleUcryptoプロバイダを無効化します。代わりに、次のいずれかの方法を使用してSunJCE GCM実装を使用します。この回避策ではOracleUcryptoが提供するすべてのサービスが無効になることに注意してください。
<java-home>/lib/security/java.securityファイルを編集します。java.security.Security.removeProvider("OracleUcrypto") APIを使用します。javax.crypto/SolarisMozilla Firefoxなどの新しいクライアントで、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256などのAEAD/GCMベースの暗号を使用して、TLS v1.2接続のネゴシエートが試行される場合があります。Tomcat 8.0.3などのJDK 8ベースのサーバーでは、以前のGCMの状態が再試行され、次の例外がスローされるという、OracleUcryptoプロバイダの既知の問題が発生する場合があります。
java.lang.IllegalStateException:Must use either different key or iv
for GCM encryption
次の回避策を使用できます。
プロバイダの構成ファイル(<java-home>/lib/security/ucrypto-solaris.cfgなど)にあるdisabledServicesセクションに"Cipher.AES/GCM/NoPadding"の文字列を追加して、OracleUcryptoプロバイダからのGCM実装を無効化します。
OracleUcryptoプロバイダを無効化します。代わりに、次のいずれかの方法を使用してSunJCE GCM実装を使用します。この回避策ではOracleUcryptoが提供するすべてのサービスが無効になることに注意してください。
<java-home>/lib/security/java.securityファイルを編集します。java.security.Security.removeProvider("OracleUcrypto") APIを使用します。javax.net.ssl SSL/TLSプロトコルでRSAクライアント鍵交換を使用しているときに、SunJSSEプロバイダがFIPS 140準拠モードで機能しません。この問題がSunJSSEのデフォルト・モードに影響を与えることはありません。
簡単な回避策として、SunJSSEプロバイダのFIPSモードを無効にする方法があります。詳細については、FIPS 140 Compliant Mode for SunJSSEを参照してください。
他の回避策として、SSL/TLSプロトコルでのRSA鍵交換の使用を無効にする方法があります。この問題は、RSA鍵交換に基づくSSL/TLS暗号スイートにのみ発生します。この問題を回避するために、代わりにアプリケーションでDHE/ECDHE暗号スイート(TLS_DHE_RSA_WITH_AES_128_CBC_SHAやTLS_ECDHE_RSA_WITH_AES_128_CBC_SHAなど)を使用できます。SSL/TLS暗号スイートのカスタマイズについて詳しくは、JSSE Reference Guideを参照してください。
Math.powで2の累乗の値を使用すると、パフォーマンスが低下します。この問題を回避するには、次の例と同様のコードを使用します。
if (power == 2) {
return x * x;
}
return Math.pow(x, power);
javaコマンドのローカライズ済みmanページに、ほとんど使用されず廃止された一部のガベージ・コレクタの組み合わせを制御する特定のオプションが廃止されたことに関する情報が記載されていません。英語版のmanページには該当する情報が記載されています。影響を受けるオプションについて詳しくは、http://openjdk.java.net/jeps/173を参照してください。
javac JDK 8にElementType.TYPE_USEが導入され、これがElementType.TYPEとElementType.ANNOTATION_TYPEの論理スーパーセットとして考慮される必要があります。しかし、現在javacコマンドでは、ElementType.TYPE_USEはスーパーセットとして認識されません。
javac JDK 8での型推論の仕様変更により、javacコマンドでは、次の例と同様のプログラムは使用できません。
abstract class A2<T>{
abstract <S> S foo(S x, S y);
abstract <S1> void baz(A2<S1> a);
void bar(A2<Integer> y, A2<Long> x){
baz(foo(x, y));
}
}
javac ラムダ式とインナー・クラスを組み合わせた次の例と同様のコードを使用すると、javacツールがクラッシュする場合があります。
public class Test {
void m() {
m1(()-> {
new A(){
public void m11() {}
};
});
}
void m1(Runnable r) {}
}
Aが既知の識別子の場合、このプログラムは正常にコンパイルされます。
javac ラムダ式内に複数のcatch文を持つコードに対して、不適切な例外テーブルが生成されます。次の例では、この動作を引き起こすコードの種類を示しています。
class LambdaWithMultiCatch {
public static void main(String[] args) {
Runnable r = () -> {
try {
throw new IOException();
} catch(IOException | IllegalArgumentException e) {
System.out.println("This code will generate a wrong exception table");
}
};
r.run();
}
}
メソッドmain()の生成された例外テーブルには、次の情報が含まれます。
Exception table:
from to target type
0 8 8 Class java/lang/Exception <--- neither IOException nor
<--- IllegalArgumentException appears
この問題が解決するまで、ラムダ式の本文で複数のcatch文を使用しないでください。
Visual Studio 2010の変更内容とsetargv.objに互換性がないことに対処するには、Java SE 7 Update 4 Release Notesの7146424のリリース・ノートで概説されているように、Javaランチャで独自の引数パーサー/プロセッサを使用します。
上記の解決策の副作用として、引用符とスペースのエスケープは、Windowsの仕様に従って実行する必要があります。次の例では、ディレクトリにスペースを含むコマンドラインを引用符で囲む正しい方法を示しています。
"c:\Program Files\Java\jdk1.8.0\bin\java.exe" -cp "c:\Some Dir\" SomeMain
この例は、引用符を使用する正しい方法です。さらにこの例は、Windowsコマンド・インタプリタ(cmd.exe)がユーザー・コマンドをオートコンプリートして、引数を引用符で囲む方法も示しています。
c:\\"Program Files\"\Java\jdk1.8.0\bin\java.exe -cp "c:\Some Dir\" SomeMain
c:\Progra~1\Java\jdk1.8.0\bin\java.exe -cp "c:\Some Dir\" SomeMain
この例は、dir /Xから取得された8.3形式でないファイルの短いファイル名を対象としています。
Java DBネットワーク・サーバーの起動に追加のアクセス権が必要になる場合があります。特に<db/bin>のスタートアップ・スクリプトで、ネットワーク・サーバーのブートに失敗する場合があります。
ブートの試行中に、ネットワーク・サーバーがブートに失敗し、次のエラーが表示される場合があります。
access denied ("java.net.SocketPermission" "localhost:1527" "listen,resolve")
java.security.AccessControlException: access denied
("java.net.SocketPermission" "localhost:1527" "listen,resolve")
この問題を解決するには、不足しているアクセス権を含むセキュリティ・ポリシーでネットワーク・サーバーを起動する必要があります。以下のようなネットワーク・サーバーのブート方法を避けるようにします。
java org.apache.derby.drda.NetworkServerControl start
代わりに以下のようにブートします。
java -Djava.security.manager -Djava.security.policy=${yourPolicyFile}
org.apache.derby.drda.NetworkServerControl start
ここで、${yourPolicyFile}は、Java DB Admin GuideのセクションBasic Network Server security policyに記載されたポリシー・ファイルのカスタマイズされたバージョンを含むファイルです。汎用のポリシー・ファイルをアプリケーションに合わせてカスタマイズする必要があります。また、${derby.install.url}derbynet.jarコードベースに付与された権限ブロックに次のアクセス権を追加する必要があります。
permission java.net.SocketPermission "localhost:${port}", "listen";
この${port}は、ネットワーク・サーバーが着信接続要求をリスニングするポート番号に置き換える必要があります。デフォルトでは、これはポート1527です。
Java DBのセキュリティ・ポリシーの詳細については、Java DB Admin GuideのセクションNetwork Server securityおよびRunning the Network Server under the security managerを参照してください。
レプリケーションを使用している場合は、スレーブ・サーバーのセキュリティ・ポリシーに、同様のアクセス権を付与する必要があります。${derby.install.url}derby.jarコードベースに次のアクセス権を追加します。
permission java.net.SocketPermission "localhost:${slavePort}", "listen";
この${slavePort}は、スレーブ・サーバーが着信接続要求をリスニングするポート番号に置き換える必要があります(通常、4851)。スレーブ・サーバーのセキュリティ・ポリシーの詳細については、Java DB Server and Administration GuideのセクションReplication and securityを参照してください。
次のリストには、JDK 8で解決された旧リリースからの既知の問題を記載しています。
[macosx] Scheduled AU - cannot auto update on Mac 10.9
Mac OS 10.9で、スケジュールされたJavaの(自動)更新が開始されると、インストーラが反応しなくなる場合があります。
サイズの大きいページの割当ての障害が原因でクラッシュします。
Linuxで、大きいページの割当て時の障害により、クラッシュする可能性があります。JDK 7u51以降のバージョンを実行している場合は、次の2つの方法で問題を認識できます。
クラッシュが発生する前に、次の例と同様の1つまたは複数の行がログに出力されている。
os::commit_memory(0x00000006b1600000, 352321536, 2097152, 0) failed; error='Cannot allocate memory' (errno=12); Cannot allocate large pages, falling back to regular pages
hs_errというファイルが生成されている場合に、次の例と同様の行がそのファイルに含まれている。
Large page allocation failures have occurred 3 times
この問題は、大きいページのサポートをオフにして実行することで回避できます。たとえば、"-XX:-UseLargePages"オプションをJavaバイナリに渡します。