[Java] Background on Oracle’s contribution to Jakarta EE

原文はこちら。
https://blogs.oracle.com/theaquarium/background-on-oracle%E2%80%99s-contribution-to-jakarta-ee

このエントリはWill Lyons(Senior Director, Java EE and WebLogic Server Product Management)によるものです。
Jakarta EE logo
本日Eclipse Foundationは、Jakarta EEというブランドの下、Java EE 8テクノロジーがクラウドネイティブJavaの要件を満たすために進化するという、数々のコミュニティアップデートを行っています。新しいJakarta EEウェブサイトとJakarta EEコミュニティ調査の結果をご覧ください。
Jakarta EE Community Survey of 1,800+ Java Developers Reveals “Cloud Native” Top Requirement in Platform’s Evolution
https://jakarta.ee/news/2018/04/24/jakarta-ee-community-survey/
Jakarta EE Software
https://jakarta.ee/
本日アップデートが発表されたので、これまでのこのプロジェクトへのOracleの貢献に関するアップデートを提供してもよいだろう、と考えました。以前のエントリで説明したように、OracleはJava EE 8テクノロジーをこのプロジェクトに寄贈しています。具体的には以下のようなものです。
  • Java EE 8のリファレンス実装(RI)であるOracle GlassFish 5.0のソースコード
  • Java EE 8互換性のテストに使用されるOracle Technology Compatibility Kit(TCK)のソース
  • 製品マニュアル
これまでのOracleの取り組みでは、Eclipse FoundationのEE4JプロジェクトへのOracle GlassFish 5.0およびTCKソースの貢献に注力していました。これは最終的に "Eclipse GlassFish"の構築とテストに使用されます。 Oracleは継続的にGitHubのOracle GlassFishソース・リポジトリの提供準備ができているかどうかをレビューしており、これらのレビューが完了すると、OracleはOracle GlassFish 5.0コンポーネントに対応するEE4Jのサブプロジェクトを提案します。これらのサブプロジェクトとリポジトリは、プロジェクト管理委員会(PMC)とコミュニティレビューの後に作成されます。Oracleは、新しいライセンスでEclipse Foundationにソースを提出し、そこでレビューされ、最終的にGitHubのEE4Jサブプロジェクト・リポジトリに公開されます。

このプロジェクトは、オープンなEclipseコミュニティ・プロセスによって管理および実行されています。この作業の進行状況は、EE4J Project Bootstrappingステータスページで追跡できます。このページでは、計画済みEE4Jサブプロジェクト、サブプロジェクトの作成、そしてソースコードの提出のステータスをレポートします。このステータスには、Ivar GrimstadとChristian KaltepothがSpec Leadである、MVC 1.0の参照実装のOzarkのステータスと、Oracleの貢献状況が含まれます。

纏めると、現時点ではこのプロセスの一環として…
  • 34個のEE4Jサブプロジェクトがレビュー待ち。これらのサブプロジェクトは、GlassFishプロジェクト自体、主要なGlassFishコンポーネントのほとんど、TCK寄贈のためのプロジェクトを含む、GlassFish参照実装(Reference Implementation、RI)の大部分を表す。
  • 20個のEE4Jサブプロジェクトが作られ、Oracleからの寄贈を受け取る準備は完了している。
  • Eclipse Foundationに対してこうしたEE4Jサブプロジェクトに対する15個のソースの提供があった。この中には、Jersey (JAX-RS)、Mojarra (JSF)、Tyrus (WebSocket)、Open MQ (JMS)、EclipseLink (JPA)、JSON-P、JTAといった、主要なOracle Java EE 8テクノロジーが含まれる。
  • 13個のサブプロジェクトのソース・リポジトリにソースコードが投入された
Oracleのソースを提供するこのプロセスは継続します。変更の可能性はありますが、目標は、7月までにすべてのOracle GlassFish 5.0ソースを提供し、Oracle GlassFish 5.0と互換性のあるEclipse GlassFish実装をEE4Jソースから構築し、Java EE 8 TCKバイナリを使ってJava EE 8互換性を検証できるようにします。さらに、Eclipse Foundationに提供したJava EE 8 TCKのソースをJakarta EE TCKプロジェクトに提供することで、これらのテストを進化させて、Jakarta EEコミュニティが決定したようにJakarta EE互換性テストが提供できることを願っています。

要するに、我々が昨年9月に提案した貢献を現実にするまさにそのさなかです。Eclipse Foundation、Jakarta EE Working Group、EE4J PMC、およびJakarta EEコミュニティの皆様に感謝し、Jakarta EEブランドの下でクラウドネイティブJavaのためにこれらのテクノロジーを進化させていきたいと考えています。

