[Linux, Docker] Put Your Containers on a Diet with Oracle Linux

原文はこちら。
https://blogs.oracle.com/developers/put-your-containers-on-a-diet-with-oracle-linux

最小のコンテナが最良だってこと、皆さんご存知ですよね?
Oracleは、ビジネスアプリケーションにとって最も効率的なプラットフォームを有することの重要性を認識しています。そして、そうしたアプリケーションのミッションクリティカルデリバリに最良のプラットフォームがOracle Linuxであると信じています。
Oracle Linux
https://www.oracle.com/linux/index.html
効率とセキュリティを確保する一つの方法として、できる限りコンテナに余分なものを入れないことがあります。Oracle Linuxイメージは今でも巨大ではありませんが、多くの必須ではないコンポーネントをできる限り取り除いてかなりサイズを小さくすることに成功しました。

Introducing the new Oracle Linux slim images for Docker

新しいベースイメージである、Oracle Linux 7-slim Docker Imageを導入しました。このイメージはわずか114MBです。
Oracle Linux 7-slim Docker image
https://hub.docker.com/_/oraclelinux/
確かに、Alpineほど小さくありませんが、他の主要なディストリビューションの中では最小のBaseイメージです。どれほど小さいかを是非グラフの数値でご確認ください。

このイメージは本当に小さく、テキストエディタすら入っていません。すべてのものを取り除いて、あなたのコンテナのためにできるだけ小さなイメージに仕立てました(したがって、攻撃される可能性も最小です)。しかし、yumは有効になっていて動作するので、実行したいサービスに必要なパッケージは簡単に入手できます。

Let's take the slim image for a spin

新しいスリム・イメージから独自のコンテナを構築するのは、DockerfileFROM:oraclelinux:7-slimを指定するだけです。公式のOracle LinuxイメージはすべてDocker Hubに公開されており、誰でも自由にダウンロード、配布、使用することができます。また、すべてのイメージでOracle Yum Serverからアップデートを取得できるため、コンテナ構築時に最新のセキュリティ修正および更新を適用できます。 さらに、OracleはCVE (Common Vulnerabilities and Exposures) がリリースされるたびにこれらのイメージを更新しますので、アップデートのほとんどは我々が実施します。

では、slim imageを拡張し、最新のPHPリリースを提供するSoftware CollectionをインストールするDockerfile の例を見てみましょう。
このイメージのビルドの結果、Docker Hubから入手できる公式PHP 7.0 CLIイメージよりもおよそ130MBほど小さいコンテナが作成されます。
イメージサイズの比較
1 php-ol7-slim 7.0 ed603c8d47a0  235.4 MB
2 php 7.0 6c38128f3482 363 MB

So where to from here?

まだGitHub上の公式Oracle Dockerfilesをチェックされていない場合には、是非チェックしてください。
oracle/docker-images
https://github.com/oracle/docker-images
Oracleのプロダクト・チームは、Database、WebLogic Server、Javaなどといった、利用可能なOracle製品のサンプルDockerfilesを数多く提供しています。独自のイメージを作成したくない場合は、Oracle Container Registryからイメージを取得するだけで、すぐに作業を開始できます。
Oracle Container Registry
https://container-registry.oracle.com/
Software Collections for Oracle Linuxリポジトリを有効化すれば、Oracle Linuxでサポートする全ての言語やサーバーソフトウェアの最新版を取得することができます。
Software Collection Library 2.3 for Oracle® Linux
http://docs.oracle.com/cd/E52668_01/E59096/html/index.html
Software Collections でご利用いただける全てのコンテンツは既存のOracle Linux Premier Supportサブスクリプションの対象です。

他のOracle開発者とDockerについて会話したい場合には、Oracle Technology NetworkにDocker and containersという専用コミュニティを用意していますので、そちらへどうぞ。
Containersスペース
https://community.oracle.com/community/server_&_storage_systems/containers

[Java] Plans for 2017 and Beyond

原文はこちら。
https://blogs.oracle.com/jcp/entry/jcp_meeting_jump_starts_plans

2017年も約2ヶ月が過ぎ、ほとんどの人が新年の抱負を忘れているかもしれませんが、Java Community Process(JCPプログラム)はそんなことはありません。 2017年が本格的に動き出すにつれて、自身のビジョンと優先事項を共有したいと考えています。自身はJCPプログラムに16年以上関わっており、現在JCP議長を務めています。この立場で奉仕できることを光栄に思っていますし、長年にわたり力を入れているJava Communityとの仕事を続けていくことに夢中になっています。Java開発者は、Javaテクノロジ成功の主な理由の1つのみならず、この惑星の最高の人々でもあります。リーダーや世界を駆け回る国際的なスピーカーといった様々な役割をJCPプログラムの中で務めてきたので、訪問国に関係なく、Java開発者コミュニティの寛大さ、優しさ、知性に驚かされ、共感しています。コミュニティであることこそが、何年もJCPプログラムで仕事を続けてきた理由です。
非常に技術的なコミュニティであっても、基本的には「人」であることが、はっきりと分かりました。この理念を念頭に置いて、私たちはコミュニティからのJCPプログラムへの参加を引き続き拡大する予定で、2016年の会員増強の成功の勢いを足がかりにします。2016年5月以来、300名以上の新会員がJCPプログラムに加わりました。
Java Community Process (JCP) version 2.10 with a focus on broadening JCP Membership takes effect 12 May
https://jcp.org/en/press/news/JCP_210_JSR364
JSR 364の完成に伴ってメンバーシップを拡大しました。このJSR 364は企業、個人開発者、Javaユーザーグループ(JUG)からのJCPメンバーシップを拡大する目的で策定され、結果JCPプログラムの最新バージョンJCP 2.10ができました。
JSR 364: Broadening JCP Membership
https://jcp.org/en/jsr/detail?id=364
JCP 2.10: Process Document
https://jcp.org/en/procedures/jcp2
2017年には、年間のJCP Award、Star Spec Leadの認知、グローバルAdoptionプログラム(Adopt-a-JSRとAdopt OpenJDK)を通じて、コミュニティ内のリーダーシップを引き続き讃えていきます。
JCP Program and Industry Awards
https://jcp.org/en/press/news/awards/awards_main
Star Spec Lead Program
https://jcp.org/en/press/news/star
JAVA COMMUNITY PROCESS
https://community.oracle.com/community/java/jcp 
JCPプログラムの力仕事は、Java Specification Requests(JSR)のコミュニティ開発を通じて起こります。Javaプラットフォームを発展させるJSRと、プラットフォームの最新版、Java Standard Edition(Java SE)9およびJava Enterprise Edition(Java EE)8を完成させる作業は年間を通じて継続します。
JSR 379: JavaTM SE 9 Release Contents
https://jcp.org/en/jsr/detail?id=379
JSR 366: Java Platform, Enterprise Edition 8 (Java EE 8) Specification
https://jcp.org/en/jsr/detail?id=366
さらに、ECメンバーであるGoldman Sachsがロンドンで開催したJCP Executive Committee(EC)とのFace-to-Faceミーティングでの議論の後、JCP ECがJCPプログラムで改善できる領域が以下の3個あることを確認しています。
  • JCPとOpenJDKの関係
    2グループ間のやりとりを合理化して改善できる領域を調査
  • Java MEの将来
    組み込みおよびIoT関連領域における技術的およびビジネスマーケットの要求の両方を定義
  • JCP.Nextの作業を通じたJCPのさらなる変革
    JCPプログラム内で共同開発を改善できる分野を特定
