Java SE 8 (5) - プラットフォーム、セキュリティー、他
最後に、API改良の残りのセキュリティー関連と、プラットフォームの変更、etc、について、説明します。
(2014-03-21追記)APIドキュメントのリンクを差し替えました。
モジュール化の準備
Project Jigsawで知られるモジュール化ですが、Java8では導入が見送られました。
その代わり、Java9以降でモジュール化を導入する際に障碍となると思われる問題を事前につぶしていく準備が進められています。
Java8では、次のような準備が行われています。
- クラスローディングの問題の取り組み
- 独自のサービスプロバイダーメカニズムをServiceLoaderに置き換える
- ライブラリーとの依存関係を解析するコマンドラインツール(
jdeps
)の提供 - モジュール化の大きな障害となるAPIを非推奨にマーク
- JAVA_HOME内のファイル参照を個別にする
jdeps
については、実行結果のイメージをGistに載せてみました。
もう一点、APIを非推奨(Deprecated)にする対応については、ちょっと補足しておきます。
Java SEのAPIの中では*1、以下のメソッドが非推奨になっています。
java.util.logging.LogManager#addPropertyChangeListener
java.util.jar.Pack200.Packer#addPropertyChangeListener/removePropertyChangeListener
java.util.jar.Pack200.Unpacker#addPropertyChangeListener/removePropertyChangeListener
これらのメソッドは、JavaBeans API(java.beans
パッケージ)のPropertyChangeListener
インターフェイスのオブジェクトをパラメーターにしています。
ところが、PropertyChangeListener
を含むJavaBeans APIというのは、GUI向けのAPI*2で、パッケージ単位ではAWTやSwingなどに依存しているんです。そのため、これらのメソッドを使っていると、モジュールからGUI関連のAPIを排除することができなくなってしまいます。
実際の開発でも、IDEを使っていると、テキトーに使えそうなクラスを補完で使ってしまったりすることもありそうなので、次項のコンパクトプロファイルを使って業務ロジックはcompact2に限定しておけば、こういう問題は防げるようになりますね。Java8が現場に導入されるようになるのはかなり先になりそうですけれど。
コンパクトプロファイル
Javaの将来のバージョンで、Java SEとJava MEの統合が予定されています。
また、JavaアプリケーションをJREごと配布する場合に、フルセットのJREを同梱しなければならないという問題がありました。
Java8では、コンパクトプロファイルを定義することで、GUIコンポーネントやEE向け機能を使用しないようなアプリケーションは、それを含まないサブセットで配布することができるようになります。
たとえば、これまでJava MEの領域だった小型端末向けのアプリケーションを、Java SEでデプロイできるようになります。Java SEのアプリケーションも、JREを同梱する場合に軽量化することができるようになります。
プロファイルは、以下の条件を満たす必要があります。
- プロファイルの5つの制約(意訳、原文はこちら ⇒ JSR 337: Java SE 8 - 8. Profiles)
以下のリストは、それぞれのコンパクトプロファイルの大まかなグループ分けをしたものです。
中には例外もあります。例えばXMLは、標準はcompact2
に、暗号化はcompact3
に含まれます。Webサービス向けXML機能はコンパクトプロファイルに含まれません。
compact1
compact2
compact3
コンパクトプロファイルに含まれないAPIには、アプレット、AWT、JavaBeans、ユーザー補助、注釈拡張、暗号化、Image I/O、Webサービスとそれに関連するXML(JAXB、JAX-WS)、印刷サービス、サウンド、Swing、CORBA(RMI-IIOP含む)などがあります。
セキュリティー関連
セキュリティーに関する変更をまとめてご紹介します。
HTTP URL のアクセス権
セキュリティーマネージャーが有効になっている環境下でHTTPアクセス権を設定する場合、従来はjava.net.SocketPermission
クラスを使って、IPアドレスかホスト名+ポート番号を指定する方法しか使えませんでした。
Java8では、java.net.URLPermission
を使って、java.io.FilePermission
と似たようなパス名の指定ができるようになっています。
設定変更可能なセキュアー乱数ジェネレーター
java.security.SecureRandom
クラスに新しくgetInstanceStrong
メソッドが追加されました。
getInstanceStrong
メソッドを使うと、セキュリティー設定ファイルのsecurerandom.strongAlgorithms
プロパティに指定したアルゴリズムを使ったSecureRandom
のインスタンスが取得できます。
セキュリティー設定ファイルについては、java.security.Policy
クラスを参照してください。
証明書失効チェックAPIの強化
証明書パスの失効チェックを行うjava.security.cert.CertPathChecker
インターフェイスが新規追加されました。java.security.cert.CertPathValidator#getRevocationChecker
でCertPathChecker
のインスタンス(実体はSPIで生成される)を取得することができます。
限定されたdoPrivileged
java.security.AccessController
クラスのdoPrivileged
メソッドとdoPrivilegedWithCombiner
メソッドに、java.security.Permission
クラスの可変長パラメータを持つオーバーロードメソッドが追加されました(doPrivileged(PrivilegedAction
他、計4メソッド)。
これにより、doPrivileged
を実行した際の、チェックが不要な権限の「スタックウォーク」を回避することができるようになっています。
TLSのServer Name Indication(SNI)拡張
調査中。
Javadoc APIのjavax.toolsへの追加
javax.tools
は、javac
やjavadoc
を、新しいプロセスを生成しないで実行できるようにするためのAPIパッケージです。
このパッケージに、DocumentationTool
インターフェイスが追加されました。ToolProvider#getSystemDocumentationTool
メソッドでインスタンスを取得できます。
元の資料によると、(javax.tools
はJava6で追加され、さらに)Java7でDocumentationTool
の追加が予定されていたのですが、Javadocはコードが古いためリファクタリングに時間がかかってしまい、Java7では見送られた、という経緯があるようです。
(2014-03-21追記)ツールAPI(javax.tools)でJavadoc出力 #java8も参考にしてください。
JNIネイティブライブラリーの静的リンク
ネイティブライブラリーの静的リンクサポートのため、JNI仕様が拡張されました。
このサポートのために、クラスローディングの一部の仕様も変更になっています。
これで、このシリーズは終了となります。
お読みいただき、ありがとうございました。
- シリーズ目次
- Java SE 8 (1) - 概要と一覧
- Java SE 8 (2) - ラムダ式、メソッド参照、ストリーム
- Java SE 8 (3) - 新しい言語機能
- Java SE 8 (4) - 新しいAPIと改良されたAPI
- Java SE 8 (5) - プラットフォーム、セキュリティー、他 (このエントリー)