Who's Who in Javaの続きです。
前回はJavaを作っていた人たちを紹介しました。本エントリーでは現在、Javaを作っている人たちを紹介します。
発表資料でいうと、ここからです。
本エントリーで紹介する人は、今のところすべてOracleの社員です。オープンソースになったとはいっても、Javaの方向性を決めて、実装しているのは、やはりOracleの人が中心です。
Mark Reinhold
まずはじめに紹介するのが、JavaのチーフアーキテクトであるMark Reinholdです。
Markが表舞台に登場したのは、J2SE 1.4で導入されたNIOです。
J2SE 1.4のころの大きめの標準APIは、JCPで標準策定が行われていました。NIOはJSR 51です。JSRはJava Specification Requestの略です。
そのJSR 51のスペックリードがMarkでした。
NIOも結構もめたらしいのですが、それをまとめたのがMarkだったということをJSR 51のエキスパートグループにいらした方から聞いた覚えがあります。JSR 51のエキスパートグループを見てみれば分かりますが、日本の某企業も加わっているのが分かりますね。
その後、MarkはJava 5のスペックリードになります (JSR 176)。彼は技術力だけでなく、交渉をまとめる調整力があったからだと思います。
Java 6ではMarkはスペックリードを外れます。Java 6からJava 7のころは、SunがOracleに買収されたり、オープンソース化や、関数型の導入などでゆれにゆれていた時期です。
そこで、Java 6のスペックリードがまとめきれなくなったのか、途中からMarkが再登板します。
Java 7のリリース予定が遅れまくっていた時に、ラムダ式はJava 8にスリップさせることを決めたのもMarkです。
Javaを作っている開発者や、JCPのエキスパートグループなどから全幅の信頼を持たれていたMarkだからこそ、まとめられたのだと思います。
このころ、SunでJavaを作っていた日本人開発者の方から聞いた話なのですが、「Markが言うことなら信用できる」と多くの開発者が言っていたらしいです。
そして、激動期のJavaのスペックリードをJava 9までつとめます。Java 10からはこの後に紹介するBrian Goetzがスペックリードとなりました。
現在では大きな方針変更のたびにMarkが引っ張り出されています。たとえば、LTSの期間を変えるとか、JVMLSのエントリーで紹介したProject Leydenなどです。
彼がスペックリードだった時代、JavaOneのテクニカルキーノートといえばMarkでした。
"Welcome to JavaOne"で始めるのが恒例で、彼の口癖にa lot ofではなくa bunch ofがあります。こういう言い方を知ったのも彼のセッションでしたね。
しかし、彼はSunもしくはOracleが主催のイベント以外では登壇をほとんどしていません。たぶん、Devoxxぐらいじゃないかなぁ。
日本でJavaOneをする時に、Markに来日してもらおうと、当時Oracleだった寺田さんが奮闘していたのですが、結局果たされず。ぜひ、一度は日本にも来てほしいですね。
Brian Goetz
Mark ReinholdからJavaのスペックリードを受け継いだのがBrian Goetzです。肩書としてはJava Language Architectです。
Brianはもともと自分の会社を持っていました。その当時、IBMのDeveloperWorksという技術コミュニティサイトがあって(今はIBM Developerになっています)、そこに多くの記事を書いていました。DeveloperWorksは日本語サイトもあって、Brianの記事も訳されていて、さくらばも読んでました。残念なことにDeveloperに衣替えした時に、日本語のサイトはなくなってしまったようです。
また、彼はJSR 166 Concurrency Utilitiesのエキスパートグループのメンバーでもありました。JSR 166がJ2SE 5に導入された後、Brianが中心になってJava Concurrency in Practice (日本版はJava並行処理プログラミング)を書き上げています。
もう20年近く前の本ですが、今でもJavaでパラレル処理について一番おススメできる書籍です。残念ながら、日本語版は絶版になってしまいましたが...
さて、この本が出版されたころに、BrianはSunに入ります。
彼が担当したのが、Project Lambdaです。
Project Lambdaはほんといろいろあったプロジェクトです。
関数型をJavaに導入するということで、Project Lambdaの前に前哨戦があり、いくつもの提案がされていますし、もちろん反対派も多かったのです。
たとえば、前のエントリーで紹介したJoshua BlochとNeal Gafterはそれぞれ別の方式を支持し、そのせいで仲たがいしてしまったという噂もあります。
Project Lambdaになってからも、二転三転してやっとまとまったのがJava 8だったわけです。
Brainはプロジェクトリードとして、Project Lambdaをまとめたわけです。
その後も、Project AmberやProject Valhallaのプロジェクトリードになり、Java 10からはJavaのスペックリードになりました。
これからのJavaの方向性を決めているのが彼だと言い切っても間違いではないです。
BrianはOpenJDKでも、そのつどつどでドキュメントを書いていますし、InfoQなどにも記事を書いています。それだけでなく、メーリングリストでもたびたび投稿を行っており、他の開発者からの質問にも丁寧に答えています。
すごい忙しい人だと思うのですが、よくこれだけやるなぁと本当に頭が下がります。
John Rose
Brian GoetzがJava言語の人だとしたら、JVMの人といえばJohn Roseです。
John RoseはJavaOneのキーノートへの登壇こそないものの、JVMのセッションでおなじみです。
さくらばがJohnのことを知ったのは、JSR 292 Supporting Dynamically Typed Languages on the Java Platformのスペックリードとしてです。
JSR 292は新しいバイトコードであるinvokeDynamic、いわゆるindyを導入したプロジェクトです。indyはJVM上で動的型付け言語の実装を行いやすいように、実行時に実行するメソッドを動的に決定することのできるバイトコードです。
また、これに伴いDa Vinci Machine Project (Multi-Language VM)のプロジェクトリードにもなっています。
そして、これがJVMLSにつながるわけです。
現在はProject Panamaのプロジェクトリードにもなっています。
スペックリードたち
ほんとにJavaを作っている人たちをあげていくとキリがないのですが、その中から今活躍している4人を紹介します。
左上のPaul SandozはJVMからJavaの言語仕様まで広く活躍しています。
今のメインはProject PanamaのVector APIですね。
Project Panamaは大別して、2つのサブプロジェクトがあって、1つがPaulが主導しているVector API、他方が次に紹介するMaurizioが主導するForeign Function & Memory API (FFM)です。
JavaOneでも彼のセッションはおなじみで、柔らかい口調で、楽しくてしょうがない感じで話すのが印象的です。
左下のMaurizio Cimadamoreは前述したFFMを主導しています。
もともとコンパイラが得意で、javacにおけるラムダ式の部分はほとんど彼が書いたらしいです。これはOpenJDKのコミッターである @bitter_fox さんに聞いたので、たしかなはず。
他の開発者はMarkとかBrianというようにファーストネームで呼んでますけど、@bitter_foxさんがMaurizioさんといつも呼ぶので、なんとなくMaurizioさんと私もさんづけで呼ぶようになってしまいましたw
右上のRon PresslerはVirtual Threadを策定したProject Loomのプロジェクトリードです。
リードをするのはLoomがはじめてのはず。というか、それ以前に彼が何をやっていたのかさくらばはよく知らないのです。
Project Loomはもうそろそろ終わりが見えてきたので、次にRonが何をはじめるのか楽しみです。
ここまでの3人はどちらかというとJVM側の開発者でしたが、ライブラリを作っている人もいます。右下のStuart Marksもその1人。
彼もProject Lambdaなどのプロジェクトにも参画していましたが、今はコアライブラリチームの活動が主体のようです。特にコレクションフレームワークですね。
むきむきJavaでイシダさんがSequenced Collectionsについてプレゼンしてくれたのですが、そのSequenced CollectionsのJEPを書いたのも、プルリクしたのもStuartでした。
ところで、上の写真でStuartが白衣に聴診器をつけてます。これは、2016年のJavaOneのコミュニティキーノートでSteven Chinの企画で寸劇をしたのですが、その時にDr. Deprecatorという役でStuartが演じたものでした。
彼はこれが気に入ってしまったようで、毎年Dr. DeprecatorとしてJavaOneに登場してます。
Javaコミュニティ
ここで紹介する3人は、マネージメント側の人たち。特にJavaコミュニティに関わる人たちです。
3人とも同じTシャツを着ているのは、2022年のJavaOneのキーノートセッションで撮ったからです。
一番左側のGeorges SaabはJava Platform Groupの上級副社長です。そして、JavaOneのキーノートといえばGeorgesです。
Georgesは元々は開発者でJavaのGUIであるAWTを作っていました。
その後、BEAに転職して、そのBEAがOracleに買収されて、Oracleに戻ってきました。Oracleに戻ってきた時にはBEAのJRockit担当の副社長だったのですが、今ではJava全般を担当しています。
真ん中のChad Arimuraも副社長で、Javaのデベロッパーリレーション担当です。Java Championの事務局も彼に担当していただいてます。
彼も元々開発者で、サーバーレスのFn Projectなどを作っていました。
Arimuraという名字でお分かりのように日系の方なのですが、日本語は全然喋れないです。
そういえば、2019年に東京で開催されたOracle Codeで @bitter_fox さんと私でVector APIとVirtual Thread (当時はFiber)のデモをキーノートセッションで行いました。この無茶ぶりをしてきたのが、Chadですww
右側のSharat Chanderは肩書はプロダクトマネージャーですが、Sunの頃からJavaOneなどのイベントの取りまとめなどJavaコミュニティに関する業務を一手に引き受けている感じです。
2015年からはJavaOne (or Code One)のMCも彼が担当してますね。
X (元Twitter)でも、Javaに関するツィートをいっぱいしてます(それ以外のツィートも多いですけどw)。
Duke
最後に忘れてはならないのが、Dukeです！
言語でマスコットを使ったのはJavaのDukeがはじめてだと思います(さくらばが他を知らないだけかもしれませんが...)
前回のJames Goslingの説明で、Javaは元々情報家電向けのOakという言語だったことを書きました。このOak時代に、プロトタイプとしてStar 7というタブレットの分厚いののようなマシンを作成していました。
下の写真はComputer History Museumで展示されていた、Star 7 (* 7)です。
このStar 7で、動いていたのがDukeです！この時から側転してましたww
つまり、Dukeの方がJavaよりも古くから存在するわけです。DukeのデザインをしたのがJoe Parlang。彼はのちにシュレックなどにも参画しています。
この当時は、Dukeには特に名前はなく、その形状からFang (牙)と呼ばれていました。しかし、当時のマーケの人が、「Fangなんてかわいそうな名前ではなくて、Dukeにしましょう！」と言ったとか言わないとか...
JDK 1.0のアルファ版からサンプルとしてDukeが側転するアプレットが含まれていたので、Javaを触る人は誰もがDukeを目にしていたわけです。
時代が変わって、JavaがOpenJDKでオープンソース化された時、Dukeもオープンソース化されました。JavaのライセンスはGPL Classpath Exceptionですが、DukeはBSDライセンスです。したがって、改変することも自由、商用利用も可能です。
ちなみに、Dukeはコミックにもなっていて、JavaOneで配布していました。そのコミックは The Amazing Adventures of Duke で読めます。
むきむきJavaではDukeを使ったものとして、下の4つの写真を紹介しました。
まずはやっぱりぬいぐるみ。
さくらばも各種Dukeのぬいぐるみ持ってます。ハンドパペットも持っていたりしてw
左下のDukeおにぎりはもちろん日本のものです。最古のDukeおにぎりは日本ではじめて横浜で開催されたJavaOneの時だと記憶しているのですが、もしかしたら違うかもしれません。
この時の企画は、当時SunのIさんでしたね。
その後、日本のJavaのイベントではDukeおにぎりはおなじみになってます。上の写真のDukeおにぎりは造形がイマイチですけどw
右上のギターのような楽器はウクレレです。Dukeleleといいます。
これも日本の企画でした。
Java 10周年の年である2005年に東京でJava Computing 2005 Springというイベントが開催されました。この時に、前述のIさんが記念になるノベルティを企画していたのです。
その当時、Javaで書かれた3DのウィンドウシステムであるProject Looking Glass (LG3D)が話題になっていました。
作者の川原さんはウクレレが好きで、登壇する時もウクレレを持ちながら登壇していました。また、LG3Dのコミュニティにやはりウクレレが好きなKさんが、三角形のFlukeというウクレレを見つけてきて、これだったらDukeになるんじゃないかとIさんに提案したのです。
そこからとんとん拍子に話が進んでDukeleleが誕生したわけです。
私がサムネイルに使っている写真で手に抱えているのがDukeleleです。
DukeleleはアメリカのJavaOneでも販売されたのですが、2005年と2006年だけ。持っている人はかなりレアですよ。
右下のずんぐりしたDukeは、Javaの20周年のパーティーを東京で行った時のDukeケーキです。このためにだけ、寺田さんが特注オーダーで作ってもらったものです。
この形にするために、かなりずっしりとしたケーキで、外側はマジパンで成形されてます。ちゃんと食べられるんですよ、このケーキw
これ以外にもいろいろなノベルティなどにDukeは使われていますね。
最後のDuke's Choice Awardというのは、毎年JavaOneでその年にJavaで作られた製品やサービスを表彰するというものです。
日本からもDuke's Choice Awardを受賞しています。たとえば、古くはNTTドコモのi-Modeなんてのも受賞していました。さくらばの友人だと、九州大学(当時は九州工業大学)の小出先生(2005年)や、サムライズムの山本ユースケさん(2019年)が受賞しています。
この他にも、AlanやAlex, Joe, Michael, Charlie、佐藤さんと、あげていけばキリがありません。そうそう、日本でJDKを作っているDavidも！
普段はJavaを作っている人たちはあまり表には出てきませんが、このエントリーで少しでも親しみを持っていただければと思います。
むきむきJava ふりかえり
最後にちょっとだけむきむきJavaの感想など。
ほぼはじめてだと思われる3人のプレゼンを聞いたのですが、はじめてだとしたら、まぁよかったのではないでしょうか。
JJUGのLT大会でShiryuさんが伝えることが多すぎて失敗したと嘆いていましたし、司会の cero_t さんからはメッセージは1つに絞った方がいいよとアドバイスもらっていたので、それ以外の視点で1つだけコメントしておきます。
Shiryuさんと、Kageiさん、イシダさんの3人のうち、一番わかりやすいと感じたのはイシダさんのSequenced Collectionsの話でした。
では、イシダさんと他の2人はどこに違いがあったのでしょう。
それは、ShiryuさんとKageiさんは自分が分かっていることを知らない人に説明したのに対し、イシダさんは自分の知らないことを調べてそれを知らない人に説明したという点です。
これはベテランの人でもやりがちなのですが、自分が分かっている分野だと、無意識のうちにその分野の言葉を使ってしまうのです。
もちろん、聞いている方はその分野は知らない世界なので、言葉も分かりません。そのためにプレゼンの理解が妨げられてしまうわけです。
プレゼンのターゲットが異なれば、言葉も変えていかなくてはならないのですが、普段、普通に使っている言葉だと、その言葉が相手に通じるかどうかすら考えなくなってしまうのです。
専門用語であれば「これは通じるかな？」と考えるかもしれないですけど、意識せずに使っているその世界の言葉はなかなか気づきにくいです。
以前、知人と雑談していた時に、家電の設定の初期値のことをデフォルトと言った時にまったく通じなかったことがあります。デフォルトってプログラムを書いている人であれば当たり前のように使っている言葉ですけど、この業界以外では通じない言葉です。
しかも、その知人は保険屋さんだったので、デフォルトがまったく違う意味で使われており、家電に対して使うという意味が分からなかったらしいです。金融系であれば、デフォルトは債務不履行のことなので、私たちが使う意味とは全然違いますよね。
これに対し、イシダさんは自分が知らないことを調べてプレゼンしたので、知らない世界の言葉は使わずに (というか使えなかったのだとは思いますが)、自分の言葉で説明しようとしていました。
ここが聞く側の分かりやすさの違いになっていたと思います。
プレゼンするときは、ターゲットによって言葉を変える。そして、説明する言葉が相手に理解できるかどうかを考えるというのが重要になってきます。
この点に気をつければ、次のプレゼンはもっとよくなると思いますよ。