これらが来年注力する領域です。JCPミーティングのサマリーとJCP_orgのtwitterフィードでの議論をフォローしてください。私の個人的なTwitterアカウント@heathervcでも見つけることができます。
JCP EXECUTIVE COMMITTEE MEETING MATERIALS
https://jcp.org/en/resources/EC_summaries
JCP.org@Twitter
https://twitter.com/jcp_org
Heather VanCura@Twitter
https://twitter.com/heathervc
これらのアイテムについては、一年を通して議論を深めていきます。2017年もその先も、Java開発者コミュニティと協力していくことを楽しみにしています。

[Java] Creating Custom JDK9 Runtime Images

原文はこちら。
https://blogs.oracle.com/jtc/entry/creating_custom_jdk9_runtime_images

JDK9の新機能である、カスタムランタイムイメージ作成方法の概要は、以下のYouTube動画をご覧ください。

この動画の補遺として、最近公開したブログで、NetBeansプロジェクト内でランタイムイメージの作成自動化について説明しています。詳細は以下のエントリをご覧ください。
Automating the Creation of JDK9 Reduced Runtime Images
https://blogs.oracle.com/jtc/entry/automating_the_creation_of_jdk9
[Java] Automating The Creation of JDK9 Reduced Runtime Images in NetBeans
https://orablogs-jp.blogspot.jp/2017/02/automating-creation-of-jdk9-reduced.html
信じられないのですが、このブログを始めてから10年経ち、75件のエントリを投稿しました!

[Java] Automating The Creation of JDK9 Reduced Runtime Images in NetBeans

原文はこちら。
https://blogs.oracle.com/jtc/entry/automating_the_creation_of_jdk9

JDK9の次期リリースでは、Java SEプラットフォームはモノリシックな構造に変わって、一連のモジュールを組み合わせて構築されます。
JDK 9 Project
https://jdk9.java.net/
この大きな変化に伴い、開発者は自身のアプリケーションをモジュール化することができ、さらに、アプリケーションを実行するために必要なモジュールだけを使ってランタイムイメージを作成することができます。この大規模な進化について多くの記事が出ていますし、これからも出てくることでしょう。今日は、カスタムランタイムイメージを作成する機能と、NetBeansなどの統合開発環境でその作成方法を自動化する方法について説明します。
NetBeans IDE
https://netbeans.org/
最初に、早期アクセス版JDK9と、それに対応する早期アクセスJDK9対応 NetBeansをダウンロードして、始めることにしましょう。
JDK™ 9 Early Access Releases
https://jdk9.java.net/download/
NetBeans IDE Nightly Build ダウンロード
http://bits.netbeans.org/download/trunk/nightly/latest/
このレシピでは、SimpleAppという非常に単純なJDK9アプリケーションを作成し、Java Logging APIを使用してメッセージをログに記録します。
Package java.util.logging
http://download.java.net/java/jdk9/docs/api/java/util/logging/package-summary.html
すべてのJava 9プログラムでは、java.baseというモジュールを使用する必要があります。このプログラムでロギングメソッドを呼び出すためには、java.loggingと呼ばれる追加のモジュールを取り込む必要があります。以下はNetBeansプロジェクトとソースコードの例です。

NetBeansでこのプログラムを実行すると、出力ウィンドウに以下のような表示が現れます。

このプログラムをモジュール化するために、まずモジュールの依存性を識別する必要があります。JDK 9のユーティリティjdepsを使って、以下のようにこの作業を実行することができます。

最初に、jdeps -versionを呼び出し、JDK 9版のjdepsを使っていることを確認します。続いて、NetBeansで作成した SimpleApp.jar に対して jdeps -s を呼び出し、モジュール依存性を取得します。この例では、作成したプログラムには2個のモジュールが必要です。前述の通り、全てのJava 9アプリケーションはデフォルトで java.base というモジュールが必要です。さらに、今回のプログラムではモジュール java.logging のメソッドを呼ぶため、 java.logging にも依存します。
この情報を基に、SimpleAppプロジェクトを右クリックし、New->Java Module Info...を選択してNetBeansプロジェクト内にファイル module-info.java を作成します。

作成した後、module-info.javaはSimpleAppのデフォルトパッケージになります。モジュール仕様は最初は空で、以下のように2個のrequiresと、1個のexportsを追加します。

module-info.java を適切に設定したのち、 SimpleApp をビルドします。NetBeansはコンパイル済みの module-info.class をSimpleApp.jarに追加し、モジュールのJarファイルにします。
ゲームの少し早い段階ですが、JDK9のjlinkユーティリティを使用してランタイムイメージを構築する機能が、現時点でNetBeansには欠けているように見えるので、この機能を提供するようNetBeansをカスタマイズしてみましょう。より洗練されたソリューションは間違いありません。この機能を使えば、実際に実行されるJavaコマンドを出力することで、デバッグを支援することができます。
まず、SimpleAppのNetBeans project.propertiesファイルを探して編集します。 このファイルはNetBeansの[ファイル]タブをクリックすると、プロジェクトのファイルシステムビューが表示されます。 nbproject ディレクトリの下に、project.propertiesファイルがあります。 project.propertiesをダブルクリックすると、そのファイルを編集用に開くことができます。

