2014年12月18日

[Java, JavaScript] Nashorn Architecture and Performance Improvements in the Upcoming JDK 8u40 Release

原文はこちら。
https://blogs.oracle.com/nashorn/entry/nashorn_performance_work_in_the

[訳注]
原文はMarcus Lagergren (動的言語のパフォーマンス・アーキテクト)からのメール形式になっていますが、訳文では少々編集しています。

ここしばらくブログ投稿をご無沙汰して申し訳ありませんでした。ちょうどコードフリーズしたOpenJDK 8u40について、そしてNashornにどのような機能拡張を施したのかをこのタイミングで説明するのがよいと考えました。

8u40ではNashornコードジェネレータを書き換え、Optimistic type systemが搭載されています。

JavaScript、もっとはっきり言うと、任意の動的言語は、パフォーマンスの高いコードを簡単に生成するためのコンパイル時の情報を提供しません。これが、8u40のために、Nashorn Type Systemを再設計し、より良い、高速なコードを生成するようにした理由です。Nashornコンパイラの出力である、Javaバイトコードは、意図的に強く型付けされていますが、JavaScriptはそうではありません。ここに動的言語のASTを最適なバイトコードへ変換する重大な問題があります。Attila Szegedi、Hannes Wallnöfer、と共に、昨年来、この問題を解決するために膨大な時間を研究や実装に費やしてきました。

背景
伝統的に、JavaでJavaScriptランタイムを実装する際、数字と言われるものをJavaでdoubleとして表現でき、それ以外のものは全てObjectとして表現できます。これには、数字、int型、long型や、その他の静的に証明可能ではないプリミティブ型が含まれています。言うまでもなく、このアプローチは、内部で多くのボクシングをもたらすため、JVM上での動的言語の実行速度の面でかなりのボトルネックになります。JVMは、Javaのようなバイトコードの最適化が得意ですが、これは、Javaのようなバイトコードではありません。
Type transitions in the optimistic type system
Nashornは実際に大規模な静的型解析を実施するため、生成されたコードは、上記の保守的なシナリオに比べてはるかに優れたものになる、というのが、もう一つの8u40の新しい点です。とはいえ、まだ全ての型で証明できているわけではないため、そこでOptimistic Type Systemが出てきます。今回のOptimistic Type Systemは、任意の静的に証明できない型がintという、全てのデータ型でもっとも制限の厳しいデータ型と仮定します。実行時にこの仮定が間違っていることが判明した場合には、例えばObject型やdouble型であることがわかったフィールドをメモリやスコープからロードします。また、オーバーフローする32ビットの加算を実施する場合には、実行中のコードをより保守的なバージョンで置き換えます。つまり実行中に再生成します。Nashornは実行時のコード置換を容易にするためのsimple continuationをサポートしています。これは将来、例えば、仮想的なインタプリタ層とコンパイル済みバイトコード間で行き来するといった、様々な用途に使われる可能性がある機能です。

また、将来のこうした変更に対する保護のため、リンク時にCallsiteに渡した引数によって、バイトコードがどのように見えるのかを詳細に調べ、推測しています。
Octane benchmark scores, normalized on JDK 8. 
これにより、(静的な場合には)生成されたバイトコードが実行速度において最適なJava型を含むようになっています。このコスト(全てにはコストがかかります)は、コード生成に時間を要する、というところに現れます。具体的には、わずかにウォームアップでマイナスの影響があります。ウォームアップはJDK9における主要なR&D分野であり、この件を解決でき、またワークロードを改善し、HotSpotによりうまくコンパイルさせて、もっと最適化されたサイクルにすることができる、と自信をもっています。

