Java SE 9 アップデートと移行のポイントotndnld.oracle.co.jp/ondemand/java-2016/Java_Seminar...Java SE 9 アップデートと移行のポイント 2016年12月2日 David

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |

Java SE 9 アップデートと移行のポイント 2016年12月2日 David Buck Java Platform Group Oracle Japan

Javaで創るクラウド時代のエンタープライズ開発

～マイクロサービス、DevOpsとJavaの最新動向～


Safe Harbor Statement

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

2

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | 3

このセッションについて

•JDK 9 Language, Tooling, and Library Features

[CON2497]

•https://static.rainfocus.com/oracle/oow16/sess/14624883

268160011UyF/ppt/J1_2016-jdk9-lang-tools-libs.pdf

•https://www.youtube.com/watch?v=vKYzmIi_1LM

•Joe Darcy, JDK Engineer, Oracle

•Preparing for JDK 9: The Sharp Edges [CON6171]

•https://static.rainfocus.com/oracle/oow16/sess/146

30943250540018gtW/ppt/The%20Sharp%20Edged

s%20of%20JDK%209%20-

%20JavaOne%202016.pdf

•Sharat Chander, Director, Java Product

Management and Developer Relations, Oracle

•Aurelio Garcia-Ribeyro, Senior Group Product

Manager, Oracle

本セッションのコンテンツとスライドは下記の JavaOne 2016 のセッションを元にされ、作成された。

https://www.youtube.com/watch?v=vKYzmIi_1LM













https://static.rainfocus.com/oracle/oow16/sess/14630943250540018gtW/ppt/The Sharp Edgeds of JDK 9 - JavaOne 2016.pdf






自己紹介

バックデイビッド

• Java SE サステイニングエンジニアリング

• JVM のバグを直す人

• OpenJDK 8 Updates

Project Maintainer

• 趣味：プログラミング

4


アジェンダ

• 概要

• 大コードを弄る必要がある。該当するアプリが多い。

• 中コードを弄る必要がある。該当するアプリが少ない。

• 小簡単に回避出来る。

5


概要

6


プロダクションでどの JDK を使っていますか？

7

• JDK 9 EA Jigsaw ビルド

• JDK 9 EA

• JDK 8

• JDK 7

• JDK 6

• JDK 5.0 or その前


8

Java は相変わらず後方互換性に専念


9

しかし、既存のプログラムに大きい影響を及ぼす可能性のある変更は多い

注意：本セッションはすべての非互換性をカバーしない可能性がある。


甲の薬は乙の毒

• Java2D の font metrics のバグが JDK 1.2 で修正された

• [某重要お客様] は従来の振舞はバグであったことを認めた

• しかし –デプロイ済みのアプリがバグの振舞に依存していた

–修正を無効にするためのフラグが追加された

10

ある人の修正はほかの人のバグになる


“Sun” から “Oracle” へ

• 幾つかの Properties を “Sun” のから “Oracle” に変更する予定を 2010 にお知らせした

• Eclipse が Property を利用して JVM (HotSpot vs. J9 など)を区別し、の起動引数を選ぶ

• Eclipse が準備を完了するまで変更を延長した

11


私達も

• JDK 7 の HashMap の仕様「このクラスはマップの順序を保証しません。」

• JDK ７uX のある修正で HashMap が返す要素の順番が変わった

• JDK の一部のコードが従来の順番に依存していた

• 対応するために修正を延長した

「実装ではなく、仕様に対して開発すべき」

12


このような例は山ほどある

13


Java は相変わらず後方互換性に専念

しかし、すべての既存プログラムは必ず次のリリースでそのまま正しく動く保障はない

14


リリースの互換性の範囲

Behavioral

Bin

ary

Security Update Releases (CPU), 8u75, 8u81, 8u85, …

Feature Update Releases (PSU), 8u20, 8u40,

…

Note: Figure not drawn to scale.


プラットフォームリリースの互換性の範囲

Behavioral

Bin

ary

Platform Release, JDK 8 GA, JDK 9

GA

Note: Figure not drawn to scale.


• バグ修正

• 対応アルゴリズムの変更

• セキュリティ改善

• サポート対象のプラットフォームの変更

• ネイティブコードの使用

• Properties の変更

• 非推奨の警告

• デプロイ系の変更（browser）

• 内部実装の変更 – GC アルゴリズム

–内部の API の使用

• パッケージ –ファイル名、内部ファイルの形式、

–レジストリのキー(Windows)、インストール先（ディレクトリ）

• ツールやファイルの排除

17