以下のテキストを projects.properties ファイルの最後に追加します。
#
# Added to support creation of modular jar and jlink image.
# Change this property to match your JDK9 location
#
jdk9.basedir=C:\\Users\\jtconnor\\jdk-9
#
modular.jar.command=${jdk9.basedir}\\bin\\jar.exe
modular.jar.file=${dist.dir}\\${application.title}.jar
#
modular.jar.arg1=--verbose
modular.jar.arg2=--update
modular.jar.arg3=--file
modular.jar.arg4=${modular.jar.file}
modular.jar.arg5=--main-class
modular.jar.arg6=${main.class}
modular.jar.arg7=--module-version
modular.jar.arg8=1.0
modular.jar.arg9=-C
modular.jar.arg10=${build.dir}\\classes
modular.jar.arg11=module-info.class
modular.jar.args.concatenated=${modular.jar.arg1}  ${modular.jar.arg2} ${modular.jar.arg3} ${modular.jar.arg4}  ${modular.jar.arg5} ${modular.jar.arg6} ${modular.jar.arg7}  ${modular.jar.arg8} ${modular.jar.arg9} ${modular.jar.arg10}  ${modular.jar.arg11}
#
jlink.command=${jdk9.basedir}\\bin\\jlink.exe
jlink.module.dependency1=${modular.jar.file}
jlink.module.dependency2=${jdk9.basedir}\\jmods
jlink.module.path=${jlink.module.dependency1};${jlink.module.dependency2}
jlink.image.dir=${dist.dir}\\jimage
#
jlink.arg1=--module-path
jlink.arg2=${jlink.module.path}
jlink.arg3=--add-modules
jlink.arg4=${application.title}
jlink.arg5=--output
jlink.arg6=${jlink.image.dir}
jlink.arg7=--compress=2
jlink.args.concatenated=${jlink.arg1} ${jlink.arg2} ${jlink.arg3} ${jlink.arg4} ${jlink.arg5} ${jlink.arg6} ${jlink.arg7}
まぁ悪くないですね。基本的には、JDK9のjarユーティリティとjlinkユーティリティを実行するためのコマンドライン引数を設定することです。この設定では、モジュールのjarやランタイムイメージ作成に失敗した場合のデバッグがより簡単にできるはずです。1点、重要なポイントとして、jdk9.basedirプロパティを適切に設定する必要があります。
#
# Added to support creation of modular jar and jlink image.
# Change this property to match your JDK9 location
#
jdk9.basedir=C:\\Users\\jtconnor\\jdk-9  <-- ここをご自身のJDK 9の場所に変更してください!
この手順が完了したら、SimpleAppのビルドファイル(build.xml)を変更しましょう。その前に、このファイルはFileタブのSimpleApp/ディレクトリにあります。build.xmlをダブルクリックしてファイルを編集します。

ファイルを開き、最終行に移動します。追加のantタスクを</project>の前に以下のように配置します。

以下は追加するテキストです。
<target name="-post-jar" depends="-do-modular-jar,-do-jlink">
    </target>
    
    <target name="-do-modular-jar">
        <echo message="Updating ${dist.jar} to be a modular jar."/>
        <echo message="Executing: ${modular.jar.command} ${modular.jar.args.concatenated}"/>
        <exec executable="${modular.jar.command}">
            <arg value="${modular.jar.arg1}"/>
            <arg value="${modular.jar.arg2}"/>
            <arg value="${modular.jar.arg3}"/>
            <arg value="${modular.jar.arg4}"/>
            <arg value="${modular.jar.arg5}"/>
            <arg value="${modular.jar.arg6}"/>
            <arg value="${modular.jar.arg7}"/>
            <arg value="${modular.jar.arg8}"/>
            <arg value="${modular.jar.arg9}"/>
            <arg value="${modular.jar.arg10}"/>
            <arg value="${modular.jar.arg11}"/>
        </exec>
    </target>
    
    <target name="-do-jlink">
        <echo message="Creating jlink image in ${jlink.image.dir}/."/>
        <echo message="Executing: ${jlink.command} ${jlink.args.concatenated}"/>
        <exec executable="${jlink.command}">
            <arg value="${jlink.arg1}"/>
            <arg value="${jlink.arg2}"/>
            <arg value="${jlink.arg3}"/>
            <arg value="${jlink.arg4}"/>
            <arg value="${jlink.arg5}"/>
            <arg value="${jlink.arg6}"/>
            <arg value="${jlink.arg7}"/>
        </exec>
    </target>
SimpleApp プロジェクトの変更が完了しました。NetBeansでSimpleAppを "Clean and Build" すると、追加したantタスクが実行されます。以下はNetBeansの出力ウインドウに現れた出力例です。

最後に、ビルドされたものとカスタムランタイムイメージの実行方法を見てみましょう。 以下のスクリーンショットでは、NetBeansによって構築されたSimpleAppのdistディレクトリを調べています。SimpleApp.jar(モジュールjarファイル)とjimage ディレクトリ(カスタムランタイムイメージ)の2つのエントリがあることがわかります。続いて、JDK9ランタイムであることを示すためにjimage ディレクトリでjava -versionを実行し、java -list-modulesを実行して、このランタイムに含まれるモジュールを表示します。ここでは、3個のみ現れますが、本格的なJDK9ランタイムの場合は、通常90個前後現れます。そして最後のコマンドでは、SimpleAppアプリケーションがjimage/ ランタイムからどのように実行されるかを示しています。

上記の例はWindowsプラットフォームの場合です。LinuxやMacで実施したい場合には、project.propertiesファイルを適宜変更する必要があります。このエントリがJava 9の新機能のいくつかの理解に役立つことを願っています。

[Database] Client Certification for Oracle Database 12.1.0.2/12.2.0.1

原文はこちら。
https://blogs.oracle.com/UPGRADE/entry/client_certification_for_oracle_database

先日Oracle Database 12.2.0.1に対するクライアントの動作保証に関する質問を受けました。
この質問に回答する内容が、My Oracle Supportの以下のドキュメントです。
Client / Server Interoperability Support Matrix for Different Oracle Versions (ドキュメントID 207303.1)
https://support.oracle.com/rs?type=doc&id=207303.1
このドキュメントではOracle Database 9.2にまでさかのぼって、クライアントの互換性を取り扱っており、非常に役に立つリソースです。
Client Certification Oracle Database
忘れないでいただきたいのは、時として、クライアントソフトウェアにもパッチが必要になることがある、ということです。定期的にメールをやりとりしているお客様はDatabaseをOracle Database 12.1.0.2にアップグレードしたばかりでしたが、すでに最新のJDBCクライアントを使っているにもかかわらず、JDBCクライアントでたびたび奇妙なエラーを見かけました。

以下のメッセージと共に、ORA-904, ORA-923 and ORA-920が発生していました。
oracle.jdbc.driver.OracleParameterMetaDataParser.computeBasicInfo(OracleParameterMetaDataParser.java:277)
結局JDBCクライアントにもパッチが必要だったということがわかりました。つまり、12.1.0.2クライアントに対し、マージパッチ #21623553 を当てる必要があったのです。
パッチ21623553: MERGE REQUEST ON TOP OF 12.1.0.2.0 FOR BUGS 21185279 21455135
https://support.oracle.com/rs?type=patch&id=21623553
このマージパッチは、別の有用な修正と共に、JDBCクライアント向けマージパッチ #24012252 として統合されました。
パッチ24012252: MERGE REQUEST ON TOP OF 12.1.0.2.0 FOR BUGS 22603057 20362778 23345279
https://support.oracle.com/rs?type=patch&id=24012252 
パッチ適用後、エラーは出なくなりました。JDBCクライアントへの推奨パッチは、以下のMy Oracle Supportのドキュメントをご覧ください。
Recommended patches on JDBC 12.1.0.2.0 version (ドキュメントID 2227214.1)
https://support.oracle.com/rs?type=doc&id=2227214.1
さらに言えば、OTNから簡単にダウンロードできデプロイできるInstant Clientの存在もお忘れなく。
Oracle Instant Client Downloads
http://www.oracle.com/technetwork/database/features/instant-client/index-097480.html
Oracle Instant Client Download OTN