NashornをJVMの動的言語のための一般的なプラットフォーム/ランタイムとする取り組みで、Optimistic Type SystemはNashornに対しコード生成を指示しているどんなASTともうまく統合されています。将来のJavaのリリースのためにこれらの計画をもっと固め、最終的にNashornが「JVM上の動的言語のためのLLVM」のようなものになることを願っています。楽観的な型付けの問題がすべての動的言語に戻ってきます。このことを証明するために、当社の優れた論文学生であるAndreas Gabrielssonが、TypeScriptをNashornで実行するために必要なほとんど全てのものを実装することに成功しました。これを書いている時点で、唯一の大規模な機能のモジュールが不足しています。中間レベルのコンパイラ層でJavaScriptを生成せずに、NashornはTypeScriptからバイトコードに直接到達します。これは非常に素晴らしいことであり、Nashornが既に拡張性が高いことを示しています。類似の環境でRubyやGroovyが実行されていることについて考えてきました。Nashorn TypeScriptはまだオープンソース化されていませんが、まもなくそうなることを期待しています。

optimistic typeを使って8u40のNashornを実行するには、 以下の引数を使う必要があります。
--optimistic-types=true
まだウォームアップの問題に対する解決策を入れる時間がなかった(それはすべてのものに影響するわけではないですが、問題が残っていることで迷惑を掛ける可能性があります)ため、Optimistic Type SystemはまだNashornのデフォルト設定・動作とはなっていません。これは過度に保守的のように思われるかもしれませんが、不必要に皆さんのウォームアップを壊したくなかったためにそのようにしました。

以前のリリースに比べると、Octane benchmarks suiteのようなもので、数桁のオーダーでの性能向上をお知らせできます。また、Avatarプロジェクト向けのREST、HTTPベンチマークにおけるネイティブまたはネイティブに近いパフォーマンスを報告することができます。このことについてかなり好感を持っています。いくつかのケースでは、Nashorn上のJavaScriptアプリケーションは、SpiderMonkeyやV8のようなネイティブランタイム上で実行した同じアプリケーションと同じくらい速く動作します。言うまでもなく、自分たちの仕事をかなり誇りに思っています。

しかも・・・
JDK 8u40のNashornは生成されたコードと、推測された型情報を実行時にディスクへキャッシュします。
これは、長いウォームアップを伴う大きめアプリケーションにおける最初のイテレーションだけが問題になることを意味します。同じコードを連続実行する場合には非常に素早く安定し、等しく良好なパフォーマンスで実行されるでしょう。


是非お試し頂き、気付いたことをお知らせください。何かご質問があれば、ドキュメントを読み、メーリングリスト nashorn-dev [at] openjdk.java.net に参加してお知らせください。TwitterでNashornチームをフォローすることもできます。
  • Jim Laskey: @wickund 
  • Sundararajan Athijegannathan: @sundararajan_a
  • Marcus Lagergren: @lagergren
  • Attila Szegedi: @asz
  • Hannes Wallnöfer: @hannesw 

近い将来、より多くのエントリをUpすることになるはずですので、ご期待下さい。ブログ執筆活動を休止していることに対し、申し訳なく思っております。

追伸
多言語ランタイムとしてのJVMや、そうした多言語ランタイムを促進するフレームワークとしてのNashornに関する情報に関心がある場合には、以下のプレゼンテーションが知的好奇心を満たすかもしれませんのでご紹介しておきましょう。

2014年12月17日

[Java] USB Device Access for Java SE and OSGi

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