非互換性の原因（代表）


• バグ修正

• 対応アルゴリズムの変更

• セキュリティ改善

• サポート対象のプラットフォームの変更

• ネイティブコードの使用

• Properties の変更

• 非推奨の警告

• デプロイ系の変更（browser）

• 内部実装の変更 – GC アルゴリズム

–内部の API の使用

• パッケージ –ファイル名、内部ファイルの形式、

–レジストリのキー(Windows)、インストール先（ディレクトリ）

• ツールやファイルの排除

• 非推奨のメソッド、クラス、機能の排除

18

JDK 9 の非互換性の原因


JDK 9 の #1 の非互換性

自分のアプリが依存するサードパーティーのライブラリやツールが非互換性によって影響を及ぼされる

• 影響を及ぼされるフレームワークやライブラリの開発者にすでに連絡した

• JDK 9 のリリース前に殆どのベンダーや組織がアップデートを提供する見込み

• 自分のシステムは新しいバージョンへアップデートするまで影響が発生する

19


大コードを弄る必要がある。該当するアプリが多い。

20


JEP 260: Encapsulate most internal APIs

• デフォルトで殆どの内部の API をアクセスすることが出来なくなる

• 幾つかよく利用されている API が一時的にアクセス可能のまま –代用できる public API がまだないことが前提

• JDK 8 に含まれている jdeps ツールを使って、内部 API の利用を検出することが出来る。（JDK 9 に含まれているバージョンの利用を推奨）

• Multi-Release JAR files (JEP 238) が JDK バージョンによって専用のクラスファイルをサポートする

• JDK 9 ではコマンドラインのフラグで従来の振舞に戻すことが可能

JDK の内部の API を利用不可になる

21

http://openjdk.java.net/jeps/260


JEP 223: New Version String Scheme

• JDK 8 以前の version string が複雑で標準化されていない

• 新しい仕組みはセマンティックバージョニングを準拠し、従来の歴史的な部分（1.x や u など）を排除

• 該当する properties が変更される

• JDK のファイル名も変更する

• JDK ９だけが変更されるために、両方の仕組みを対応する必要があるコードは多い

JDK 1.9.0_25 から JDK 9.1.9 へ

22

http://openjdk.java.net/jeps/2２３


JEP 220: Modular Run-Time Images

• モジュール化によって JDK 内部の構成が大きく変わる

• ディレクトリ名やファイル名などが変更される

• JDK のインストールディレクトリの中身を見て何かを判断するコードが動かなくなる可能性がある

rt.jar の排除

23



中コードを弄る必要がある。該当するアプリが少ない。

24


殆どの sun.misc.* と sun.reflect.* API の排除

• 代用出来る public API がまだ存在しないものが一時的に残る – sun.misc.Unsafe

– sun.misc.{Signal,SignalHandler}

– sun.misc.Cleaner

– sun.reflect.Reflection::getCallerClass

– sun.reflect.ReflectionFactory

• 上記以外の sun.{misc,reflect}の API が排除される –例：sun.misc.Base64

例外は JEP 260 が指摘する

25



JEP 214: Remove GC Combinations Deprecated in JDK 8

• JEP 173 によって JDK 8 この GC アルゴリズムの組み合わせが非推奨になった

• 下記のGC アルゴリズムの組み合わせを指定するとエラーが発生する – DefNew + CMS: ParNew + SerialOld: -XX:+UseParNewGC

– ParNew + iCMS: -Xincgc

– ParNew + iCMS: -XX:+CMSIncrementalMode -XX:+UseConcMarkSweepGC

– DefNew + iCMS: -XX:+CMSIncrementalMode -XX:+UseConcMarkSweepGC -XX:-UseParNewGC

– CMS foreground: -XX:+UseCMSCompactAtFullCollection

– CMS foreground: -XX:+CMSFullGCsBeforeCompaction

– CMS foreground: -XX:+UseCMSCollectionPassing

• インクリメンタル CMS (iCMS) は排除

26



基本のルール：認識されない VM オプションに注意

• 認識されないオプションを利用する場合 JVM は起動しない

• JDK 8 で非推奨になったオプションを利用すると、警告が出力される $ java -XX:MaxPermSize=1G -version

Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize; support was removed in 8.0

• JDK 9 で排除されたオプションを利用する場合、 JVM が起動しない場合がある – PermGen が JDK 8 で排除された (JEP 122)

27



JDK 8 で始まった作業(JEP 162: Prepare for Modularization)の続き

• addPropertyChangeListener と removePropertyChangeListener を排除 – java.util.logging.LogManager から