[Database] Updated In-Memory Advisor Now Available

原文はこちら。
https://blogs.oracle.com/In-Memory/entry/updated_in_memory_advisor_available

Oracle Database In-Memory Advisorがアップデートされました。ドキュメントも同時に更新されています。詳細は、My Oracle Supportの以下のドキュメントをご覧ください。
Oracle Database In-Memory Advisor (Doc ID 1965343.1)
https://support.oracle.com/rs?type=doc&id=1965343.1
このアップデートには以下のものが含まれています。
  • スキーマやオブジェクト名などの属性によって、メモリ上に配置されると考えられるオブジェクトをフィルタリングできるようになりました
  • Oracle Database 12c Release 2を包括的にサポートします
  • Oracle Database 12c Release 2で導入されたマルチテナント・データベースでの機能強化されたPDBレベルのAWRデータをサポートします
  • 不具合の修正ならびに拡張性の強化

[Java] Early Access documentation for Oracle JDK 9 has been released

原文はこちら。
https://blogs.oracle.com/thejavatutorials/entry/early_access_documentation_for_oracle

Oracle JDK 9早期アクセスリリースのドキュメントが本日リリースされました。
是非チェックしてください。
Oracle JDK 9 Documentation Early Access
http://docs.oracle.com/javase/9/
このドキュメントにはアップデートされた開発者ガイド、移行アシスタンス、このリリースでの新機能リストが含まれています。
JDK 9早期アクセスリリースは以下のURLからダウンロードできます。
JDK™ 9 Early Access Releases
https://jdk9.java.net/download/

[Java] Filter Incoming Serialization Data - a little of JDK 9 goodness available now in current release families

原文はこちら。
https://blogs.oracle.com/java-platform-group/entry/incoming_filter_serialization_data_a

JDK 9向けに開発されている新機能の一つが、JEP 290:Filter Incoming Serialization Dataです。この機能がJDK 8、7、6にバックポートされました。
JEP 290: Filter Incoming Serialization Data
http://openjdk.java.net/jeps/290
(訳注)
JDK 7、JDK 6はJava SEに対するサポート契約をOracleと締結されている方のみご利用いただけます。

着信シリアライズデータのフィルタリング方法として、オブジェクトのシリアル化に対する保護ならびに堅牢化のための層をもう一つ追加します。このフィルタリングメカニズムを使用することにより、開発者はアプリケーションがデシリアライズ可能なクラスを制限できます。ほとんどのセキュリティ機能と同様に、この新機能は現在のセキュア・コーディングのプラクティスを置き換えるものではなく、こうしたプラクティスに追加することを目的としています。
Secure Coding Guidelines for Java SE
http://www.oracle.com/technetwork/java/seccodeguide-139067.html
この機能はJDK 9の早期アクセスリリースでご利用いただけますが、現在のバージョンの利用者にもこの機能を使ってもらいたい、ということで、2017年1月のCritical Patch Update(8u121、7u131、6u141)に対しても導入されました。
Jan 2017 Critical Patch Update
http://www.oracle.com/technetwork/security-advisory/cpujan2017-2881727.html(英語)
http://www.oracle.com/technetwork/jp/topics/ojkbcpujan2017-3454417-ja.html(日本語)
詳細は、対応するリリースのリリースノートをご覧ください。
JDK Release Notes
http://www.oracle.com/technetwork/java/javase/jdk-relnotes-index-2162236.html

[Java] Gear up for Java SE 9

原文はこちら。
https://blogs.oracle.com/java/gear-up-for-java-se-9

ご存知のように、Java SE 9はfeature completeに達し、Ramp Downプロセスがスタートしました。これはモジュールシステムがJavaプラットフォームに導入されるという、重要なリリースになることでしょう。リリースは2017年7月を予定しています。現在、今月リリースされた早期ドラフトレビュー仕様がご覧いただけます。
JSR 379: JavaTM SE 9 Release Contents
https://www.jcp.org/en/jsr/detail?id=379
今すぐあなたのコードがJDK 9で動作することを確認してください。願わくば、この情報を既にご覧になっていることを期待します。

JavaアーキテクトのAlan Batemanは、昨年のJavaOneで「Prepare for JDK 9」というセッションで講演しました。このセッションでは、非推奨プロセス(deprecation process)、カプセル化(encapsulation)、非サポートのAPI、コードのテスト方法などを説明しました。

彼のセッションに追加して、彼が言及していたJEPおよびツールについて詳細に知っておく必要があるでしょう。
以前のリリースと同様、このリリースでも後方互換性の確保は重要と考えています。これまでのように、APIが非推奨になった時点で通知システムが作動します。このJEP 277(Enhanced Deprecation)で、このプロセス、ステータス、APIの意図する処分について説明しています。
JEP 277: Enhanced Deprecation
http://openjdk.java.net/jeps/277
ほとんどの内部APIがデフォルトでアクセスできなくなりますが、重要な、幅広く利用されている内部APIは、サポートされる代替APIができるまでアクセスできます。ほとんどの内部APIのカプセル化について説明するJEP 260(Encapsulate Most Internal APIs)では、引き続きアクセスできる重要な内部APIを説明しています。
JEP 260: Encapsulate Most Internal APIs
http://openjdk.java.net/jeps/260
例えばこのようなAPIを使っている3rdパーティライブラリに依存している場合、ご利用のアプリケーションがJDKの内部APIを利用していることがわからない可能性があります。そのような場合には、Jdeps(Java dependency analysis tool:Java依存性分析ツール)を使ってこうしたAPIを識別してください。このツールは、置換候補があれば、候補の提案もしてくれます。詳細は、Jdepsのページを参照してください。
Java Dependency Analysis Tool
Jdepshttps://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
強調してもしすぎることはないので、JDK早期アクセスリリースを使ってアプリケーションをテストしてください。Java 9早期アクセスリリースを今すぐダウンロードしましょう。
JDK™ 9 Early Access Releases
https://jdk9.java.net/download/access
Key links to bookmark:
Related Blogs:

[Database] Announcement: Oracle Database 12c Release 2 on Exadata and SuperCluster