JavaOne 2014でのハンズオン「Java SE Embedded Internet of Things Hands-on-Lab」を作成するにあたっての課題の一つが、JavaとOSGiを使った、USB温度センサーとの通信でした。
Java SE Embedded Internet of Things Hands-on Lab [HOL2097]
https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=2097
残念ながら、USB通信APIは(2014年のハロウィン時期の段階で)Java SE標準には含まれておりません。そのため、この問題はどうすればJava/USB通信を確立できるのか、そしてさらに、どうやればOSGiフレームワークで動作するのか、ということに相当します。
今回は、この接続のベースとしてjavahidapiを選択しました。
JavaHIDAPI - Java API for working with Human Interface USB Devices (HID)
http://code.google.com/p/javahidapi/
HID API for Linux, Mac OS X, and WindowsのJava/JNIラッパーとしてのこのAPIの魅力は、このAPIを使うと、各プラットフォームの各デバイス用カスタムドライバが不要になる、という点にあります。
HID API for Linux, Mac OS X, and Windows
http://www.signal11.us/oss/hidapi/
OSGiフレームワーク内で操作するために(今回の場合、Apache Felix 4.4)、javahidapiのオープンソースコードを少々修正・機能拡張しました。その結果、最終的にOSGiバンドルを標準のOSGiフレームワークに適用し、HIDデバイスのUSB通信をサポートすることができます。このバンドルにはネイティブコンポーネントを含みまた、単純化のために、別のjarファイルをサポート対象のアーキテクチャ用にそれぞれ用意することにしました。OSGi愛好家向けに、Linux/armhf(Raspberry Pi向け)アーキテクチャ用の生成された MANIFEST.MF がどのようなものかご覧いただきましょう。
Manifest-Version: 1.0
Bnd-LastModified: 1414694971263
Build-Jdk: 1.7.0_51
Built-By: jtconnor
Bundle-Activator: com.codeminders.hidapi.Activator
Bundle-ManifestVersion: 2
Bundle-Name: hidapi OSGi Bundle for Linux/armhf
Bundle-NativeCode: native/linux/armv6l/libhidapi-jni-32.so; osname=Linux; processor=armv6l
Bundle-SymbolicName: com.codeminders.com.codeminders.hidapi-armhf
Bundle-Version: 1.0.0
Created-By: Apache Maven Bundle Plugin
Export-Package: com.codeminders.hidapi;uses:="org.osgi.framework";version="1.0.0"
Import-Package: org.osgi.framework;version="[1.6,2)"
Tool: Bnd-1.50.0
以下は事前ビルド済みの人気のあるLinuxプラットフォーム用hidapi OSGiバンドルです。
元のソースに対し、以下のような変更を加えました。
  1. MavenカテゴリのOSGiバンドルを使い、NetBeansプロジェクトを作成
  2. javahidapi のJavaソースコードをプロジェクトの src/main/java/com/codeminders/hidapi ディレクトリに配置
  3. アーキテクチャ固有のネイティブライブラリをプロジェクトの src/main/resources/native/linux/architecture ディレクトリに配置。具体的には、Linux/x86版の場合、 libhidapi-jni-32.so ファイルを src/main/resources/native/linux/x86 ディレクトリに配置。
  4. Activator.java クラスをプロジェクトの src/main/java/com/codeminders/hidapi ディレクトリに追加。OSGiでは、このバンドルがアクティベートされた際にこのクラスの start() メソッドが呼び出される。これはバンドルの MANIFEST.MF ファイルに指定する。
  5. 元の ClassPathLibraryLoader.java ファイルを簡素化。現時点ではLinuxにのみ対応。
  6. これはMavenベースのプロジェクトなので、ビルド時に上記で紹介したものと類似のMANIFEST.MFファイルを生成するよう、プロジェクトの pom.xml ファイルを編集した(x86版はこんな感じ)。
また、以下は関連するNetBeansプロジェクトです。上記4個のバンドルをビルドする際に使用しました。
このテンプレートを拡張しこれら以外のアーキテクチャ用のOSGiバンドルを含めたい場合、上記プロジェクトのうち一つを使って作業を始め、複製し、新しい環境のための適切な変更を施すことができます。新プラットフォーム用のネイティブのjavahidapiコンポーネントが使えない場合には、hidapiのソースをダウンロードしてビルドし、プロジェクトに含める必要があるでしょう。
signal11/hidapi
https://github.com/signal11/hidapi/downloads
この作業に興味がある方は、ここ(原文のコメント)に成果をお知らせ頂けると幸甚です。

2014年12月9日

[Java] Project Jigsaw: Modular run-time images

原文はこちら。
http://mreinhold.org/blog/jigsaw-modular-images

