2014年12月22日

[Java, JavaScript] Node.js and io.js on Java

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

Nashorn(ドイツ語でRhino) JavaScriptエンジンはJDK 8の数多ある機能改善のうちの一つであり、Rhinoとして知られる以前のJavaScriptエンジンに変わるもので、より高速に動作します。また、別の注目すべき機能があります。それは多くのNode.jsやio.jsアプリケーションをJVM上で実行することができる、というものです。これらのアプリケーションは最適化されたJavaライブラリを呼び出したり、JMXを使って監視能力を自動的に受け取ったりすることができます。
まもなく登場するJDK 8 update 40では、Nashorn/JavaScriptのパフォーマンスがOptimistic Typingにより、より一層向上するはずです。
Nashorn Architecture and Performance Improvements in the Upcoming JDK 8u40 Release
https://blogs.oracle.com/nashorn/entry/nashorn_performance_work_in_the
http://orablogs-jp.blogspot.jp/2014/12/nashorn-architecture-and-performance.html

Java Virtual Machine - More than just Java

Java Platformは、異なるタイプのアプリケーションを実行する方法を提供しています。たとえアプリケーションがJavaプログラミング言語で書かれていないとしてもです。その結果、開発者はJVMの最適化機能や安定性を活用できるとともに、システム管理者はデプロイメントの管理・監視が向上します。
JVMで動作する他の言語の例として、JavaScript(Nashorn)、Ruby(JRuby)、Python(Jython)、Scala、Groovyなど、様々なものがあります。

Project Avatar – A JavaScript services layer on the JVM

Avatar.jsはNodeプログラミングモデル、APIやモジュール・エコシステムをJavaプラットフォームにもたらすプロジェクトです。
Avatar.js
https://avatar-js.java.net/
JavaScriptで記述されていますが、これらのアプリケーションはJavaプラットフォームの拡張性、管理性、ツールや拡張可能なJavaライブラリやミドルウェアのコレクションを活用することができます。Avatar.jsバイナリをダウンロードすると、開発者はアプリケーションを実行できます。例えば、Tim Caswellの記事である "Hello Node!" には、hello-console.js と hello-http.js という基本的なサンプルが含まれており、これを使ってAvatar(訳注:厳密にはAvatar.jsです)のテストのために利用することができます。
Hello Node!
http://howtonode.org/hello-node
「Nashorn, The Hidden Weapon of JDK 8」というプレゼンテーションが2014年12月のSilicon Valley Java User Groupの会合で発表されました。このスライドではNetflixでのNashornとAvatarの利用に関して説明しています。さらに別のNashornのデモを紹介しています。
Nashorn, The Hidden Weapon of JDK8
http://www.meetup.com/sv-jug/events/218752724/
Nashorn @ Netflix
https://docs.google.com/file/d/0B1_6_iTSwCcjVlc0d1JQLTFTUUU/edit
nashorn at netflix (スライドとデモコード)
https://drive.google.com/folderview?id=0B1_6_iTSwCcjcFRUTjRQRWV2bkk&usp=drive_web#

Avoid rewrites and re-use libraries

サーバーサイドJavaScriptアプリケーションをJVMで実行する主要なメリットに、Javaライブラリへアクセスできる、というものがあります。開発者は主要なライブラリ、SQLやNoSQLドライバ、Hadoopクライアント、エンコーディングライブラリなどの機能を書き直す必要はありません。以前の「Nashorn, the rhino in the room」というエントリで別のサンプルがありますが、これはNode.jsに固有のものではありません。
Nashorn, the rhino in the room
https://blogs.oracle.com/java-platform-group/entry/nashorn_the_rhino_in_the
Niko Köbler(@dasniko)がAvatar 2.0とそのModel Store APIに関する2部構成の記事を出しています。このモデルストアAPIを使用することで、開発者はより簡単に、SQLやNoSQLと対話することができ、そして多くの既存の最適化されたものから便益を享受することができます。

Monitoring Applications on the JVM

すべてのJavaプロセスをJMXと呼ばれるメカニズムで監視することができます。システム管理者はリモートの認証済みJMX接続を有効にして、こうした実行中のアプリケーションを外部から監視するのではなく、内部から監視することができます。JMX監視(ローカル、リモートとも)に関する詳細情報は、以前のエントリからどうぞ。
Deep Monitoring with JMX
https://blogs.oracle.com/java-platform-group/entry/deep_monitoring_with_jmx

Monitoring applications with Mission Control / Flight Recorder

Java Flight Recorderを使うとJVMアプリケーションを本番環境で効果的に監視することができます。標準的な(NetBeansプロファイラのような)開発プロファイラとは異なり、Flight Recorderは性能への影響が軽微でほぼ無視できます。
Mission Controlのダッシュボード・ビューには、CPUやメモリリソースの基本情報が表示されます。開発者はThreadタブを使ってシステムのスループットや、アプリケーションが特定のリソースでブロックしているかどうかをより詳細に把握できます。
Mission Controlを立ち上げるには、jmcコマンドを実行し、Avatarアプリケーションに接続します。以下のスクリーンショットは、com.oracle.avatar.Serverとして識別されているNode.jsアプリケーションをMission Controlで監視している様子です。