[Java] The road to Jakarta EE

原文はこちら。
https://blogs.oracle.com/theaquarium/the-road-to-jakarta-ee

Jakarta EE logo

本日、Eclipse Foundationは、https://jakarta.eeとJakarta EEのロゴの公開、開発者アンケートの結果などを含む、Jakarta EEに関連する複数の発表を行っています。
Eclipse Foundation Unveils New Cloud Native Java Future with Jakarta EE
https://jakarta.ee/news/2018/04/24/eclipse-foundation-unveils-new-cloud-native-java-future-with-jakarta-ee/
Jakarta EE Community Survey of 1,800+ Java Developers Reveals “Cloud Native” Top Requirement in Platform’s Evolution
https://jakarta.ee/news/2018/04/24/jakarta-ee-community-survey/
Jakarta EE Software
https://jakarta.ee/
ここまでの道のりを紹介するいいタイミングかもしれません。
2016年終わりごろから2017年初頭、Java EEについて説明していたときに以下のようなスライドを冗談で使っていました。

その当時、誰も将来を予測していなかったと思います。その期間中、Java EEプラットフォームの将来について疑問が提起されましたが、Java EEにとって状況は簡単では簡単ではなかったことを思い出す必要があります。当時、OracleはJCP expertsと共にJava EE 8およびAPIの最終化に注力していました。

そのプロセスの比較的早い段階で、私たちはJava EEプラットフォームの将来についても考え始めました。つまり、Java EE 8以後の時代を「Java EE Next」と非公式に呼んでいました。JavaOne 2016で共有されていたJava EE 9の計画は、特に歓迎されなかったため、白紙に戻してやり直しました。Java EEエコシステムが再びわくわくするものかつ多数の方が関与するものたり得るには、根本的に異なる何かをしなければならないことは明らかでした。

長年にわたって提起されたJava EEに対するすべての懸念を取り除くために、我々はその時点から、よりオープンな方法で、より速いペースでプラットフォームを進化させるべきだと考えました。プラットフォームは、十分に確立されたガバナンスを含め、オープンソースモデルを採用しなければならないことは明らかでした。その初期の反省から、Oracleはエコシステムの主要プレーヤー、つまりRed HatとIBMと一緒に、Eclipse Foundationこそがこのラディカルな進化をホストするのにふさわしいと決定しました。多くの理由の1つは、EclipseがすでにMicroProfile.ioプロジェクトをホストしているという点です。MicroProfileでは、Java EEプラットフォームにマイクロサービス・アーキテクチャ向けの機能を追加しています。その後まもなく、Tomitribe、Payara、FujitsuなどのJava EEプレイヤーがイニシアティブに参加しました。こうしてEE4JJakarta EEが誕生しました。

プラットフォーム開発のEclipse Foundationへの移行は大仕事です。私は発言に責任を持てないのでここでは取り扱いませんが、複雑な法的問題を含め、多くの技術的側面と非技術的側面があります。さらに、私たちは小さなプロジェクトについて話しているわけではありません。例を挙げると、GlassFish、Jersey、Grizzly、Mojarra、Open MQを含む多数の確立されたプロジェクトについて話しています。しかもそれで終わりではありません。また、さまざまなTCKのオープン化に関連するあらゆる活動もあります。ただただ巨大な作業であり、おそらくEclipse Foundationがこれまでに進めてきたプロジェクトで最大のものでしょう(背景は以下をご覧ください)。
Background on Oracle’s contribution to Jakarta EE
https://blogs.oracle.com/theaquarium/background-on-oracle%E2%80%99s-contribution-to-jakarta-ee
https://orablogs-jp.blogspot.jp/2018/04/background-on-oracles-contribution-to.html
これこそが、Jakarta EEがベースラインとしてJava EE 8を使用し、旧バージョンのプラットフォームがJakarta EEに含めないことを早期に決定した理由の一つで、このアプローチは端的に合理的かつ実用的でした。こうしている間にも、これらすべての成果が生まれています。Jakarta EEの重要な目標、つまりプラットフォームを進化させることに効果的に注力できるようにするために、そうした取り組みを背後におきながら、すべてが出そろうのを待つ必要があります。それに関連し、著名なコミュニティメンバーから以下のようなメールを最近受け取りました。