– java.util.jar.Pack200/Unpack200 から

• com.sun.security.auth.callback.DialogCallbackHandle の排除

28



JEP 231: Remove Launch-Time JRE Version Selection

• JDK 5 で導入された Multiple JRE (mJRE) でアプリを実行する JRE のバージョンを指定することが出来た

• Jar ファイルの manifest やコマンドラインで指定することが出来た

• 実は JRE のバージョンを指定することは思ったより複雑であり、現在はもっと適切な選択肢がある

• JDK 9 では manifest で指定されたバージョンが無視され、コマンドラインで指定する場合 JVM が起動しない

29



JEP 182: Policy for Retiring javac –source and –target options

• {-source,-target} 1.5 は JDK 8 で非推奨になった

• JDK 9 では 1.6 以上しかサポートしない

• 新しいポリシーとしては、”one plus three back” –例： JDK 9 は 6, 7, 8, 9

JDK 10 は 7, 8, 9, 10

30



java.awt.peer と java.awt.dnd.peer パッケージが隠蔽

• このパッケージの機能はサポートされている他の API からアクセスすることが出来る

• jdeps が検出し、代用出来る API を提案する

• OpenJDK でアナウンス済み、評判は良い

明確ではなかったが、toolkit の実装のためだけだった

31


JEP 240: Remove the JVM Tool Interface hprof Agent

• ソースコードは OpenJDK からアクセスが出来る

• JVM TI のデモだけとして JDK に含まれていた – 「 This is demonstration code for the JVMTI interface and use of BCI, it is not an official

product or formal part of the JDK. 」

• Heap dumps (heap=dump) は JVM の内部で実装されている (jmap –dump や GC.heap_dump)

• メモリアロケーションプロファイリング (heap=sites) は VisualVM など

• CPU プロファイリング (cpu=samples, cpu=times) は JFR や VisualVM

Libhprof.so

32



JEP 241: Remove the jhat Tool

• ソースコードは OpenJDK からアクセスが出来る

• java.net の HAT (Heap Analysis Tool) から JDK 6 に追加された

• サポートされず、実験的であれ、時代遅れのもの

• ドキュメントから「NOTE: This tool is experimental and may not be available in future versions of the JDK.」

• より便利なツール（MAT など）はかなり前からあった

33



RMI の HTTP プロキシの仕組みは JDK 8 で非推奨へ

• RMI HTTP プロキシの実装の排除 (JDK-8066750)

• RMI/JRMP HTTP tunneling の実装の排除

• 設計レベルの問題は最初からあった。。。

JDK 9 で排除

34


Thread::stop(Throwable) が例外を throw する

• Thread::stop メソッドは危険であり、オブジェクトのデータの整合性を失う可能性がある。JDK 1.2 から非推奨であった。

• JDK 9 で UnsupportedOperationException を throw する

• 引数がないバージョン (Thread::stop()) は残る –このメソッドも危険だけど、thread::stop(Throwable) よりよく利用されている

JDK-7059085

35


Serialized Applet 機能の排除

• シリアライズオブジェクトとしてアプレットをデプロイする機能だった

• 現代的の圧縮技術と JVM のパフォーマンスのおかげで利用する価値はもうない

• アプレット自体もそもそも非推奨になった

JDK-8074161

36

https://bugs.openjdk.java.net/browse/JDK-8074161




JNLP Parsing が厳しくなる

• JDK 8 までは JNLP 形式の分のエラーがあっても処理される（可能な場合）

• セキュリティのためにルールを厳しく実施する

• 問題ある場合は修正しやすいはず。

JDK-8075605

37





非サポートのアップル時代の API の排除

• JEP 272: Platform-Specific Desktop Features の排除 – com.apple.eawt

– com.apple.eio

– java.awt の機能でリプレースする

• com.apple.concurrent の排除 JDK-8148187

• AppleScript scripting engine の排除 JDK-8143404

JDK 7でアップル社から貰ったコード

38









com.sun.image.codec.jpeg

• 別の正式の API が 1.4 (2002)からあった

• OpenJDK には含まれていない

• JDK 7 から非推奨

JDK-8038838

39





JEP 271: Unified GC Logging

• GC ログの出力（形式）が変わる –ログ出力を分析するツールを修正する必要がある場合はある

• いろんなログのフラグが非推奨になって、新しいフラグでリプレース – -XX:+PrintGC -> -Xlog:gc

– -XX:+PrintGCDetails -> -Xlog:gc*

– -Xloggc:<filename> -> -Xlog:gc:<filename>