原文はこちら。
https://blogs.oracle.com/exadata/entry/announcement_oracle_database_12c_release

この10日はExadataにとって非常にわくわくさせるものでした。まず、30個以上の機能や強化ポイントを含むExadata Software 12.2.1.10をリリースしました。つづいてSoftware-in-SiliconのパワーがExadataシステムで利用できるようになった、Exadata SL6をローンチしました。そして、ExadataおよびSuperCluster用のオンプレミス版Oracle Database 12c Release 2をリリースします。

Oracle Database 12c Release 2では、Oracle Databaseの全ての面が強化されています。いくつかの特徴を見ていきましょう。
Oracle MultitenantはApplication Containerのサポートを強化します。MultitenantユーザーはCPUやI/Oリソースに加え、Pluggable Databaseのメモリリソースを管理することができるようになりました。Database In-Memoryは、より高速なJoinを可能にします。In-MemoryユーザーはJSONデータのインメモリクエリを実行できるようになりました。In-Memoryフォーマットをストレージに永続化することで、より高速な再起動を可能にしています。このリリースでは、既存の暗号化されていない表領域をインポート、エクスポートする必要なく、表領域をオンラインで暗号化できるため、データベースをよりセキュアにすることができます。Oracle Database 12c Release 2では、待望のOracle Native Shardingが導入されました。データベースの安全性、可用性、高速性、管理性が向上し、Developer Friendlyならしめる数多くの機能が搭載されています。

Oracle Database 12c Release 2の更なる差別化要素として、Exadataプラットフォームがあります。Exadataのユニークなリソース管理機能やI/O最適化機能上に構築された、以下の2機能はExadataおよびSuperClusterでだけご利用いただけます。
  • Active Data GuardスタンバイデータベースでのIn-Memory処理
  • 1Container Databaseあたり252個を超えるPluggable Databaseのサポート
このリリースでは、多くのユニークなExadataの機能、例えば階層型スナップショット、圧縮された索引のSmart Scanオフロード、XMLオペレータのSmart Scanの機能強化、End-to-EndのI/Oレイテンシキャッピング、拡張されたdistance clusterなどがサポートされています。詳細は、スライド、Webcast、以前のエントリをご覧ください。
Exadata Software 12.2.1.1.0
The Best Database Cloud Pla1orm
Just Got Be6er!
http://www.oracle.com/technetwork/database/exadata/exadatasoftware-12211-3521134.pdf
Exadata 12.2.1.1.0: The Best Database Cloud Platform Just Got Better
https://blogs.oracle.com/exadata/entry/exadata_12_2_1_1
Oracle Database 12c Release 2を最大限に活用するには、データベースを12c Release 2にアップグレードする前に、最新のExadata Softwareリリース12.2.1.10にアップグレードすることをお薦めします。Exadata Software 12.2.1.1.0では、Oracle Database 12c Release 2のSmart Scan機能をサポートしており、OSDC (Oracle Software Delivery Cloud) 経由で入手できます。
Oracle Software Delivery Cloud
https://edelivery.oracle.com/osdc/faces/Home.jspx
Exadata、SuperCluster以外のプラットフォーム用Oracle Database 12c Release 2のリリーススケジュールは、以下のサポートドキュメントをご覧ください。
Release Schedule of Current Database Releases (Doc ID 742060.1)
https://support.oracle.com/rs?type=doc&id=742060.1

[Database] DBMS_QOPATCH does not work in PDBs (right now)

原文はこちら。
https://blogs.oracle.com/UPGRADE/entry/dbms_qopatch_does_not_work

以下のエントリにコメントをくれたMurthyと、最終的にER(Enhancement Request)になったSR(Service Request)を起票してくれたSimCorpのJeannette Hollandに感謝します。
How to find out if a PSU has been applied? DBMS_QOPATCH
https://blogs.oracle.com/UPGRADE/entry/dbms_qopatch_datapatch_and_other

DBMS_QOPATCH in Multitenant

DBMS_QOPATCHはCDB$ROOT内で実行した場合に限り、インストール済みのパッチに関する有用な情報を取得できます。このデザインはOracle Database 12.1のセキュリティ上の理由によるものです。PDBにインストールされたパッチを確認する必要がある場合にも情報を取得することができます。

Testcase

JannetteのSRからテストケースを拝借しました。
SQL> COLUMN NAME FORMAT A8
SQL>
SQL> SELECT NAME, CON_ID, DBID, CON_UID, GUID FROM V$CONTAINERS ORDER BY CON_ID;

NAME     CON_ID DBID       CON_UID    GUID
-------- ------ ---------- ---------- ------------------
CDB$ROOT      1 3424772713 1          47C8525C0DFE49...
PDB$SEED      2 3983775695 3983775695 E6204BB1F6EB4F...
MYPDB1        3 7270044002 7270044002 B975668B860049...
MYPDB2        4 1943363979 1943363979 BCD7AAFAF3F641...
PDBで実行してみると……
ALTER SESSION SET container = myPDB;

Session altered.

SQL>  select * from OPATCH_XML_INV ;
ERROR:
ORA-29913: error in executing ODCIEXTTABLEOPEN callout
ORA-29400: data cartridge error
KUP-04080: directory object OPATCH_LOG_DIR not found


no rows selected

SQL> select dbms_qopatch.get_opatch_install_info from dual;
ERROR:
ORA-20001: Latest xml inventory is not loaded into table
ORA-06512: at "SYS.DBMS_QOPATCH", line 1986
ORA-06512: at "SYS.DBMS_QOPATCH", line 133
CDBで実行してみると……
SQL> ALTER SESSION SET container = cdb$root;

Session altered.

SQL>  select * from OPATCH_XML_INV ;

XML_INVENTORY
--------------------------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<InventoryInstance>


SQL> select dbms_qopatch.get_opatch_install_info from dual;

GET_OPATCH_INSTALL_INFO
--------------------------------------------------------------------------------
<oracleHome><UId>OracleHome-2d1c0910-36ac-429b-98db-96a353d423b6</UId><targetTyp

Solution

Oracle Database 12.1.0.2の場合、現時点で有効な解決策はありません。また、この挙動はドキュメントに記載されていないようです。結果として起票されたSRがEnhancement Requestとなりました。Oracle Database 12.1.0.2のPDBでは、以下の回避策がお役に立つかもしれませんが、DBMSのパッケージを呼び出すAPIを使うため、面倒でしかも簡単ではありません。
select patch_id, patch_uid, version, action, action_time, status, description from dba_registry_sqlpatch;
Oracle Database 12.2.0.1でテストしたところ、期待通りに動作してくれました。
SQL> create pluggable database PDB3 admin user adm identified by adm file_name_convert=( '/u02/oradata/CDB2/pdbseed', '/u02/oradata/CDB2/pdb3');