私たちはJakarta EEとは無関係の問題について話し合いました。その人からの謝意にを心からありがたく思いつつ、本当にJakarta EE全体の取り組みについて強調する必要があると考えています。コミュニティー内でVisibilityがある人もいます(PMCにおけるOracleの代表であるDmitry Kornilov(@m0mus)、エバンジェリストとしてのDavid Delabassee)が、Oracle側の立場で言えば、まさにチームの成果なのです。Java EEをEclipse Foundationに移管するために背後(Oracle)では多数の人々が関わっています。関わりの濃淡にかかわらず、この作業に非常に多くの同僚が関わっているため、全員を紹介できませんし、リストにしても誰かを忘れてしまう可能性があるのでそういうことはしたくないのですが、特に言及すべきと考えている、Ed Bratt、Will Lyons、そしてBill Shanonの業績を公言させてください。彼らはJakarta EEを確実に誕生させるための作業の初期段階から休むことなく作業してくれました。皆さん、ありがとう!

また、通常プロジェクトがオープンソース化される場合、すべての法的側面を含む関連するすべての活動が上流で行われること、そしてすべてが議論され、合意された場合のみ、プロジェクトが公開されることを認識しておく必要があります。しかし、早い段階で、できるだけ透明性の高いものにすることを決めていました。そのため、昨年の夏の最初の意図を発表したのです。当時、まだ多くのことが決定されていませんでしたが、それゆえに、Jakarta EEの初期段階で、新しいけれどもすでに活発な活動をしているオープンソースコミュニティの創設をも含めて、現在の状況に至りました。Jakarta EEの究極の目標、すなわち、プラットフォームを来る10年に必要なオープンソースおよびJavaベースのクラウドネイティブの基盤への進化に適切に取り組むためには、まだまだ多くの作業が必要です。Jakarta EEコミュニティはそのゴールに向けて活発に活動しており、本日の発表が重要な初期マイルストンを表しています。
Eclipse Foundation Unveils New Cloud Native Java Future with Jakarta EE
https://jakarta.ee/news/2018/04/24/eclipse-foundation-unveils-new-cloud-native-java-future-with-jakarta-ee/

[Java] Oracle Dev Tour Japan 2018

風薫る5月といえば、そうJavaの月ですね。そして、彼らが今年もやってきます。
そう、SteveとSebastianです。

今年も全国のJUGをお訪ねする、Oracle Dev Tour Japan 2018を開催します。
2018/04/24現在参加登録サイトがオープンしている会場を下表にまとめました。ご興味あればぜひお近くの会場にお越しください。

場所開催日時開催場所リンク
熊本5/8 (火) 18:50-20:50
開場:18:20
熊本県民交流館パレア
10階会議室6
https://kumamotojava.doorkeeper.jp/events/73213
福岡5/10 (木) 19:00-21:00
開場:18:30
日本オラクル株式会社 西日本支社
九州オフィス セミナールーム
https://javaq.connpass.com/event/85022/
岡山5/11 (金) 19:00-21:00
開場:18:30
岡山県立図書館
サークル活動室2 
https://okajug.doorkeeper.jp/events/73098
大阪5/14 (月) 19:00-21:00
開場:18:30
日本オラクル株式会社 西日本支社
大阪オフィス セミナールーム
https://kanjava.connpass.com/event/84996/
名古屋5/15 (火) 19:00-21:00
開場:18:30
日本オラクル株式会社 中日本支社
東海オフィス セミナールーム
https://ngo-java.connpass.com/event/85297/
仙台5/21 (月) 19:00-21:00
開場:18:30
日本オラクル株式会社 東北支社
セミナールーム 
https://connpass.com/event/86131/

そして、5月17日は、Java Day Tokyo 2018もお忘れなく。

[Linux] An Update on Retpoline-enabled Kernels for Oracle Linux

原文はこちら。
https://blogs.oracle.com/linuxkernel/an-update-on-retpoline-enabled-kernels-for-oracle-linux