Node.jsアプリケーションをJavaScriptで記述していますが、Flight RecorderはCPUのスパイクのようなイベントに関するトリガーベースの記録も可能です。システム管理者や開発者が記録を見返して、何がそのイベントの原因だったのかを知ることができます。
詳細情報は、Mission Controlの製品情報ページやユーザーガイドからどうぞ。
Java Mission Control
http://www.oracle.com/technetwork/java/javaseproducts/mission-control/java-mission-control-1998576.html
Java Mission Control (JMC) and Java Flight Recorder (JFR)
http://docs.oracle.com/javacomponents/jmc.htm

Additional ways of running Node.js on the JVM

Avatar.jsはNode.jsアプリケーションをJVMで実行するための方法の一つです。
Oracle Java上で動作させる場合、どちらのプロジェクトも上述のようにFlight Recorder/Mission Controlで監視することができます。この監視をOracle JVM自身が直接提供しているため、コードの変更や追加の監視パッケージの適用は不要です。

2014年12月21日

[FMW, BPM] ADF FormをBPM Process ComposerのPlayerで使ってみたり、タスクを取り下げてみたり

JPOUG Advent Calendar 2014 の12月21日分のエントリです。昨日は @mutatsu さんのエントリでした。
本当はNashornについて書きたいところですが、そこは耐え難きを耐え、Oracle Business Process Management Suite(以下、Oracle BPM)について今年よくお尋ねいただいた質問とその回答をご紹介します。なお、「Oracle BPMって何?」という方はこちらをどうぞ。
Oracle Business Process Management Suite
http://www.oracle.com/technetwork/jp/middleware/bpm/overview/index.html

Q1) BPM Process Composerで利用可能なProcess Player機能って、ADF Formでも使えるの?
A1) はい、使えます。
まず、Process Composerとは、Web画面でプロセスの設計・開発ができるツールです。
Process Composer (画面は12cの例)
そのComposerに含まれているProcess Playerとは、作成したプロセスが想定通りに動作するかを入力フォームや作業するロールを含めて確認するための機能です。簡単に言えばテストのための機能です。
Process Playerの実行例
Process Composerでは、Web Formと呼ばれる画面を使って、簡単に入力フォームを作成できますし、
Web Formの例
もっと凝った、リッチな画面が必要であれば、ADF Formと呼ばれるADF(Application Development Framework、アプリケーション開発のためのOracleが提供しているフレームワーク)を使った画面をJDeveloperで開発し、プロセスの入力・表示画面として利用することができます。
ADF Formの例
で、Web Formを使うか、ADF Formを使うかは、Composerのヒューマンタスク機能で設定するのですが、下図の通り、その設定内容がわかりづらいために、上記質問をいただいた、というわけです。
Web Formの場合
ADF Formの場合
では、本題。ADF Formをタスクフォームウィザードを使って、BPMプロセスと一緒にJDeveloperからデプロイした場合、プレゼンテーションの設定は、「何もする必要がない」というのがが答えです。実際にProcess Playerを実行すると...

という感じで、正しくADF Formが表示されます。
ただし、何も設定しないで動作させるためには、以下の前提条件を満たしていることが必要です。

  • PAM(Process Asset Manager)にBPMプロジェクトをチェックインしており、Process Composerからプロジェクトにアクセスできること
  • BPMエンジンの稼働するサーバ(たいていの場合はSOAサーバ)にADF Formがデプロイされていること

APIを使って画面を作成している場合や、外部JNDI経由でADF Formを作成している場合には、ADF Formの設定をProcess Composerで実施する必要があります。

Q2) ワークフローの取下げ(ワークフローの起票をなかったことにする)ってできるの?できるタイミングは?
A2)取下げはプロセスが完了していないかぎり、任意のタイミングで可能です。
ヒューマンタスクの定義で、「取下げ」はタスク作成者、タスク所有者、管理者が実施できるようになっています。

例えば、先ほどのプロセスで、James Cooper(jcooper)というアカウントの人が起票した経費精算レポートのタスクを、すでに上長であるJohn Stein(jstein)が取得しているとします。James CooperとしてBPM Workspaceにログインし、その状況を確認してみましょう。

右下のペインに[アクション]がありますが、これを開くと、[取下げ]が選択できます。

これを選択すると、当該インスタンスは終了します。タスク履歴上は取下げ済になっています。


BPMについてはいろいろお伝えしたいことがありますが、今回はこのあたりで。
明日は吉川和宏さんのエントリです。お楽しみに。
Happy holidays!

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/