Pluggable database created.

SQL> alter pluggable database pdb3 open;

Pluggable database altered.

SQL> alter session set container=pdb3;

Session altered.

SQL> select dbms_qopatch.get_opatch_install_info from dual; 

GET_OPATCH_INSTALL_INFO
--------------------------------------------------------------------------------
<oracleHome><UId>OracleHome-3cb04a3a-3999-4767-86f1-bc845cab158e</UId><targetTyp

SQL>   select * from OPATCH_XML_INV ;

XML_INVENTORY
--------------------------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>         <Inv
entoryInstance> <ora

SQL> select xmltransform(dbms_qopatch.get_opatch_lsinventory, dbms_qopatch.get_opatch_xslt) from dual;

XMLTRANSFORM(DBMS_QOPATCH.GET_OPATCH_LSINVENTORY,DBMS_QOPATCH.GET_OPATCH_XSLT)
--------------------------------------------------------------------------------

Oracle Querayable Patch Interface 1.0
-----------------------------------------


SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         3 PDB3                           READ WRITE NO

[Java] Further Updates to 'Moving to a Plugin-Free Web'

原文はこちら。
https://blogs.oracle.com/java-platform-group/entry/further_updates_to_moving_to

Java Appletを立ち上げるために必要とする、標準ベースのNPAPIプラグインをサポートするテクノロジーを、ブラウザベンダーがサポートしない方向のため、およそ1年前、JDK 9でJava Browser Plug-inを非推奨(deprecated)にする計画を発表するエントリを記載しました。
Moving to a Plugin-Free Web
https://blogs.oracle.com/java-platform-group/entry/moving_to_a_plugin_free
[Java] Moving to a Plugin-Free Web
https://orablogs-jp.blogspot.jp/2016/01/moving-to-plugin-free-web.html
これ以後、Oracleの開発チームは、JDK 9での非推奨化の流れ(案)に関する技術的な詳細を付けて、JDK Enhancement Proposal (JEP 289: Deprecate the Applet API) を発行しました。
JEP 289: Deprecate the Applet API
http://openjdk.java.net/jeps/289
さらに、Apple SafariとMozilla Firefoxの開発者から、ブラウザからの標準ベースのプラグインのサポート廃止(Javaおよびその他のプラグインベーステクノロジーの埋め込みができなくなる)に関するタイムラインのアップデートが発表されました。
Updates to “Moving to a Plugin-Free Web”
https://blogs.oracle.com/java-platform-group/entry/updates_to_moving_to_a
[Java] Updates to “Moving to a Plugin-Free Web”
https://orablogs-jp.blogspot.jp/2016/08/updates-to-moving-to-plugin-free-web.html
彼らが発表したタイムラインによれば、Mozilla Firefox 52(2017年3月リリース)で、32ビット版Mozilla Firefoxは標準ベースのプラグインサポートに必要なAPIを提供しなくなります。
RapidRelease/Calendar MozillaWiki
https://wiki.mozilla.org/RapidRelease/Calendar
Windows 64ビット版のMozilla Firefoxは、Javaを含むほとんどのNPAPIベースのプラグインをサポートしません。
Firefox 64-bit for Windows Available
https://blog.mozilla.org/futurereleases/2015/12/15/firefox-64-bit-for-windows-available/
Mozillaは、大規模に展開するために拡張サポートが必要な組織向けに、拡張サポートリリース(ESR)バージョンのFirefoxを提供しています。
Mozilla Firefox ESR Overview
https://www.mozilla.org/en-US/firefox/organizations/faq/
32ビット版Mozilla Firefox 52 ESRのみ、引き続き、Java Appletを起動するために必要な、標準ベースのプラグインをサポートするテクノロジーに対するサポートを提供する予定ですが、Firefoxの一般バージョンとESRをサーバーサイドで区別する方法がないことにご注意ください。開発者がサーバーサイドでチェックする実装を入れるのではなく、影響を受けるユーザーが、ESRリリースを使用しているかどうか(「ヘルプメニュー - >バージョン情報」からFirefox 52でESRの文字を探す)を調べる方法を必要とするかもしれません。

Mozillaはおよそ1年間はFirefox ESR Releaseをメンテナンスします。開発者および32ビット版Mozilla FirefoxでJavaプラグインテクノロジーを使っているユーザーの方々は、異なるソリューションへの移行を検討する必要があります。

様々な移行方法に関する背景や情報の詳細は、以下のURLの短編ホワイトペーパーにまとめられていますので、ご一読ください。
Migrating from Java Applets to plugin-free Java technologies
http://www.oracle.com/technetwork/java/javase/migratingfromapplets-2872444.pdf

[Database] Dealing with very very long string lists using Database 12.2

原文はこちら。
https://blogs.oracle.com/datawarehousing/entry/dealing_with_very_very_long

Oracle Database 11gR2で、文字列値を取り扱うLISTAGG関数が導入されました。これは、行のグループから値を集計し、値が通常コンマまたはセミコロンで区切られた連結文字列を戻すために利用できます。また、独自の区切り記号を指定すれば、コード内でこれを判別できます。

さまざまなフォーラムやブログの投稿から、開発者に広く使用されているようです。しかし、多くの人が強調してきた重要な問題が1つあります。非常に大きな文字列を含むデータセットに対してLISTAGGを使用すると、長すぎるリストを作成する可能性があります。これにより、次のようなオーバーフローエラーが発生します。
ORA-01489: result of string concatenation is too long
ORA-01489: 文字列を連結した結果、長さが最大長を超えました
開発者やDBAにとってさらに面倒なことに、指定されたLISTAGG measure_expr内の値を連結するとORA-01489エラーが発生するかどうかを事前に判断することは非常に難しいため、(筆者自身を含め)多くの人がこの問題を解決するための回避策を提示しています。おそらく最も洗練されたシンプルなソリューションは、12cのMATCH_RECOGNIZE機能を使用することですが、これは12c Release 1を必要とするため、すべてのDBAや開発者が常に利用できるわけではありません。
問題を再現したい場合、そしてサンプルのSHスキーマにアクセスできる場合は、次のクエリを実行してみてください。
SELECT 
g.country_region, 
LISTAGG(c.cust_first_name||' '||c.cust_last_name, ',') WITHIN GROUP (ORDER BY c.country_id) AS Customer
FROM customers c, countries g
WHERE g.country_id = c.country_id
GROUP BY country_region
ORDER BY country_region;
この記事のすべてのサンプルは、サンプルのSHスキーマを使用しています。オンプレミス版のOracle Database 12c Release 2がリリースされると、OTNのデータベース・ホーム・ページから、ご使用のプラットフォーム用のサンプル・ファイルをダウンロードできるようになるはずです。筆者はLiveSQL上ですぐに使えるチュートリアルがあるのですが、現在非常に長い文字列を使用する上で技術的な問題が発生しています(LISTAGGワークショップを実行すると 'Data out of range' エラーが発生する)。問題を解決次第、このブログの記事を更新し、このチュートリアルへのリンクを追加します。
Oracle Live SQL
https://livesql.oracle.com/apex/livesql/file/index.html