1月に、研究者らは、MeltdownとSpectreと呼ばれる投機的実行の欠陥を明らかにしました。Oracleは以下のサポート・ノートで公式ガイダンスを公開しました。
Meltdown and Spectre
https://meltdownattack.com/
Responding to the Spectre and Meltdown vulnerabilities (CVE-2017-5715, CVE-2017-5753, and CVE-2017-5754) in Oracle Linux and Oracle VM on Oracle X86 Servers (Doc ID 2370398.1)
https://support.oracle.com/rs?type=doc&id=2370398.1
当時、特別なIntelのマイクロコードに依存したこれらのセキュリティ問題の軽減策をリリースしましたが、最新のカーネルリリースkernel-uek-4.1.12-112.16.4には、Spectre Variant 2(CVE-2017-5715)のより高速な、retpolineベースの軽減が含まれています。
[El-errata] ELBA-2018-4050 Oracle Linux 6 Unbreakable Enterprise kernel bug fix update
https://oss.oracle.com/pipermail/el-errata/2018-March/007581.html
このカーネルは、Oracle Linux 7とOracle Linux 6の両方で使用できます。UEK Release 2、UEK Release 3、そしてOracle Linux 6および7のRed Hat Compatible Kernel向けの既存のパッチとあわせ、Oracle LinuxのSpectre and Meltdownの脆弱性に対する最新のソフトウェア軽減策を提供します。
[El-errata] ELBA-2018-4050 Oracle Linux 6 Unbreakable Enterprise kernel bug fix update
https://oss.oracle.com/pipermail/el-errata/2018-March/007581.html
[El-errata] ELBA-2018-4050 Oracle Linux 7 Unbreakable Enterprise kernel bug fix update
https://oss.oracle.com/pipermail/el-errata/2018-March/007580.html
全てのソースコードはGitHubで公開済みです。
oracle/linux-uek - v4.1.12-112.16.4
https://github.com/oracle/linux-uek/releases/tag/v4.1.12-112.16.4
Development Versions of Oracle Linux UEK now available on GitHub
https://blogs.oracle.com/linuxkernel/development-versions-of-oracle-linux-uek-now-available-on-github
https://orablogs-jp.blogspot.com/2018/04/development-versions-of-oracle-linux.html
Oracleはまた、1月にIBRS/IBPB軽減策を使用してSpectre Variantの緩和策をXenに移植しました。Oracle VM 3.4でXenのretpoline軽減策をリリースしようとしています。これにより、サポートされているすべてのハイパーバイザー(Oracle VM 3.2、Oracle VM 3.3、Oracle VM 3.4、およびkvm)へのMeltdown/Specterタイプの攻撃から完全に保護されます。

Retpolinesの利点については、以下のIntelのホワイトペーパーとgoogle.comのサポート記事を参照してください。
Retpoline: A Branch Target Injection Mitigation
https://software.intel.com/sites/default/files/managed/1d/46/Retpoline-A-Branch-Target-Injection-Mitigation.pdf
Retpoline: a software construct for preventing branch-target-injection
https://support.google.com/faqs/answer/7625886
Retpolinesは、間接的な分岐を投機的な実行から隔離するコンパイラによって実行されるソフトウェアによる軽減策です。"return trampoline"から派生したretpolineを使う軽減策は、マイクロコードベースの軽減策よりも大幅にパフォーマンスのオーバーヘッドが少なく、とあるワークロードでは、パッチ適用前のレベルに近いパフォーマンスが得られる可能性があります。

Retpolinesは、Oracle Linux 7(およびOracle Linux 6)で使用可能なretpoline対応のgccコンパイラを使用して、カーネル(およびカーネルモジュール)を再コンパイルすることで有効になります。
[El-errata] ELBA-2018-0408 Oracle Linux 7 gcc bug fix update
https://oss.oracle.com/pipermail/el-errata/2018-March/007569.html
[El-errata] ELBA-2018-0513 Oracle Linux 6 gcc bug fix update
https://oss.oracle.com/pipermail/el-errata/2018-March/007583.html
Oracleのコンパイラエキスパートは、このサポートをgcc-4.8およびgcc-4.4コンパイラに移植しました。このコンパイラはyum.oracle.comで公開されています。これがOracle Linuxでretpoline対応のカーネルを使用できるようにするための前提条件でした。この結果、Oracle Linuxはコンパイラ機能を使用して、Spectre Variant 2攻撃に対してカーネルを自己保護することができます。アプリケーションの再コンパイルは必要ありません。

retpolineを使用する代わりに、IBRS(Indirect Branch Restricted Speculation)を使うこともできます。これはIntelの最新のマイクロコードのアップデートで定義された特別なSPEC_CTRL MSR(モデル固有のレジスタ)を呼び出します。IBRSはマイクロコードを使用してセキュリティ上の脆弱性を軽減します。 IBRSは、とあるワークロードではパフォーマンスが大幅に低下します。retpolineが利用可能である場合でも、もう一つの軽減策であるMSR、IBPB(Indirect Branch Predictor Barrier)も特定のユースケースでは以前として利用されています。

retpolinesを軽減策として利用する上での注意点がいくつかあります。まず、ハードウェアがretpolineをサポートしなければなりません。最新のハードウェアによっては、retpolineの軽減策を無視して命令を推測する場合があります。第2に、ロード可能なカーネルモジュールもretpoline対応のコンパイラでコンパイルする必要があります。そうしないと、カーネルは依然として脆弱なままです。