• ４３件の珍しいフラグが排除される（JDK-8145092）

JEP 158 JVM Logging framework を利用して GC ログを再実現

40









「_」は identifier (識別子)として利用出来なくなる

• JEP 213: Milling Project Coin に含まれている

• 既に JDK 8 ではラムダ式の引数として利用出来なかった

• JDK 8 で利用する時警告が出力される

JDK-8061549

41






32-bit Windows の Client VM の排除

• JDK 8 までは 32-bit Windows 上のデフォルトの VM が Client であった

• Client VM に似ている振舞を Server VM で実現するには – TieredStopAtLeve を１に設定する (C1 JIT のみになる）

– Compilation threshold を設定する（例 10,000 -> 1,000）

– Code cache のサイズを小さくする

– G1 ではなく ParallelGC を利用する

Server VM のみがサポートされる

42


デプロイの機能（Applet や javaws）はクライアントのプラットフォームだけをサポートする

• サポート対象 – Windows 7, 8, 19

– Ubuntu Linux

– MacOS (OSX)

• サポート対象外 (例) – Oracle Linux

– Red Hat Linux

– Solaris

– Windows Server

43


小簡単に回避出来る。

44


G1 がデフォルトの GC へ

• JDK 8 以前、Parallel CG はデフォルトだった（殆どのプラットフォーム） –まだあるけど、デフォルトとして利用されていない

–コマンドラインのフラグを使うだけで JDK 9 でも利用することが出来る

• 例外 – 32-bit Windows はまだ Serial GC

– G1 がサポートされていないプラットフォームは変更なし

JEP 248: make G1 the Default Garbage Collector

45



JEP 252: Use CLDR Locale Data by Default

• Unicode Consortium‘s Common Locale Data Repository

• CLDR は JDK 8 で提供されているが、デフォルトとして利用されていない

• デフォルトの優先順： CLDR, JRE, SPI

• locale の名前や振舞が変わってくる場合がある

• java.locale.providers の propery で従来の優先順に戻すことが出来る

46



JavaDB の排除

• JavaDB は単純に Apache Derby のコピー

• JDK 7 と JDK 8 で付属されていた

• Apache プロジェクトから直接に入手が出来る

JDK-8004716

47


JDK 9 で非推奨になった

• Applet ベースのデプロイ

– Applet viewer

– Common DOM APIs: JDK-8074162

– classid サポート: JDK-8134712

• • VP6 video codec と FLV/FXM ファイル形式 (JavaFX Media) JDK-8134330

• • jarjar: JDK-8133595

• • CMS Garbage Collector

• • com.sun.jarsigner package JDK-8076535

• • Java Policy Tool

• • 時代遅れのセキュリティ API JDK-8050955

• • Doclet API, （代用 simplified doclet JEP 221)

（JDK 10 以来は排除される可能性がある）

48






まとめ 49


JDK 9 Information

• Current proposed schedule: GA July 2017, weekly updates:

– Early access binaries + docs: https://jdk9.java.net/

– Early access binaries with cutting edge Jigsaw: https://jdk9.java.net/jigsaw/

• OpenJDK : – Project: http://openjdk.java.net/projects/jdk9/

– Mailing list: http://mail.openjdk.java.net/mailman/listinfo/jdk9-dev

– Source code: http://hg.openjdk.java.net/jdk9/dev/

– Adoption: http://mail.openjdk.java.net/pipermail/adoption-discuss/ https://wiki.openjdk.java.net/display/quality/Quality+Outreach/

– JEPs (JDK Enhancement Proposals) used for project tracking

50

https://jdk9.java.net/

https://jdk9.java.net/jigsaw/

http://openjdk.java.net/projects/jdk9/

http://mail.openjdk.java.net/mailman/listinfo/jdk9-dev



http://hg.openjdk.java.net/jdk9/dev/

http://mail.openjdk.java.net/pipermail/adoption-discuss/



https://wiki.openjdk.java.net/display/quality/Quality+Outreach/




ご質問・ご相談等ございましたら、終了後もお受けしております

0120-155-096 （平日9:00-12:00 / 13:00-18:00）

http://www.oracle.com/jp/contact-us/overview/index.html

各種無償支援サービスもございます。

Oracle Digital 検索

Oracle Digital あなたにいちばん近いオラクル

52






Java SE 9 アップデートと移行のポイントotndnld.oracle.co.jp/ondemand/java-2016/Java_Seminar...Java SE 9 アップデートと移行のポイント 2016年12月2日 David

Documents