以前投稿したように、Project Jigsawがいくつかのステップを踏んでJDK 9に組み入れられています。
Project Jigsaw: Phase Two
http://mreinhold.org/blog/jigsaw-phase-two
Project Jigsaw
http://openjdk.java.net/projects/jigsaw/
JDK 9
http://openjdk.java.net/projects/jdk9/
JEP 200ではJDKのモジュラー構造を定義し、JEP 201ではJDKのソースコードをモジュラー型に再編成し、そしてJEP 220ではモジュールをサポートするようにJDKおよびJREランタイムイメージを再構成します。実際のモジュールシステムはJSR 376(現在作業中)で定義し、対応するJEP(まだ発行されていません)によって実装される予定です。
JEP 200: The Modular JDK
http://openjdk.java.net/jeps/200
JEP 201: Modular Source Code
http://openjdk.java.net/jeps/201
JEP 220: Modular Run-Time Images
http://openjdk.java.net/jeps/220
Java Platform Module System JSR (376)
http://openjdk.java.net/projects/jigsaw/spec/
ソースコードの再編成(JEP 201)は今年の8月に実施しました。このステップは計画的なものであって、開発者やエンドユーザーには影響はありませんでした。モジュラーランタイムイメージ(JEP 220)に対するほとんどの変更が先週後半に統合され、JDK 9早期アクセス版ビルド41でご利用頂けるようになっています。
JDK™ 9 Early Access Releases
9 Build b41
https://jdk9.java.net/download/
このステップはソースコードの再編成とは対照的に、開発者やエンドユーザーにとって大きな影響が及ぶことが想定されます。この作業の詳細はJEP(JEP 220)に記載されていますが、以下に主要な点を書き出しておきます。
  • JREとJDKイメージには現在、理想的な構造が存在します。以前はJDKイメージはJREをjreサブディレクトリに埋め込んでいましたが、現在はJDKイメージは、はからずも開発ツールや以前からJDKにあったその他のアイテムの完全なセットを含むシンプルなランタイムイメージです。
  • ユーザーが編集可能な構成ファイルは以前libディレクトリにありましたが、これは今後は新たなconfディレクトリにあります。libディレクトリに残るファイルはランタイムシステムのプライベートな実装の詳細であり、開いたり、変更したりするべきではありません。
  • エンドースド・オーバーライド機能(Endorsed Standards Override Mechanism)は削除されました。
    Java Endorsed Standards Override Mechanism
    http://docs.oracle.com/javase/8/docs/technotes/guides/standards/index.html
    この機能を利用しているアプリケーションは、java.endorsed.dirsシステムプロパティを設定するか、もしくはjarファイルをJREのlib/endorsedディレクトリに配置しなければ動作しません。同様の機能をJDK 9の後期でupgradable modulesとして提供する予定にしています。
    Upgradeable modules
    http://openjdk.java.net/projects/jigsaw/goals-reqs/03#upgradeable-modules
  • 拡張機能メカニズム(extension mechanism)は削除されました。
    The Extension Mechanism
    http://docs.oracle.com/javase/8/docs/technotes/guides/extensions/index.html
    この機能を使っているアプリケーションは、java.ext.dirsシステムプロパティを設定するか、もしくは以前拡張としてインストールしたjarファイルをJREのlib/extディレクトリに配置しなければ動作しません。ほとんどの場合、jarファイルは拡張として以前インストールされているので、それらをクラスパスの前に単に結構です。
  • rt.jartools.jardt.jarという内部ファイルは削除されました。これらのファイルの中身は現在より効率良い形式でlibディレクトリのimplementation-privateファイルに格納されています。以前tools.jardt.jarに入っていたクラスやリソースファイルは、JDKイメージにブートストラップ・クラスローダやアプリケーション・クラスローダを使うと、現在もなお確認することができます。
  • 新しい、組み込みNIOファイルシステムプロバイダを使って、ランタイムイメージに格納されているクラスやリソースファイルにアクセスすることができます。以前rt.jarやその他の内部jarファイルを読んでいたツールは直接このファイルシステムを使うようにアップデートすべきです。