最新のkernel-uekは、これらの各条件を自動的に検出し、マイクロコードベースのIBRS軽減策を有効にします。フォールバックであるIBRS軽減策の場合、システムにアップデート済みのマイクロコードが存在している必要があります。したがって、ハードウェアベンダーから提供される利用可能な最新のシステムマイクロコードに更新することを常にお勧めします。アップデートされたIntelのマイクロコードには、SPEC_CTRL MSRが導入されていますが、それを呼び出すことはしません。カーネルはMSRを起動する必要があるからです。このカーネルの挙動はユーザーが有効または無効にできます。そのため、IBRSを無効にする予定のシステムに更新されたマイクロコードをロードしてもパフォーマンスに影響はありません。

ゲスト(仮想マシン)システムではマイクロコードを更新する必要はありません。ホストシステムに正しいマイクロコードを有しており、アップデートされたソフトウェア(Xenまたはqemu)があれば、ハイパーバイザーはゲストを保護するために必要なMSRをパススルーします。

サードパーティのカーネルモジュール
サードパーティ製のカーネルモジュールは、retpoline対応のコンパイラで再コンパイルする必要があります。UEKでは、以前にコンパイルされたモジュールがロードされることをkABI(Kernel Application Binary Interface)が保証していますが、これらのモジュールがretpolineに対応していない場合、カーネル全体がIBRS保護を再び有効にし、retpolinesのパフォーマンス上の利点は失われます。

Repolinesは必須ではない
Retpolineが有効になっているカーネルはパフォーマンスが向上しますが、retpolinesがなくてもセキュリティパッチが適用されたカーネル場合、すぐにこれらのパッチを適用することは重要ではありません。

マイクロコードのアップデートは必要
システムがIBRS(マイクロコードベース)の軽減策にフォールバックする必要のある、シナリオが多く存在します。この場合、システムのマイクロコードをアップデートしていない場合は失敗します。retpolinesを利用できる場合でも、マイクロコードをフォールバックとして利用できるようにすることは不可欠です。多数のエッジケース(kvm、強化GPG、Xen、ハードウェア制限など)では、retpolineの緩和策が十分でない場合があります。マイクロコードが期限切れの場合、 'dmesg'出力に表示されるこのメッセージは見たくないでしょう(retpolinesが利用できず、IBRSを利用可能なマイクロコードが利用できない場合のブート時のログです)。
[  358.742211] kmod1: loading module not compiled with retpoline compiler.
[  358.742214] Spectre V2 : Disabling Spectre v2 mitigation retpoline.
[  358.749417] Spectre V2 : Could not enable IBRS.
[  358.754569] Spectre V2 : No Spectre v2 mitigation to fall back to.
[  358.761587] Spectre V2 : system may be vulnerable to spectre
アプリケーションの再コンパイルは不要
カーネルでretpolineを使えるようにアプリケーションを再コンパイルする必要はありません。ロード可能なカーネルモジュールだけを再コンパイルする必要があります。

In summary:

  • UEK 2/3/4、Red Hat Compatible Kernelを使うOracle Linux 6および7はSpectre variant 1/2/3に対応している
  • 最新のUnbreakable Enterprise Kernel release 4には、Spectre variant 2に対応するretpolineベースの軽減策が含まれている
  • retpolineが有効化されたUEK4では、マイクロコードベースのSpectre軽減策を有する以前のリリースに比べてパフォーマンスが大幅に向上している
  • retpolineの軽減策を使うUEK4は特定のハードウェアでのみ動作し、全てのカーネルモジュールをretpoline対応のコンパイラで再コンパイルする必要がある。
  • retpolineの軽減策を使うUEK4は、retpolineのサポートに必要な状況でない場合にはマイクロコードベースの保護策に自動的にフォールバックする。
  • ここに記載した内容全てと詳細は、以下のMy Oracle Supportにドキュメントがある。
    Responding to the Spectre and Meltdown vulnerabilities (CVE-2017-5715, CVE-2017-5753, and CVE-2017-5754) in Oracle Linux and Oracle VM on Oracle X86 Servers (Doc ID 2370398.1)
    https://support.oracle.com/rs?type=doc&id=2370398.1

[misc.] JavaOne Event Expands with More Tracks, Languages and Communities – and New Name

原文はこちら。
https://blogs.oracle.com/developers/javaone-event-expands-with-more-tracks-languages-and-communities-and-new-name

JavaOneが拡大し、より多くの言語、テクノロジー、開発者コミュニティを含む、新たなより大きいイベントに生まれ変わります。開発者が期待しているJavaのテクニカルコンテンツだけでなく、Go、Rust、Python、JavaScript、Rについてのセッションにも期待してください。この新しいイベントOracle Code Oneは、10/22から10/25まで、San FranciscoのMoscone Westで開催します。

