これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
CTC 教育サービス
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
『建設者』：
気が遠く成るほどに果てしなく続く、奇々怪界に幾重にも折り重なり積み上げられた階層。
無制御の「建設者」が上へ上へと無為に階層化された壮大な都市を築き続ける。
まるで「蟻」が下へ下へと地下深くに身の丈を超えた巨大な巣を造る様相。
無秩序に建設を続ける行為は不可解で不自然な人工的な作為で構成されているだが、一体何なのかの理解を超えている。
階層化された都市を管理する「統治局」の保安部隊でセーフガードと呼称される尖兵「駆除系」に不法居住者である人間は抹殺される未来世界。
ただ際限なく無尽蔵に建設される都市の片隅で、駆除される側となった人間が散り散りに隠れ生き延びている。
無限に続くとも思える程に重層化された広大な都市の階層を「答え」を探し求めて独り放浪する探索者がいる。
セーフガードや都市に生息する亜種の珪素生物と遭遇する危険を顧みずに微塵の躊躇も恐れも落胆もなくただ黙々と探索を続ける。
見つかる筈のない答えを探し続けることだけが、無口な彼の生きる目的であるかの様に。
『霧亥』：
「頭部の装備を脱げ、眼がみたい。」
「この辺りにネット端末遺伝子を持つ人間はいるか？」
「あんたは何者なの？」
「俺は霧亥。人間だ。」
Netflix（ネットフリックス）がオリジナルコンテンツとしてアニメーション映画「BLAME! （ブラム）」を2017年に公開しているのが本作です。現在も全世界でネット配信しています。
少しばかり遅ればせながら筆者も現在追従しておりまして視聴を繰り返すほどに夢中です。
（ Netflix に関しては、過去コラム『第39回 ハウス・オブ・カード』（前編）と『第40回 続・荒野の用心棒』（後編）にて顛末を記載しています。併せて御覧下さい）。
アニメーション映画「BLAME! （ブラム）」となった原作は弐瓶勉が描く同名タイトルのハードSF漫画ですが、原作漫画は全巻を大人買いしまして只今拝読中です。
映画版「BLAME!」は、原作と同じく人類が「違法居住者」として駆除（抹殺）される未来都市が舞台です。
ネットスフィアに接続できる人間が絶えて主人が居なくなった都市が「建設者」によって勝手に増殖し無限に続くような階層を築き上げている世界でその階層の隙間に隠れ住むように寄り添って生きている後世の人間たちのサバイバルの物語です。
部落と化した人々、残されて困窮する彼等の前に黒装束に身を包んだ旅人「霧亥」（キリイ）が唐突に現れ窮地を救います。前述の短い会話が遭遇後のやり取りです。
霧亥には探し物がある様子ですがそれが何なのかも知る由もなく、そしてそれが今にも忘れられようとしている人類文明を救うためなのかという意図すらも分からないままに、出会った彼等と成り行きで関わっていきます。
映画版を見終わった印象を振り返ると「マッドマックス2」 "Mad Max2：The Road Warrior" と「ターミネーター2」"Terminator 2: Judgment Day" のテクスチャーを大胆に持ち込んでミクスチャーしたショート・ストーリーと準えることが出来るかもしれません。
主人公の「霧亥」"Killy" を一見すると「メル・ギブソン」"Mel Gibson" 演じる無口な「マックス（マクシミリアン・ロカタンスキー）」"Max, Maximillian Rockatansky" が大口径の銃（ショットガン）と大型ナイフを携行しボロボロの革ジャンをプロテクターで修理して着続けているような風体を彷彿とさせる上に、パンクファッション「原宿ブラック」で購入したようなベルトだらけ装丁も施した真っ黒な装いです。短銃の形状をした強力な武器「重力子放射線射出装置」"Gravitational Beam Emitter" と大型ナイフも携行しています。
しかも無口な男の素性（潜在能力）としては「アーノルド・シュワルツェネッガー」"Arnold Schwarzenegger" が体現する「ターミネーター」"T-800: Cyberdyne Systems Model 101 Series 800 Version 2.4" に相当する高度にサイボーグ化された体躯の機能を持ち合わせているのです。
加えて、階層化都市が勝手に拡張し人間を排除するのも「スカイネット」"Skynet" もしくは「マトリックス」"The Matrix" の「マシン・シティ」"Machine City" に通じるところがあるからかもしれません。
着ている洋服の素材は不明ですが、主人公「霧亥」の装いが映画版製作者のストーリーに少なからず影響を与えている様が背後に見え隠れします。
原作においても霧亥の孤独で危険な旅路を描くストーリーが本筋なのでしょうが、映画版では最終版の回顧シーンに注目すると救世主としての霧亥を想い出（伝説）として語る様は、やっぱり「マッドマックス2」 "Mad Max2：The Road Warrior" がオマージュとなっていると思います。
ラストシーンで霧亥が皆とは袂を分かつまま、独り敵と対峙します。痺れます。
回顧シーンで霧亥はまだ独り終わりなき旅を続けているのだろうと思いを馳せることで締めくくります。
原作漫画はストーリーが異なる様子ですが熾烈なアクション描写を含めじっくり読みたいと思います。
『Java VM』：
2018年に突入してから Java の周りが騒がしくなってきています。
Java の開発環境は長い間、アップデートされずにリリースの延期が相次いでいたのですが、ここにきて立て続けにメジャーリリースがされています。少し振り返ってみます。
Java SE 7 は、2006年に開発が始まったもののリリースされたのは、何度も延期がされた挙句これ以上は遅らせることが出来ないと未実装の新機能を先送りして2011年にリリースされました。結果、5年もの時間が経過したことになります。
これが、オラクルによるサン買収後の初のリリースです。迷走が始まった感は否めません。
次のメジャーリリースである Java SE 8 も当初から延期されて2014年にリリースされ「ラムダ式」など前回積み残した機能を詰め込んで発表するまでに約三年間有しました。しかも本リリースで当初追加する予定だった機能 (Project Jigsaw) は次回に延期されます。
そして Java SE 9 のリリースがさらに三年後の 2017年です。やっと宿題を片付けましたという感じです。
ここで変化が露呈します。三年間のインターバルを経てリリースされるサイクルなのかと世間も理解しはじめていたと思うのですが、次の Java SE 10 が 2018年にリリースされたのです。Java SE 9 がリリースされた半年後です。
どういった風の吹き回し（気分の変化）なのだろうと不審に思っていると、どうやらリリースサイクルを定期化するという方針が発表されました。年2回メジャーバージョンアップしてリリースしますとのことです。
これには大きなオマケがあって、オラクルの「提供方法」と「サポート」の変更が併せて公表されました。
リリースサイクルの変更に伴いサポートされるメインテナンス期間も追従して次のメジャーバージョンアップまでという極端に短い期間に限定される見込みです。つまりメインテナンス期間が半年となり、その間でしかバグフィックスやセキュリパッチが提供されなくなってしまいます。これでは Java をベースとしたシステムでは安定して長期の運用をすることが難しくなります。
もし、企業などで必要な長期のメインテナンスが必要な場合には、有償サポートを得てくださいとのことです。
もう一つの変更は「提供方法」ですが、今まで無償提供されていた JDK が有償配布になるらしいのです。
Oracle JDK としての無償公開は Java SE 10 (JDK 10) までと発表されています。
Java SE 11 からは 、Oracle JDK ではなく今まで同等の無償公開されるのはオープンソース実装版である OpenJDK 11 をご利用くださいということだそうです。
それゆえに、Java SE 11 では Oracle JDK 同等の実装を施した OpenJDK が同じタイミングでリリースされる見通しです。
Java SE 11 は、前リリースから半年後の2018年9月に予定されています。
これらの流れからオラクルは本気で Java でマネタイズしようという目論見が感じられます。
Java SE 11 でのオープンソースとのシンクロナイズは、袂を分かつ基準点として揃えておこうという作為と捉えることも出来ます。
オラクルのマネタイズ作戦に意義を申し立てるつもりはないのですが、公共プラットフォームを所有（買収）することでの地位を確保してその恩恵を得ているにも関わらず、その「公共の場所」として確率された存在で金儲けしようという行為には、少なからず反感や不安を駆り立てるなど枚挙に遑がない（いとまがない）のは、想像に違わないでしょう。
ですが、オラクルのマネタイズの方針の裏には、懐具合や株主などの突き上げなど様々な背景（理由）があるのかと想像されます。
勝手に憶測すると要因の一つとなったのは、サン・マイクロシステムズが長年独占して固辞してきた Java をオープンソースとしたのが 2007年、オラクルがサン・マイクロシステムズを買収したのが 2009年という時系列がポイントになりそうです。
オラクルが長きに亘って希求した「普遍的なプラットフォーム 」(Java VM) を手中にしたのはオープンソースされた後ですが、そのオープンソースコミュニティで主導権を握れなかったのが起因しているのではないかと考え始めています。
勿論、コミュニティでオラクルが主導権を握れなかった信頼されなかった理由も様々にあるのでしょうが、ジェームズ・ゴスリンが不在なのは決定的です。
サン・マイクロシステムズでは、ネットワークウィンドウシステム 「NeWS」"Network extensible Window System" そしてプログラミング言語 「Java」、プラットフォーム「Java 仮想マシン」"Java VM" という技術を世に送り出した「ジェームズ・ゴスリン」"James Gosling" という神様がオラクル買収後に退職したのは、たった一年後の2010年のことなのです。
それから数年が経過していつまでたっても業界の主導権を握れないと判断したオラクル経営陣が即物的に収益に傾いたマネタイズに踏み切ったのだと考えられます。飽く迄、憶測にしか過ぎませんが近視眼的な判断であまり賢い戦略とは言えないでしょう。
この経営判断が「アルタビスタ」"AltaVista" を無視する（理解できない）という大きな過ちを犯したために「ディジタル・イクイップメント・コーポレーション」"Digital Equipment Corporation, DEC" という巨像が倒れる羽目に陥ったのですが、オラクルが DEC の二の舞となるのではと危惧されます。
これらの方向転換は大きな波風を起こすどころか、新しい潮流を呼び込む呼び水になりそうな気がします。
『階層』：
片や大きな胎動が始まっている予感を遅ればせながら察知しました。
これは長期熟成された従来の Java VM の階層構造に変更を加えることで更なる汎用プラットフォームを目指すという試みです。
この挑戦は長い期間を掛けてじっくり実装を進めてきたご様子で、それが結実しはじめた現在時点でオラクルが満を持して GraalVM 1.0を 2018年にリリースしました。
GraalVM として提供されるプラットフォームは下記の階層で構成されます。
1. Graal (Java実装の JITコンパイラ）
2. SubstrateVM （コンテナ軽量ラッパー）
3. Truffle （言語インタプリタ用フレームワーク）
Java SE 7 で提供されている Java VM から少しずつ実装を施していたらしく Java SE 9 では experimental （実験実装）として利用も可能になっているらしいです。
GraalVM は、階層化されて構成されている Java VM に新たな息吹を吹き込む期待を抱くことが出来ます。
今までコンパイラーインターフェースを通して「バイトコード」"bytecode" を供給していた「JIT コンパイラ」"Just-In-Time Compiler" は、Java 言語のセマンティクスに特化したといえる C++ 実装の コンパイラでした。コンパイラによって生成されたバイトコードを実行するのが最下層の HotSpot VM です。 HotSpot VM も C++ で実装されています。
長年かけて階層化された Java VM の内部構造は全てのコンポーネントが C++ プログラミング言語で実装されており、C1 / C2 という二つのコンパイラを内包しています。
C1 コンパイラは、クライアントコンパイラ。クライアントアプリケーションで利用するのに適した高速で軽量化されたバイトコードコンパイラです。
C2 コンパイラは、サーバーコンパイラ。サーバーサイドで利用される様な長時間実行されるアプリケーションでマシン依存の最適化されたバイトコードを生成するコンパイラです。
二つの JIT コンパイラの実装は異なるため、生成されるマシンコードも異なります。二つのコンパイラは指定オプションによって別個に使い分けることや、二つのコンパイラを併用した階層的コンパイルも使用可能です。
┌─────────────────┐
│ HotSpotVM │
│ ┌─────┐ ┌─────┐ │
│ │ C1 │ │ C2 │ │
│ └─────┘ └─────┘ │
│ ┌─────────────┐ │
│ │ Compiler Interface │ │
│ └─────────────┘ │
│ ┌─────────────┐ │
│ │ HotSpotVM │ │
│ └─────────────┘ │
└─────────────────┘
All components are implemented in C++
┌─────────────────┐
│ GraalVM │
│ ┌─────┐ ┌─────┐ │
│ │ C1 │ │ Graal │ │
│ └─────┘ └─────┘ │
│ ┌─────┐ ┌─────┐ │
│ │Compiler │ │ JVMCI │ │
│ │Interface │ │ │ │
│ └─────┘ └─────┘ │
│ ┌─────────────┐ │
│ │ HotSpotVM │ │
│ └─────────────┘ │
└─────────────────┘
Graal and JVMCI are implemented in Java
これを、Java SE 7 から「invokedynamic命令」を導入したことで動的型付け言語のコンパイルおよびランタイムを JVM で実装する際の障害が払拭され動的型付け言語対応可能になったことを受けて JVMのコンパイラーインターフェース "JVMCI" (Java-Level JVM Compiler Interface) が提供されました。JavaでJITコンパイラを実装することが出来るという意味です。
この JVMCI インターフェースを経由して Java 実装の汎用 JIT コンパイラ である "Graal" コンパイラを使いJVM の階層構造が利用できるのです（過去コラム『第2回 （続）Java SE 7 登場』を併せてご覧ください）。
そして "Truffle" は API であり、ASTインタプリタ(abstract syntax tree interpreter, 抽象構文木)のフレームワークとして提供されてインタプリタ言語の実装を提供しやすくしてくれます。"Truffle" の効能として考えられるのは、最適化されたプラットフォーム (HotSpotVM) で汎用/独自言語を高速に実行することが可能になります。
そこで問題となるのが言語に付属している「ライブラリ」です。ライブラリの一部はネイティブコード(多くが、C もしくは C++ で記述) 実装されているため動かないのです。これらネイティブコードをサポートするのが、SubstrateVM の役割であろうと考えられます。SubstrateVM では直接ネイティブバイナリにコンパイルが出来るらしいです。事前コンパイルが可能であれば、組み込み向けの用途にも適用出来るようになり「プラットフォーム」として守備範囲が膨大に広がります。
JavaVM ベースの言語としては、Java、Scala、Groovy、Kotlin 等があります。これらは既に JVM をプラットフォームとして稼働しています。
それらに加えて、Ruby, Python, R, JavaScript, LLVM IR (Intermediate representation, 中間表現) など広く利用されている他のプログラミング言語や特定ドメインを解決するためだけの独自言語なども含めた「多言語 VM のプラットフォーム」"Polyglot Virtual Machine and Platform" としての機能を実現することが可能になることで、普遍的なプラットフォームの地位を獲得出来るのではないのかという期待が芽生えてきます。
┌────────────────────────────────┐ │ ┌─┐┌──┐│ │ │C ││C++ ││ │ └─┘└──┘│ │ ┌─────┐┌──┐┌───┐┌─────┐│ │ │JavaScript││Ruby││Python││ LLVM ││ │ └─────┘└──┘└───┘└─────┘│ │┌──┐┌───┐┌─────────────────────┐│ ││Java││Scala ││ Truffle Framework ││ │└──┘└───┘└─────────────────────┘│ │┌──────────────────────────────┐│ ││ Graal Compiler ││ │└──────────────────────────────┘│ │┌──────────────┐┌──────────────┐│ ││ JVM Compiler Interface ││ SubstrateVM ││ │└──────────────┘└──────────────┘│ │┌──────────────┐ │ ││ HotSpotVM │ │ │└──────────────┘ │ └────────────────────────────────┘ GraalVM = Graal + Truffle + SubstrateVM / HotSpotVM
"Graal" (グラール) はフランス語で「杯」（さかずき）を意味するらしく、つまり英語では ""Grail" (グレイル)、「聖杯」"Holy Grail" の「杯」です。
「聖杯」となれば「インディ・ジョーンズ/最後の聖戦」"Indiana Jones and the Last Crusade" で出てきた聖杯のように奇跡譚を拝むことになるやも知れません。または、「モンティ・パイソン・アンド・ホーリー・グレイル」"Monty Python and the Holy Grail" でのアーサー王伝説と化すのかもしれません。まだ不明です
"Truffle" (仏：truffe, トリュフ) は、高級食材です。世界三大珍味の一つで滅多にお目にかからないものです。「滅多にお目にかからないよ」と言いたいのでしょうか。
"Substrate" （サブストレート）は、そのまま「回路基板」もしくは「プリント基板」 です。まさにチップを搭載前の基盤を意味しています。やはり IoT 時代を見据えて「組み込み」で採用されたいとの意気込みからの命名なのかもしれません。
"GraalVM" （云わば「聖杯仮想機械」）は、これらを組み合わせて階層化しています。
Oracle が提供する GraalVM と同じ方向性で IBM では、 "OpenJ9" という別アプローチを試みています。
こちらは Eclipse に寄贈されて "Eclipse OpenJ9" と名前を変えてランタイムには、"Eclipse OMR" を同梱しています。
この二つも過去と同じく競争になり果たしてどちらが主導権を握るのかが、将来大きな糧になり覇権の行く末を決める一因にもなりそうです。
他方でマッシブなサービスを提供する先駆者である Twitter は先行して GraalVM を採用しており OpenJDK を土台としたカスタム JDK をこしらえて既にサービスに投入しているそうです。今後、これら率先して新技術を採用したリーダーが先行している影響が後陣を拝したライバルたちにどのように流布（伝染）されて展開（感染）していくのかに注目が集まるところです。
筆者は Java 言語(及び Java VM) 自体を全く触っていないので、そのシャープさという意味では体感はしていませんが、これら様々な「階層」については興味もあるので、未来の潮目を占う意味で調査を継続してみたいとは思います。
『探索者』：
無限に続くとも思える程に重層化された広大な都市の階層を「答え」を探し求めて独り放浪する探索者。
セーフガードや都市に生息する亜種の珪素生物と遭遇する危険を顧みずに微塵の躊躇も恐れも落胆もなくただ黙々と探索を続ける。
見つかる筈のない答えを探し続けることだけが、無口な彼の生きる目的であるかの様に。
現在もこの多層化された回廊のどこかで探索を続けているのであるのか知る由もない。
何かを探し求め続けることは人間として本質的な欲望なのかもしれない。
「俺はネット端末遺伝子を探している。」
次回をお楽しみに。
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