これらの変更の結果、アプリケーション、特にJDKの内部構造に依拠しているIDEやその他の開発ツールが壊れる可能性があることを認識していますが、パフォーマンスやセキュリティ、メンテナンス性の向上を実現するこうした変更がより大きな価値を生み出すと考えています。既に主要なIDEのメンテナンス担当者に対し、こうした変更があること、必要に応じて支援する準備が整っていることを伝えました。
既存のアプリケーションをJDK 9 build 41以後で実行したときに障害が発生し、それがこの再編成によるもので、JEP 220にや上記の変更内容にあるものが原因でない、と考える場合には、是非jigsaw-devメーリングリストへ知らせる(まだ購読していない場合には、まず購読してください)か、bugs.java.comからバグレポートを上げてください。どうぞよろしくお願いいたします。
jigsaw-dev -- Technical discussion about Project Jigsaw
http://mail.openjdk.java.net/mailman/listinfo/jigsaw-dev
Java Bug Database
http://bugs.java.com/

2014年12月8日

[Database] Parallel Execution Fundamentals White Paper

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

Parallel Execution(多くの人にはParallel Queryとして知られているものです)のプロダクトマネージャとしての最初の投稿で、Oracle Databaseにおけるパラレル実行の基本原理に関する新しいホワイトペーパーをお知らせしたいと思います。以下のリンクよりダウンロードいただけます。
Parallel Execution with Oracle Database 12c Fundamentals
http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-parallel-execution-fundamentals-133639.pdf
Database Resource Managerを利用し、パラレル実行でコンカレントワークロードを管理する方法をまとめたホワイトペーパーも現在用意していますのでしばらくお待ちください。まもなく発行の予定です。

ホワイトペーパーに対するコメント、質問やフィードバック、Oracle Databaseにおけるパラレル実行に関する一般的な質問などは、yasin.baskan at oracle.comにおよせください。以下のコメントセクションを使用していただいても結構です。

2014年12月5日

[Java] The Java 7 EE Tutorial - free eBook!

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

Java EE 7のドキュメントページが見やすいわかりやすいレイアウトに変更されました。
Java Platform, Enterprise Edition (Java EE) 7
http://docs.oracle.com/javaee/7/
これまでよりもJava EE APIやJava EE SDKの各ドキュメント、Java EEチュートリアルをご覧いただきやすくなったはずです。
そのJava EEチュートリアルという有用なリソースが、しかも無料で利用できる、というのはいつか役に立つことでしょう。
Java Platform, Enterprise Edition: The Java EE Tutorial
https://docs.oracle.com/javaee/7/tutorial/index.html
Java EEチュートリアルは見逃されがちですが、貴重なものの一つです。チュートリアルはJava EE 7を取り扱っているので、Java EEを学習したい人たちだけでなく、既にJava EEを熟知されている方にとっても貴重なコンテンツです。しかも、JCAといったJava EEプラットフォームでもあまり知られていない部分も取り扱っています。
Java EE 7入門者向けには、Java EEプラットフォームのわかりやすい入門編があります。
Java Platform, Enterprise Edition: Your First Cup: An Introduction to the Java EE Platform
https://docs.oracle.com/javaee/7/firstcup/index.html
このJava EE 7チュートリアルは無料でご利用いただけ、オンライン版とPDF版があります。さらに、Java EEチュートリアルはePub、Mobi形式でもご利用いただけます(ヒント:オンライン版の右上部をチェックしてください)ので、タブレット、iBook、Kindleなどのお気に入りのeBookリーダーにダウンロードし、ご覧頂けます。オンライン版の右上部をチェックするだけです。もう一度言います。こうしたすばらしいリソースが無料なんです!
最後に、電子書籍はちょっと、という方には、有料ですが、書籍版としてもJava EE 7チュートリアルを入手いただけます。以下はAmazonの例です。
Amazon (US)
http://www.amazon.com/Java-EE-Tutorial-5th/dp/0321994922/
Amazon (JP)
http://www.amazon.co.jp/Java-EE-Tutorial-5th/dp/0321994922/

2014年11月29日

[Java, Security] JSR 375: Java EE Security API

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