Oracle Code OneではJavaチームのアーキテクトによる、最新のJavaプラットフォームに関する情報をご紹介するテクニカルキーノートを開催予定です。この中で、Java 11に関する最新の詳細情報、OpenJDKの最新情報、およびその他のコアなJava開発についても説明します。現在、Jakarta EE(現在はEclipse Foundationの一部)、Spring、Javaマイクロサービスやコンテナの最新情報など、サーバーサイドのJava EEテクノロジーの専用トラックを計画しています。その他、クライアント開発、JVM言語、IDE、テストフレームワークなどの豊富なコミュニティによるコンテンツも計画しています。

拡張に伴い、chatbot、マイクロサービス、AI、ブロックチェーンなどの最先端のトピックにもご期待ください。また、弊社のOracle JET、Project Fn、OpenJFXなど、最新のオープンソース開発者テクノロジーに関するセッションも予定しています。

最後に、このカンファレンスを引き続き盛り上げる要素の1つに、若手開発者のためのOracle Code4Kidsワークショップ、各地のJUGリーダーによるIGNITEライトニングトーク、Developer Loungeでのテクノロジーデモやコミュニティプロジェクトの展示といった、幅広いコミュニティによる活動があります。Developer Community Keynoteでのグランドフィナーレでこの週のテクノロジー、コミュニティイベントを締める予定です。

本日、Oracle Code OneのCall for Paperの受付を開始しました。Java開発者、データベース開発者、フル・スタック開発者、DevOps実践者、およびコミュニティ・メンバーのための11トラックのコンテンツに応募できます。

JavaOneのこの拡張について、筆者と同じくわくわく感を感じていただき、Oracle Code One最初の年にご参加いただけることを願っています。

Call for Paperは以下から応募ください。
Oracle Code One 2018
https://www.oracle.com/code-one/index.html

[Linux] Announcing the release of Oracle Linux 7 Update 5

原文はこちら。
https://blogs.oracle.com/linux/announcing-the-release-of-oracle-linux-7-update-5

Oracleはx86_64アーキテクチャ向けのOracle Linux 7 Update 5の一般提供を発表します。個々のRPMパッケージはUnbreakable Linux Network (ULN) とOracle Linux Yumサーバで確認できます。
Unbreakable Linux Network (ULN)
https://linux.oracle.com/
Oracle Linux yum server
https://yum.oracle.com/
ISOインストールイメージはまもなくOracle Software Delivery Cloudからダウンロードできるようになる予定です。
Oracle Software Delivery Cloud
http://edelivery.oracle.com/new
Oracle Container Registry
https://container-registry.oracle.com/
Docker Hub
https://hub.docker.com/_/oraclelinux/
Oracle Linux 7 Update 5には、以下のカーネルパッケージが同梱されています。
  • x86-64アーキテクチャ用Unbreakable Enterprise Kernel (UEK) Release 4 (kernel-uek-4.1.12-112.16.4.el7uek)
  • x86-64アーキテクチャ用Red Hat Compatible Kernel (kernel-3.10.0-862.el7)

Application Compatibility

Oracle Linuxは、Red Hat Enterprise Linux(RHEL)とのユーザー空間の互換性を維持しています。これはオペレーティング・システムの基礎となるカーネル・バージョンとは独立しています。ユーザー空間内の既存のアプリケーションは、Oracle Linux 7 Update 5+UEK Release 4の組み合わせ上で、修正無しでそのまま実行できます。Red Hat Enterprise Linux 7またはOracle Linux 7ですでに動作保証済みのアプリケーションでは再度認証する必要はありません。

Notable security-related features in this release:

  • 最近のIntelプロセッサーのメモリー保護キーのサポート
    このアップデートには、最新のIntelプロセッサー上のメモリー保護キーハードウェア機能のサポートが含まれています。CPUは、各キーに対して2つの別個のビット(アクセス禁止と書き込み禁止)を含む新しいユーザーアクセス可能なレジスタ(PKRU)を通してこのサポートを提供します。
  • 起動プロセス中にネットワークに接続された暗号化されたデバイスのロックを解除する機能以前は、ネットワークに接続されたブロックデバイスは、ネットワークサービスを開始する前にこれらのデバイスを接続および復号化できなかったため、ブートプロセス中にロックを解除できませんでした。
  • mod_sslでのSSLv3の無効化
    SSL/TLS接続のセキュリティ改善のため、httpd mod_sslモジュールのデフォルト構成でSSLv3のサポートを無効にしています。この変更が特定の暗号化サイファースィートの利用が制限されます。
  • KASLR for KVMゲスト向けKASLRの追加 guests added.
    KVMゲスト用のカーネルアドレス空間レイアウトのランダム化(KASLR)機能が追加されました。