What have we changed in 12.2?

ORA-01489エラーを解決する方法の一つは、単純にVARCHAR2オブジェクトのサイズを増やすことです。

Larger object sizes

VARCHAR2 オブジェクトの最大サイズはDatabaseのパラメータMAX_STRING_SIZEで決まります。以下のコマンドを使って環境の設定を確認できます。
show parameter MAX_STRING_SIZE
筆者のデモ環境では、以下のような結果が返ってきます。
NAME            TYPE   VALUE 
--------------- ------ -------- 
max_string_size string STANDARD
Oracle RDBMS 12.1.0.2以前では、 VARCHAR2 のサイズの上限は4Kでしたが、Oracle RDBMS 12.1.0.2でこの制限が拡大され、32Kになりました。この拡大によって、多くの問題が解決する可能性がありますが、DatabaseのパラメータMAX_STRING_SIZEを変更する必要があります。MAX_STRING_SIZE = EXTENDEDを指定すると、新たに32767 バイトを上限に設定変更できます。
ALTER SYSTEM SET max_string_size=extended SCOPE= SPFILE;
しかし、ビッグデータ・ソースへの関心が高まるにつれ、大規模なデータ・セットに対する問合せでLISTAGG機能を使用した場合に、エラーORA-01489の可能性が依然高いことは明らかです。必要なのは、LISTAGG関数内の構文がもっと豊富に提供されることですが、これは、Database 12c Release 2の一部として実装されています。

Better list management

12cR2では、文字列サイズの大きさゆえにエラーが発生しそうなリストの管理がより簡単になりました。利用可能な新しいキーワードをご紹介しましょう。
  • ON OVERFLOW ERROR
  • ON OVERFLOW TRUNCATE
  • WITH COUNT vs. WITHOUT COUNT
これらの機能のそれぞれをもうちょっと深掘りしてみましょう。