Java EEが長い間エンタープライズ・アプリケーションを安全に開発、実行のために使われてきました。明らかに、Java EEおよびそのコンテナはグローバルセキュリティ方程式の一部に過ぎません。Java EE層に注目すると、セキュリティ機能の一部が仕様に取り込まれていることがわかります。それに対し、他のセキュリティ機能はプロプライエタリで異なるJava EE実装に固有のものです。いくつかのセキュリティ機能は、外部アドオン(例えばサードパーティのライブラリ)でもあります。セキュリティは、自己完結するものではなく、異なるコンポーネント間の相互作用を要求することがよくあります(例えばJava EE Application ServerはLDAPサーバーと対話する必要があります)。オンプレミスでのデプロイからクラウドベースのデプロイに移行する際には、状況も変わります。最終的には、セキュリティに関しては移植性がシンプルになることはありません。

Java EEが意味のある存在でいるためには進化が必要です。 Java EE 8コミュニティサーベイからのフィードバックを見れば、明らかにセキュリティは改善されるべき領域です。
Final Results from our Java EE 8 Community Survey
http://glassfish.org/survey
そして、それこそがつい先頃レビューのためにJCPに提出されたJSR 375(Java EE Security API)のゴールです。
The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 375
https://jcp.org/en/jsr/detail?id=375
JSR 375は、Java EE8に含められる予定ですが、その最初のスコープは、コミュニティ・サーベイのフィードバック、Java EE仕様に対する課題やRFE(機能拡張依頼)、EG(Expert Group)メンバーによる長時間にわたるやりとり、コンファレンスでの非公式の議論などに基づきます。

このJSR 375では、達成目標の詳細を提供しています。手短に言うと、JSR 375のゴールは、様々な領域のプラットフォームにわたり、セキュリティAPIをシンプルにし、標準化、近代化することです。
  • User Management(ユーザー管理)「ユーザー・サービス」APIを標準化し、アプリケーションが(たとえばユーザーの作成などの)ユーザー管理操作を実現できるようにします。この「ユーザー・サービス」は、(LDAPやデータベースなどの)物理ユーザーストアを抽象化したユーザーソースを信頼します。ユーザーサービスはデプロイ要件に合うよう構成可能になる予定です。

  • Password Aliasing(パスワードエイリアス)(セキュアな)パスワード・リポジトリに保存されたパスワードに(別名)を指すための構文を標準化します。このパスワード・リポジトリは、その後アプリケーションにバンドルされることがあります(例えば、クラウドへのデプロイメントを考えてください)。
  • Role Mapping(ロール・マッピング)「ロール・サービス」APIを定義、標準化し、アプリケーションが(例えば、グループロールを照会するような)様々なロール・マッピング操作を実施できるようにします。これは、環境のニーズに基づいて適応可能な、異なるロールマッパー(例えばLDAPやファイル)を介して行われます。

  • Authorization(認可)CDIインターセプタ・アノテーションを定義し、メソッドレベルでアプリケーションドメインのルールを事前に決定するために使います。
  • Authentication(認証)認証まわりでいくつか機能強化が予定されています(Webアプリケーションが様々な認証方法を提供できるようにする、とか)
これは初期スコープの概要に過ぎません。また、Expert Groupは、これらの新しいAPIを簡単に利用するために、一部のJava EEの直交テクノロジ(Java EE orthogonal technology、例えばCDIイベントや式言語など)をどうやって活用できるか、を調べる必要もあります。このJSRのについてもっと知りたいという方は、JSR 375をお読みください。また、JavaOneでLinda Demichielが話したJava EE Overviewの動画をご覧いただくこともできます。セッションの中で、そうした考えに触れています。
JavaOne Replay: 'Java EE 8 Overview' by Linda DeMichiel
https://blogs.oracle.com/theaquarium/entry/javaone_replay_java_ee_8
JSR 375はJCPレビュー期間に入りました。その後の次のステップは承認投票期間になるはずです。
JCP 2: Process Document
2. INITIATE A NEW OR REVISED SPECIFICATION
2.2 JSR REVIEW
https://jcp.org/en/procedures/jcp2#2.2
そして、この投票を通過すれば、Expert Groupを形成し、実際の作業(ならびに議論)がスタートする予定です。そんなわけで、現在我々はちょうどこの取り組みの端緒にいますが、Java EE 8の様々な部分の準備を整えるさまを見ることができうれしいです。