Oracle Linux 7.5では、Btrfsが引き続き完全にサポートされています。Btrfsのサポートは、Red Hat Compatible Kernelでは廃止予定になっています。
これらの機能やその他の新機能、変更点の詳細は、Oracle Linux Documentation LibraryのOracle Linux 7 Update 5リリースノートを参照してください。
Oracle Linux 7 Update 5 Release Notes
https://docs.oracle.com/cd/E52668_01/E93593/html/index.html
Operating Systems Documentation - Oracle Linux
https://docs.oracle.com/en/operating-systems/linux.html
Oracle Linuxは無料でダウンロード、利用、配布でき、すべてのアップデートと正誤表に無料で入手でき、お客様がサポート契約の必要なシステムを決定します。
Oracle Linux Support
https://www.oracle.com/linux/index.html#support
そのため、Oracle Linuxは開発、テスト、および運用システムに最適です。 お客様は、すべてのシステムを最新かつ安全に保ちつつ、個々のシステムに対してどのサポートカバレッジが最善かを判断します。
Oracle Linux Premierサポートをご利用のお客様は、Ceph Storage、Oracle Linuxソフトウェア・コレクション、Oracle OpenStack、Oracle Kspliceを使用したゼロ・ダウンタイム・カーネル・アップデートといった、追加のLinuxプログラムもサポートされます。
Oracle Linuxの詳細については、以下のURLをご覧ください。
Oracle Linux
https://www.oracle.com/linux/index.html
https://www.oracle.com/jp/linux/index.html

[Java] Announcing GraalVM: Run Programs Faster Anywhere

原文はこちら。
https://blogs.oracle.com/developers/announcing-graalvm

現在の仮想マシン(VM)は、特定の言語または非常に少数の言語に対してのみ、プログラムの高性能な実行を提供します。コンパイル、メモリ管理、ツールは、‘don’t repeat yourself’ (DRY) (重複を防ぐ)の原則に違反して、言語ごとに別々に管理されています。これは、VM実装者にとって大きな負担になるだけでなく、パフォーマンス特性、ツール、および設定が一貫しないために開発者にとっても大きな負担になります。さらに、異なる言語で書かれたプログラム間の通信には、高コストなシリアライズ、デシリアライズのロジックが必要です。最後に、高性能VMは、高いメモリフットプリントの重量プロセスで、埋め込みは困難です。
数年前、これらの欠点に対処するために、Oracle Labsは仮想マシンの新しいアーキテクチャを探索するための新しい研究プロジェクトを始めました。
Oracle Labs
https://labs.oracle.com
我々のビジョンは、すべてのプログラミング言語で高性能を提供する単一のVMを作成し、プログラム間の通信を容易にすることでした。このアーキテクチャは、メンテナンス性を向上させるために統一された、言語非依存のツールをサポートし、その組み込み可能性(embeddability)の結果、VMがスタック全体で利用できるようにすることを目指しています。
この目的に適うよう、このようなVMのビルドにあたって新しいアプローチを考案しました。長年にわたる研究開発の結果、我々は今、最初の本番環境で利用可能なリリースを発表する準備が整いました。
Practical partial evaluation for high-performance dynamic language runtimes
https://dl.acm.org/citation.cfm?id=3062381

Introducing GraalVM

本日、polyglot(多言語)な世界向けに設計された汎用仮想マシンGraalVM 1.0のリリースを発表しました。
GraalVM
http://www.graalvm.org/
GraalVMは、個々の言語に対し高いパフォーマンスを提供し、さらに多言語アプリケーションでパフォーマンスのオーバーヘッドをゼロにする相互運用性を提供します。GraalVMの場合、言語境界でデータ構造を変換するのではなく、オブジェクトと配列を別のプログラミング言語で直接使用できます。

シナリオとして、例えばNode.jsコードからJavaライブラリの機能にアクセスしたり、JavaからPython統計ルーチンを呼び出したり、Rを使用して別の言語で管理されるデータから複雑なSVGプロットを作成したりすることが考えられます。GraalVMを使用すると、開発者は現在のタスクを解決するのに最も生産的な言語を自由に使用できます。

GraalVM 1.0では以下の言語を実行できます。
  • JVMベースの言語(Java、Scala、Groovy、Kotlinなど)
  • JavaScript (Node.jsを含む)
  • (CやC++、Rustで記述されたプログラムから生成された)LLVM bitcode
  • Ruby、R、Pythonの実験的バージョン