1. Keeping Pre-12.2 functionality
文字列長が長すぎた場合に既存コードで引き続きエラーを返したい場合、すばらしいことに、これがデフォルトの挙動です。 LISTAGG 文字列の長さが VARCHAR2 の制限を超えた場合、標準的なエラーが返ります。
ERROR at line xxx:
ORA-01489: result of string concatenation is too long
ORA-01489: 文字列を連結した結果、長さが最大長を超えました
しかしながら、可能であれば、オーバーフロー発生時にエラーが発生することを完全に明確にするため、LISTAGGコードに "ON OVERFLOW ERROR"を追加することをお勧めします。
SELECT 
g.country_region,
LISTAGG(c.cust_first_name||’ ‘||c.cust_last_name, ‘,' ON OVERFLOW ERROR) WITHIN GROUP (ORDER BY c.country_id) AS Customer
FROM customers c, countries g
WHERE g.country_id = c.country_id
GROUP BY country_region
ORDER BY country_region;
デフォルトでは、truncation(切り詰め)機能は無効化されており、エラーの発生を抑止したい場合には既存コードを変更する必要があることに注意することが重要です。

2. New ON OVERFLOW TRUNCATE… keywords
4Kもしくは32Kの境界で値のリストを切り詰めたい場合には、新規追加されたキーワードON OVERFLOW TRUNCATEを使う必要があります。以下はその例です。
SELECT 
g.country_region,
LISTAGG(c.cust_first_name||’ ‘||c.cust_last_name, ‘,' ON OVERFLOW TRUNCATE) WITHIN GROUP (ORDER BY c.country_id) AS Customer
FROM customers c, countries g
WHERE g.country_id = c.country_id
GROUP BY country_region
ORDER BY country_region;
切り詰めが発生すると、完全な値が切り詰められ、その時点でリストが切り捨てられたことをユーザーに示す方法を制御できます。 デフォルトでは、切り詰めが発生したことを示すインジケータとして3つのドット '...'を文字列に追加しますが、これを次のようにオーバーライドすることができます。
SELECT 
g.country_region,
LISTAGG(c.cust_first_name||' '||c.cust_last_name, ',' ON OVERFLOW TRUNCATE ‘***') WITHIN GROUP (ORDER BY c.country_id) AS Customer
FROM customers c, countries g
WHERE g.country_id = c.country_id
GROUP BY country_region
ORDER BY country_region;
文字列長が超過した際、12.2以前の既存の挙動のままエラーを返したい場合は、デフォルトの挙動に従うか、もしくはキーワードを使って明示的にエラーを返すことを宣言することができます(個人的には、デフォルトの挙動に依存しないほうがよいと考えています)。
SELECT 
g.country_region,
LISTAGG(c.cust_first_name||' '||c.cust_last_name, ',' ON OVERFLOW ERROR) WITHIN GROUP (ORDER BY c.country_id) AS Customer
FROM customers c, countries g
WHERE g.country_id = c.country_id
GROUP BY country_region
ORDER BY country_region;
この場合、通常のエラーメッセージを生成します。つまり、12.2以前の挙動のままです。
ORA-01489: result of string concatenation is too long
01489. 00000 - "result of string concatenation is too long"
*Cause: String concatenation result is more than the maximum size.
*Action: Make sure that the result is less than the maximum size.
もちろん、新しいキーワードを省略しても同じ挙動になります。
SELECT 
g.country_region,
LISTAGG(c.cust_first_name||’ ‘||c.cust_last_name, ‘,') WITHIN GROUP (ORDER BY c.country_id) AS Customer
FROM customers c, countries g
WHERE g.country_id = c.country_id
GROUP BY country_region
ORDER BY country_region;
以前と同様、この場合も通常のエラーメッセージを生成するので、12.2以前の挙動と同じです。
ORA-01489: result of string concatenation is too long
01489. 00000 - "result of string concatenation is too long"
*Cause: String concatenation result is more than the maximum size.
*Action: Make sure that the result is less than the maximum size.

3. How many values are missing?
利用可能な領域に収まるようにリストから削除された値の個数を知る必要がある場合は、キーワード 'WITH COUNT' を使用できます。切り捨てられた文字列の最後に削除された値の個数が不要の場合、キーワード 'WITHOUT COUNT'を使用することができます。デフォルトの挙動は'WITHOUT COUNT'です。
SELECT 
g.country_region,
LISTAGG(c.cust_first_name||' '||c.cust_last_name, ',' ON OVERFLOW TRUNCATE'***' WITH COUNT) WITHIN GROUP (ORDER BY c.country_id) AS Customer
FROM customers c, countries g
WHERE g.country_id = c.country_id
GROUP BY country_region
ORDER BY country_region;
4. Do we split values when truncation occurs? (切り詰めが発生した場合に値は分割されるのか?)
いいえ、切り捨てを強制する場所を決定する際には、各値の全長を考慮に入れます。したがって、各国内の顧客名リスト作成時にLISTAGGを使用する場合、顧客のフルネームであるKeith Laker(ファーストネーム + ラストネーム)が常に含まれます。 完全な文字列(ファーストネーム + ラストネーム)をリストに追加するのに十分なスペースがなければ、文字列全体、 "Keith Laker"が削除され、切り捨てインジケータが挿入されます。 ラストネームが切り捨てもしくは削除された場合、ファーストネームだけが文字列の最後の値として存在することはありません。

5. How do we calculate the overall length of the string values?(文字列の全長の計算方法は?)
オーバーフローが発生したことを示す文字は値リストの後ろに追加されます。デフォルトの場合、その文字は3個のドット'...'です。オーバーフロー機能は、最大長からLISTAGG句の最後の完全な値の最後まで逆方向に移動した後、ユーザ定義の区切り文字(最終デリミタ)、ユーザ定義のオーバーフローインジケータ(切り捨てインジケータ)を追加した上で、 'WITH COUNT'による、リストから削除または切り捨てられた値の個数を示す出力を追加します。

Summary

Oracle Database 12c Release 2では、ORA-01489エラーに対し次の2つの方法で対処しました。
  1. VARCHAR2オブジェクトのサイズを32Kに増やした
  2. LISTAGGの拡張機能を使用して非常に長いリストの管理をより詳細に制御できるようにした
そして、新しいキーワードが追加されています。
  • ON OVERFLOW TRUNCATE
  • ON OVERFLOW ERROR (デフォルトの挙動)
  • WITH COUNT(デフォルトの挙動)
  • WITHOUT COUNT

うまくいけば、この新しい機能によって、長年にわたって作成された
ORA-01489: result of string concatenation is too long
ORA-01489: 文字列を連結した結果、長さが最大長を超えました
というエラーを解決するためのすばらしい回避策は、標準のSQL機能で置き換えられることでしょう。

[Java] Java EE 8 - January recap

原文はこちら。
https://blogs.oracle.com/theaquarium/entry/java_ee_8_january_recap

1月はJava EE 8にとって慌ただしい月でした。直近で起こったアクティビティを簡単にまとめてみます。

JSF 2.3、JSON-P 1.1、CDI 2.0がPublic Draft状態になっています。それぞれのPublic Draft期間が終了するまでにこれら3個の仕様をチェックし、フィードバックすることが重要です。
JSRPublic Previewの期間
JSR 372: JavaServer Faces (JSF 2.3) Specification
https://jcp.org/en/jsr/detail?id=372
2017/1/23 - 2017/2/21
JSR 374: JavaTM API for JSON Processing 1.1
https://jcp.org/en/jsr/detail?id=374
2017/1/17 - 2017/2/16
JSR 365: Contexts and Dependency Injection for JavaTM 2.0
https://jcp.org/en/jsr/detail?id=365
2017/1/31 - 2017/3/2

JAX-RSについて言うと、3個のJAX-RS 2.1の高価な機能のうち2個、すなわちReactive Client APIとServer-sent Eventsのサポートに関する完全な提案ができたことで、かなりの進捗がありました。
JAX-RS 2.1 Reactive Client API
https://blogs.oracle.com/PavelBucek/entry/jax_rs_2_1_reactive
https://orablogs-jp.blogspot.jp/2017/01/jax-rs-21-reactive-client-api.html
[jax-rs-spec users] Server-Sent Events API proposal
https://java.net/projects/jax-rs-spec/lists/users/archive/2017-01/message/142 
Non Blocking I/Oプロバイダは3番目の高価な機能で、引き続きJAX-RS Expert Groupで議論されているはずです。
JAX-RS Expert Group Mailing List Archive
https://java.net/projects/jax-rs-spec/lists/users/archive
JSR 380のSpec LeadであるGunnar Morlingは、Bean Validation 2.0の進捗について、間もなくEarly Draft Reviewを予定しているとのことです。この間、Draftの進捗状況を常に確認することができます。
JSR 380: Bean Validation 2.0
https://jcp.org/en/jsr/detail?id=380
Bean Validation 2.0 Progress Report
http://beanvalidation.org/news/2017/01/19/bean-validation-2-0-progress-report/
Bean Validation 2.0 specification - WORK IN PROGRESS
http://beanvalidation.org/latest-draft/spec/
Servlet 4 Expert Groupでも作業が進んでいます。HTTP/2 (例:Server Push)の技術的実装の詳細のいくつかが現在議論されているということです。
Servlet Specification : Users Mailing List
https://java.net/projects/servlet-spec/lists/users/archive
さらに、Security JSR (JSR-375) についての議論が今後数多く見られると思われます。
Java EE Security API Specification : Expert Group Mailing List
https://java.net/projects/javaee-security-spec/lists/jsr375-experts/archive/2017-01/
最後に、MVCの仕様策定をコミュニティ主導に移転する件に対する投票が終了し、承認されました。つまり、ペーパーワークを進めることができるようになったということです。そして、Ivar Grimstadはまもなく正式に新しいMVC仕様のリードになるはずです。
JSR #371 Model-View-Controller (MVC 1.0) Specification Transfer Ballot
https://jcp.org/en/jsr/results?id=5907
JSR 371: Model-View-Controller (MVC 1.0) Specification
https://jcp.org/en/jsr/detail?id=371 
具体的には、4個のJava EE 8仕様がPublic Draft(JSON-B 1.0、JSON-P 1.0、JSF 2.3、CDI 2.0)の状態にあります。それゆえ、仕様に関与し、テストし、これらの仕様に対するフィードバックを出すのにいいタイミングです。コントリビュートの出発点として、先日JCPが実施したAdopt A JSRのWebcastをご覧になるのをお奨めします。
Adopt-a-JSR for Java EE
http://linkis.com/www.youtube.com/2mnrm 
まだまだ早期の段階ではありますが、Java EE 8参照実装(Reference Implementation)、つまりGlassFish 5に関わるアクティビティの復活を確認できます。
glassfish - Java.net JIRA
https://java.net/jira/browse/GLASSFISH/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel
その点で、Java.net終了のことを、明確かつ十分に意識しています。Java.netの終了によって、Java EE、つまりJava EEに関連するJSRやGlassFishを含むさまざまなRIに影響を与えないように努めており、できるだけ早くより具体的な詳細を共有する予定です。