[Linux, Virtualization] Oracle Linux Docker Base Image on Ubuntu 14.10

原文はこちら。
https://blogs.oracle.com/brunoborges/entry/oracle_linux_docker_base_image

Oracle Linuxチームががんばってくれたおかげで、Dockerのサポートが提供されるようになりました。8月からOracle Linux YUMリポジトリでDockerバイナリがリリースされていることを知って喜んでらっしゃることと思います。
Ahoy! Cast off with Docker on Oracle Linux
https://blogs.oracle.com/linux/entry/ahoy_cast_off_with_docker
そして先頃、Oracle Linux 6、7のOracle Linux Docker Base Imageがリリースされました。
Oracle Linux images for Docker released
https://blogs.oracle.com/linux/entry/oracle_linux_images_for_docker
Oracle Linux(OL6とOL7)およびDockerのドキュメントにも説明が入っています。
Oracle® Linux Administrator's Solutions Guide for Release 6
Chapter 10 Docker
https://docs.oracle.com/cd/E37670_01/E37355/html/ol_docker.html
Oracle® Linux Administrator's Guide for Release 7
Chapter 26 Docker
https://docs.oracle.com/cd/E52668_01/E54669/html/ol7-docker.html
DockerとOracle Linuxに関しては、以下のページからどうぞ。
Docker Images from Oracle
http://public-yum.oracle.com/docker-images/
では、なぜこれが重要なのか、とおたずねになるかもしれません。そうですね、ある時点でFusion Middleware製品チームが自身の製品、たとえばWebLogic ServerをDocker上でも動作保証をするよう進む場合、それは明らかに必要とされるステップだからです。
Docker, Java EE 7, and Maven with WebLogic 12.1.3
https://blogs.oracle.com/brunoborges/entry/docker_java_ee_7_and
それゆえ、まだ動作保証もサポートも対象外ではあるけれども、Oracle製品をDocker上で今すぐ使いたい場合、Oracle Linux Base Imageを使ってください。
開発者として、自身のラップトップでUbuntu Linuxを使いたいので、たとえばOL7 Docker Base Imageを使うにあたり、以下のすぐに終わる簡単な手順を実施しなければなりませんでした。
  1. Ubuntu環境にDockerがインストール済みであることを確認
    Ubuntu - Docker Documentation
    https://docs.docker.com/installation/ubuntulinux/
  2. OL7 Base Imageをダウンロード
    http://public-yum.oracle.com/docker-images/OracleLinux/OL7/
  3. まずxzを使ってファイルを展開する。Dockerがxzバイナリを見つけられないという問題が発生するかもしれません。
  4. $ sudo docker load -i oraclelinux-7.0.tar.xz
    2014/11/28 18:36:08 Error: Untar exit status 1 exec: "xz": executable file not found in $PATH
    
    $ unxz oraclelinux-7.0.tar.xz
  5. 展開終了後(tar ballのまま)、rootユーザーとして、ローカルDockerリポジトリにイメージを読み込む
  6. $ sudo docker load -i oraclelinux-7.0.tar
  7. インストールの確認
  8. $ sudo docker images
    REPOSITORY     TAG  IMAGE ID       CREATED      VIRTUAL SIZE
    oraclelinux    7.0  5f1be1559ccf   2 weeks ago    265.2 MB
  9. このイメージをベースにしたコンテナを作成し、実行
  10. $ sudo docker run -t -i oraclelinux:7.0 bash
これでできあがりです。DockerとOracle Linuxで遊んでください。そしてFusion Middleware製品で何か素敵なものを作成される場合には是非お知らせください。