GraalVMは、スタンドアロンでも、OpenJDKやNode.jsのようなプラットフォームの一部としても、あるいはMySQLやOracle RDBMSなどのデータベースに埋め込まれていても実行できます。
Oracle Database Multilingual Engine (MLE)
https://oracle.github.io/oracle-db-mle/
アプリケーションは、標準化されたGraalVM実行環境を介してスタック全体に柔軟にデプロイできます。データ処理エンジンの場合、GraalVMは、実行中のプログラムにカスタム形式で保存されたデータを直接公開します。その際の変換オーバーヘッドはありません。
JVMベースの言語の場合、GraalVMは速やかに立ち上がり、メモリフットプリントの低い、プリコンパイルされたネイティブイメージを作成するメカニズムを提供します。イメージ生成プロセスは、メインのJavaメソッドから到達可能なコードを見つけるための静的解析を実行し、完全なAOT(Ahead-of-time)コンパイルを実行します。生成されたネイティブバイナリには、即時実行のためのマシンコード形式のプログラム全体が含まれています。 このネイティブバイナリを他のネイティブプログラムとリンクしたり、GraalVMコンパイラを包含して、GraalVMベースの言語をハイパフォーマンスで実行できるよう、JIT(Just-In-Time)コンパイルをサポートすることもできます。

GraalVMエコシステムの主な利点は、すべてのGraalVMデプロイメントに適用される言語に依存しないツールです。GraalVMのコア・インストールでは、言語に依存しないデバッガ、プロファイラ、およびヒープビューアを提供します。
GraalVM Debugging and Monitoring Tools
http://graalvm.org/docs/reference-manual/tools/
3rdパーティツールの開発者や言語開発者に対し、計測ツールAPIや言語実装APIを使用してGraalVMエコシステムを充実してもらうよう呼びかけています。GraalVMは言語レベルの仮想化レイヤーとして、すべての言語でツールと埋め込みを利用できるようにすることを目指しています。

GraalVM in Production

Twitterは、Scalaベースのマイクロサービスを実行するためGraalVMを本番環境に導入している企業の1つです。GraalVMコンパイラの積極的な最適化により、オブジェクトの割り当てが削減され、全体の実行速度が向上しています。この結果、ガベージコレクションに伴う休止が少なくなり、プラットフォームの実行に必要な計算能力が少なくて済みます。以下のプレゼンテーションでは、TwitterのJVMエンジニアが自身の詳細な体験とGraalVMコンパイラを使ってどのようにコストを低減しているかを説明しています。


現在のリリース1.0では、本番利用の場合、JVMベースの言語と(Node.jsを含む)JavaScriptを推奨しています。R、Ruby、Python、LLVMベースの言語はまだ実験的な段階です。

Getting Started

GitHub上のGraalVMオープンソースリポジトリから構築したGraalVM v1.0(リリース候補)Community Edition(CE)のバイナリは以下のURLからご利用いただけます。
GraalVM Community Edition 1.0 RC1
https://github.com/oracle/graal/releases
このリリース候補版に対し、コミュニティからのフィードバックを求めています。GitHubのIssueやGitHubのプルリクエストの形でフィードバックを承っています。
Issues
https://github.com/oracle/graal/issues
Pull Requests
https://github.com/oracle/graal/pulls
GraalVM CEに加え、本番環境でのセキュリティ、スケーラビリティ、パフォーマンス向上を目的として、GraalVM v1.0(リリース候補)Enterprise Edition(EE)を提供します。GraalVM EEはOracle Cloud Infrastructureで利用可能で、評価のためにOracle Technology Networkからダウンロードできます。 GraalVM EEの本番利用に関しては、graalvm-enterprise_grp_ww@oracle.comまでご連絡ください。

Stay Connected

最新のインストーラとドキュメントは以下のURLにあります。
GraalVM
http://www.graalvm.org/
GitHubリポジトリで、開発状況、リクエスト・エンハンスメント、または問題の報告をチェックしてください。
GraalVM: Run Programs Faster Anywhere
www.github.com/oracle/graal
以下のGraalVMメーリングリストに登録することをお勧めします。
  • graalvm-announce@oss.oracle.com
  • graalvm-users@oss.oracle.com
  • graalvm-dev@oss.oracle.com
Twitterのアカウント @graalvm でTweetします。ハッシュタグ #GraalVM でツイートやスタックオーバーフローに関する質問をチェックしています。

Future

この最初のリリースは始まりにすぎず、GraalVMのあらゆる側面の改善、特にPython、R、Rubyのサポートのために取り組んでいます。

GraalVMはオープンなエコシステムであり、独自の言語やツールを作成することをお勧めします。GraalVMは、標準化された言語実行と言語に依存しない豊富なツールを可能にする共同プロジェクトにしたいと考えています。詳細はwww.graalvm.orgを参照してください。
みなさまと一緒にPolyglotな世界のためのこの次世代テクノロジーを作っていくことを楽しみにしています。