Java 30周年 - 技術を変えたコードの天才、ジェームズ・ゴスリン インタビュー

• ジェームズ・ゴスリンはJavaの創始者であり、30年にわたり現代コンピューティングに影響を与えてきた実践的な天才と評価されている
• 貧しい環境の中でごみの山の部品を使ってコンピュータを組み立てながらプログラミングを学び、この自己主導型の学習は後の言語設計哲学にも反映された
• Sun Microsystemsでのいたずらと革新が共存していた時代は、ゴスリン特有の創造性と技術文化づくりの基盤になった
• 最近、彼は生成AIツールとAIブームについて強い懐疑を示し、プログラミング教育の重要性はむしろ高まっていると強調した
• Javaの生存の秘訣は派手さではなく、安定性、後方互換性、開発者生産性を徹底して志向した実用主義的な設計哲学にあった

---

Java at 30: The Genius Behind the Code That Changed Tech

• Javaは5月23日で30周年を迎える汎用高水準オブジェクト指向言語であり、現在でもさまざまな規模のシステムを動かす中核技術である
• Javaが存在し得た根底には、ジェームズ・ゴスリンの実践的な技術感覚と創造的な直感力がある
• ゴスリンは、ごみ箱から部品を集めてコンピュータを組み立てていたカナダ出身の自立心の強い10代の少年から出発し、世界的プログラマーへと成長した
• 「一度書けばどこでも動く」という哲学はJavaの象徴であり、それはすなわちソフトウェア開発のあり方に根本的な転換をもたらした言語哲学へとつながった
• ゴスリンはキャリアを通じて技術的卓越性、遊び心、そして明確な倫理観を調和させながら、現代コンピューティング文化の形成に継続的な影響を与えた開発者像を体現してきた

James Gosling: The Brilliant Mind Behind Java

• ジェームズ・ゴスリンは単なる「Javaの父」ではなく、複雑な概念を直感的に説明できる謙虚な天才である
• Javaを生み出してから30年が過ぎた今、彼は技術の歩みを振り返りながら、言語と開発文化の進化の過程をたどった

The Path To Programming: Resourceful Beginnings

• 幼少期、極度に貧しい環境の中でゴスリンは、ごみ箱からテレビを拾って技術的創造力を育んだ経験を持つ
• 最初のコンピュータは電話局の廃棄リレーラックを組み合わせて作られ、これは早い時期から現れていた機械的センスと組み立て能力を象徴している
• カルガリー大学のコンピュータセンターを訪れ、画面、点滅するランプ、テープ装置などに魅了されたことから、プログラミングへの生涯にわたる好奇心が始まった
• 彼はパンチカードをあさってパスワードを得る形で独学し、高校生の頃には大学の物理学科で衛星データ分析プログラムを作って報酬を得ながらプログラミングを楽しんだ経験を積んだ
• 彼の初期のプログラミング経験は、IBMメインフレームのPL/1、Fortran、PDP-8アセンブリ言語、CDC 6400のコードにまで及ぶ。独特の抑制された口調で「夏にはCOBOLコンパイラを開発するアルバイトをした」と軽く語っていたが、これは多くの熟練プログラマーでも手に負えない仕事だった

Academia to Industry: Finding His Way

• ゴスリンは学界を「大学院生を安価な労働力として使う研究所」と表現し、理論より実用を重視する率直な視点を示した
• カーネギーメロン大学の博士課程在籍中にもスタートアップで働いて実務経験を積み、その後学位課程を終えるという産業界と学界を並行した柔軟な進路選択を実現した
• 最初の職場はIBM Researchだったが、「自分の足を撃つことに献身的な会社」と評し、企業運営と技術戦略に対する冷徹な分析姿勢を保っていた
• こうした初期経験は、その後のSun Microsystemsでの活動様式に影響を与えた現実重視の組織文化理解の基盤となった

The Sun Days: Innovation and Pranks

• Sunで最も楽しかった思い出として、ゴスリンは毎年行われた大規模なエイプリルフールいたずらプロジェクトを挙げ、創造性と愉快さが共存していた組織文化を回想した
• 代表的ないたずらの例としては、池の上のプラットフォームにフェラーリを浮かべるというものがあり、これは工学的な問題解決力とチームワークを活かしたユーモア感覚を示す事例だった
• CEOのオフィスに人工芝、バンカー、ウォーターハザードを備えた1ホールのゴルフ場を作ったいたずらは、技術と遊びが結びついた独創的な試みとして言及されている
• ゴスリンはSunを「技術的卓越性といたずらっぽい創造性が同時に許容される珍しい環境」と記憶しており、これは彼の全般的な問題解決の方法と技術に対する姿勢形成の土台になった

Java: Creating a Legacy That Changed Everything

• Java30年の歩みは、ゴスリンにとって最も代表的な成果であり、技術人生の決定的な転換点である
• 街中で「Javaのおかげでキャリアを得られた」と声をかけられるたびに感じる、開発者エコシステムに残した影響への深い満足感が語られている
• ラムダやジェネリクスのような機能は最初から入れたかったが、「間違ったやり方では入れない」という設計哲学に従って導入時期を調整した
• OracleによるJava運営については「期待していたよりうまくやった」と評価し、実際にはコミュニティの継続的な参加と貢献が中核的な役割を果たしたことを強調した
• Javaはクラウド環境に最適化されながら進化してきており、マルチコア対応、メモリ処理、GC改善などで**「本当にすばらしい水準」と言える技術的完成度**に達している

Beyond Java: Ventures After Sun

• SunがOracleに買収された後、ゴスリンはしばらく休養を取ってからGoogleに入社したが、6か月で退職してLiquid Roboticsへ移った
• そこで自律型海洋ロボットの制御システムを開発し、ハワイでシュノーケリングが必要な業務環境など、技術と自然が結びついた独特の勤務条件を経験した
• 北極と南極の海洋温度をモニタリングするプロジェクトにも参加したが、環境研究は資金不足で、VC主導のスタートアップ構造との衝突を経験した
• 国防分野への転換圧力が強まると、倫理的理由から退職し、AWSでGreengrassプロジェクトや開発ツール関連の仕事に参加しながら、技術的関心と倫理基準の両方を考慮したキャリア選択を続けた

On Open Source and Industry Trends: Cutting Through the Hype

• オープンソースは単なる協業ツールを超え、デベロッパーリレーション、マーケティング戦略、ボトムアップ導入モデルとして機能する複合的なエコシステムとして説明されている
• ローコード・ノーコードのトレンドについてはCOBOL時代から繰り返されてきた主張だとして、複雑なドメインに適用する際には限界を持つ特化型アプローチだという懐疑的な立場を示した
• AIと機械学習は技術より名称が問題だとして、「高度な統計手法」という表現のほうが本質に近いという用語批判を展開した
• AIはあくまでツールであり自律的存在と誤解されるべきではなく、人間の労働を脅かすより補助する高次のツールとして見るべきだという立場を明らかにした

Developer Tools and Preferences: Embracing Progress

• ゴスリンはNetBeans IDEを主な開発ツールとして使っており、Apacheライセンスベースのオープンソースと活発なコミュニティへの支持を示している
• いまだにViや70〜80年代のツールに固執する開発者に対しては、技術進歩を拒む姿勢への残念さをにじませた
• Viはどこでも動くという理由でたまに使うが、本格的な開発環境では現代的なIDEの使用を強く支持している

The JVM Vision: From Academic Concept to Global Standard

• Java仮想マシン（JVM）の初期構想は、ゴスリンの大学院時代に考案されたアーキテクチャ中立な配布フォーマット実験と命令変換技術の研究に端を発している
• それは後にJavaだけでなく複数の言語がさまざまなハードウェア上で動作できる汎用実行プラットフォーム技術へと発展した
• 「Write once, run anywhere」の哲学は当初、博士論文の題材としては数学的基盤が不足しているとして退けられたが、世界のソフトウェア開発環境を変えた実用技術として定着した

More Recent Work: Bridging IoT Gaps at AWS

• ゴスリンはAWSでIoTアプリケーションフレームワークであるGreengrassの開発に参加し、複雑な問題をエレガントに単純化する技術アプローチを実装した
• OTAアップデート、遠隔制御、テレメトリ、ネットワーク信頼性、セキュリティ、認証管理など、配布と運用の間にある反復的なボイラープレート作業を抽象化した
• デバイス側コードはオープンソースとして公開され、RISC-VのようなAmazon非優先プラットフォームに対するコミュニティ主導の移植貢献を促した
• その後に参加した別の開発ツールプロジェクトはAIブームに巻き込まれて中断され、技術的誠実さより流行中心の混乱が生む問題を示唆している

AI Skepticism

• ゴスリンは最近のインタビューでAI革命について「ほとんどが詐欺だ」と表現し、AIを有害なマーケティング用語とみなす懐疑的視点を示した
• 数学的に印象的な技術であることは認めつつも、AIという名称が実際の技術的実体である高度な統計手法の本質をぼかしている問題を指摘した
• ベンチャーキャピタル主導のAI熱狂は「詐欺師と誇大宣伝屋の集結地」だとして、実際に役立つ技術よりイグジット重視の短期収益追求傾向を強く批判した
• AI投資の大半は結局「ブラックホールに吸い込まれるだろう」として、持続可能性のない流行主導の資金の流れへの警告を発した

Is It a Vibe? AI Coding Tools: Impressive Demos, Limited Utility

• 生成AIコードツールは第一印象こそ強烈だが、少し複雑になるだけで失敗する限界的な構造を持つ
• これらのツールは既存のコードサンプルをスクレイピングして反復できるだけであり、本当に興味深い問題は常に新しいため、複製ベースのツールとは相性が悪い
• 専門家向けの開発環境ではパターン化されたコードはライブラリへと収束するため、AIのコード生成は現実の開発要求と構造的に衝突する
• ゴスリンはAIの本当の有用性を、誰もやりたがらない文書化作業を代行する検索ツールだと定義し、APIの使い方説明に特化した補助ツールとしての価値を強調した

Java’s Evolution: Language Features and Runtime Improvements

• 最近のJava言語の変化のうち、型推論や配列宣言方式の改善などは開発の利便性を高めた有用な機能拡張と評価されている
• しかしゴスリンは、Javaの最も印象的な進歩はJVM実行環境と標準ライブラリの品質向上にあると強調する
• 最新のJVMはコード品質、スレッド性能、ガベージコレクションの面で**「驚異的な水準」に到達した実行性能**を見せている
• メモリ管理と性能予測可能性の面でmallocベースのC言語より効率的であり、GCの停止時間を数ミリ秒まで縮められる調整可能性にも言及した
• 現在のJVMは、途方もなく大きなメモリ空間も安定して扱える高性能ランタイム環境と評価されている

Programming Languages for Critical Infrastructure

• FAA航空管制システムをどの言語で書き直すべきかという問いに対し、ゴスリンは**「ハンマーを選びながら家を建てるようなものだ」として前提そのものを退けた**
• まず通信システム、国際規制、飛行経路や衝突回避など、問題ドメインの特性を明確に理解した上で技術を選ぶべきだと強調した
• ただし信頼性が重要な大規模システムでは、Javaが有力な候補になり得る可能性も付け加えた

The Future of Programming in an AI World

• AIが進歩してもプログラミングは依然として必須の技術であるとして、ゴスリンは子どもがいるなら必ずコーディングを教えるという立場を明らかにした
• AIが人間の開発者を置き換えるというビッグテック経営陣の主張は、労働強度を高めるための自己防衛的な脅しにすぎないと批判した
• システムを正しく理解するにはプログラミング能力が必要であり、機械が代替するとしても人間の技術的理解の基盤は維持されるべきだと主張した

Java’s Longevity Secret

• Javaが30年以上生き残れた理由として、ゴスリンは実際の問題解決力、ユーザー尊重、後方互換性、生産性向上、信頼性中心の哲学を挙げた
• 言語の流行より一貫した実用性を重視してきたこと、スタイルより結果に集中した現実志向の設計哲学がエンタープライズ環境で特に効果的だった
• ソフトウェアは「常に正しく動かなければならない」という観点から、Javaは誠実で実用的なエンジニアリングツールであり続けている

Oracle’s Stewardship: Better Than Expected

• ゴスリンはSun Microsystems買収後のOracleによるJava運営について、「思っていたよりはるかにうまくやった」と述べ、予想を上回る成果への驚きを示した
• 当初は過去の振る舞いから「略奪と収奪」を懸念していたが、実際にはJavaチームを妨げず守った点で、独立性と技術中心の運営を肯定的に評価した
• 財政支援は不足していたと指摘しつつも、企業の干渉なく技術チームの自律性が保たれた構造を高く評価した

Crab Lovers Unite!

• ゴスリンは一緒に食事をしたい人と働きたいと語っており、人を中心にした協業の基準を重視する姿勢を見せている
• 記者はサンフランシスコのカニ料理店Thanh Longで偶然ゴスリンと出会い、技術界の大物が平凡な日常の中で見つかる瞬間を記録した
• その後2人は一緒にカニ料理を食べながら会話を交わし、次も同じ場所で会おうと約束することで、技術を超えた人間的な交流の温かさを伝えている

[cosine20]

私も静的型付け言語の中では、Javaがいちばん気楽に使いやすい言語だと思います。

ただ、汎用的・実用的な開発という観点では、GUIのあるエンドユーザー向けアプリをJavaで書くのはあまり良い選択ではありませんでした。（その観点では C# + .NET の組み合わせがいちばんベストです）
Javaの長所を考えると、バックエンドやミドルウェア方面で使うのが、実用面では最も良いケースだと思います。

とにかく、たまに使う機会があって使うたびに気負わず扱える言語なので、良い経験のほうが多く残っている気がします。

[mhj5730]

ゴミ捨て場でTVを分解してプログラミングしていたという話、まさにレジェンドの始まりって感じですね。

[ndrgrd]

Java以降、言語が生産性に注目するようになったのは事実です。

その前によく使われていたC++は、今でも読むだけでぞっとします。特に長く続いたプロジェクトに手を入れるときはなおさらです。

[3ae3ae]

Javaが開発者の生産性を重視していたという話には、あまり同意できませんね。
JavaほどIDEに深く依存するように発展した言語が、ほかにあるでしょうか？

[3ae3ae]

軽率なコメントをしてしまいましたね

[sunrabbit]

IDEへの深い依存は、いびつに発展したJavaエコシステムの問題であって、
設計レベルの問題ではありません。

極端な言い方をすれば、今Javaを開発するのにあえてJetBrains製品を使わなくてもいいのに、
みんながそれを使っているようなものです。

そして、Javaが登場した当時のプログラミング言語の一覧を見ると、プラットフォーム依存、つまりOSに依存する実装が多い言語ばかりでした。
それに対して、同じコードでさまざまなOS上で動くNodeやPython、C#のような言語の志向を示したのがJavaだった、ということです。

現代では、同じコードでさまざまなOS上で動く互換性は当然の「常識」ですが。

[roxie]

> 率直に言って、今Javaを開発するのに、あえてJetBrains製品を使わなくてもいいですが

この部分は……ちょっと同意しにくいですね、しくしく……

[kwj9211]

今では少し当たり前になりましたが、
Javaが登場した当時は、マルチプラットフォームを安定して新たなビルドなしでサポートするというだけでも、生産性にかなり大きく貢献したのではないでしょうか

[angrycoder]

Java以前の言語と比べると、生産性が高いようにも思えます。

[ahwjdekf]

c++ > c# >= java

[cosine20]

C# >= Java > C++

[GN⁺]

Hacker Newsの意見

• Javaの性能は最高水準ではないが、C/C++に次ぐ3位クラスで悪くないという認識。Goよりも速く、PythonやRubyよりは10倍以上先行している点に満足している。Javaの文法は完璧ではないが、一貫していて予測可能な点が長所。IdeaやEclipseのようなツールを使えば生産性を心配しなくてよい環境がある。メモリ管理の方式はUnix哲学とは異なるが、理解すれば悪くない折衷案だと感じる。こうしたトレードオフで得られるのが速度とメモリ安全性であり、同時に動的呼び出しやhotswapなどの利点まで得られる実用性に満足
  • Java向けのIntelliJのようなツールは他言語と比べても群を抜いて優れた環境だと実感。Goコミュニティが並行データ構造コンテナの開発にあまり情熱的でない理由が気になる。Javaの並行コーディングは優れたコンテナを推奨する文化があってうらやましく、時々 java.util.concurrent や JCTools が恋しくなる
  • 大学を出たばかりの頃はJavaが万能だと思っていたが、実際にはJVMとJava App Serverのツール群が時代を先取りしていた要素だったと後で気づいた。言語そのものは、2006〜2007年に生産性が向上する前までは失望感があった。最近はJVMで動くJRuby、Clojure、Scala、Groovy、Kotlinなど他の言語に関心がある。その中でもJRubyは成熟した2つのエコシステムを使えるので興味深い。Project LoomによってJVMでRubyのFiberが使えるようになったのは双方にとって得であり、Charles Nutterの功績は過小評価されている
  • JavaはGoより速いと言われるが、実際にはGoの方が速かったり、2〜10倍少ないメモリで済む場合も多いので、同程度の水準だと思う。Goのvalue typeのおかげで最適化しやすい。Goを特に言及している点が印象的で、C#がJavaより速い点を踏まえると、Javaは3位ではなく5位くらいだと判断する
  • 最近Javaに導入されたsealed class、switch expression、Project Loom、recordsが既存の文法に自然に溶け込んでいる点を高く評価している。heap dumpアナライザーやGCアナライザーなど、Javaの診断ツールも最高水準だと感じる
  • 言語性能の順位は、何を含めて何と比較するかによって変わる点を指摘。提示されたベンチマークリンクを参照
• Java（JVM）は、しばらく評判のよい別の言語やエコシステムを使ってみた後で、むしろさらに高く評価するようになった経験がある。実際には「隣の芝生が青く見える錯覚」だったと感じることの繰り返しだった。Rustだけは本当に大きく進歩した言語だと感じられ、使う楽しさがあった。最近Javaがスタートアップで「クール」な言語として扱われなくなっているのは残念で、生産性の差もほとんどなくなったと思う
  • Rustを2か月間フルタイムで使ってみたが、少なくともサーバー開発ではJavaと比べて「喜び」があるという表現は理解できない。Rustはlifetimeの問題で驚かされ、生産性が落ちる瞬間があまりにも多い。型安全性の感覚は確かにあるが、全体として本当に楽しい経験だったとは言い難い
  • C#はJavaよりはるかに先を行っており、意味のある点で大きく差別化されている（たとえば、はるかにうまく実装されたジェネリクス、ずっと前から存在するvalue type、便利なFFIなど）。Unity以外ではあまり注目されておらず、Microsoftは昔、大衆的な認知の獲得に失敗したのだと思う
  • これはプロジェクトの規模が違うからだと思う。普通は10年物のJavaレガシー大規模プロジェクトから、「新しい」hello-worldレベルのプロジェクトに移れば、当然よく見える。大規模なリライトはセキュリティレビューにも良いが、たいていの企業にはそんな余裕はなく、Googleのような例外しかない
  • まったく同じ感想。Goには失望した。あらゆることを約束しながら、結局はJavaに似ているか、あるいはスタックトレースのないエラーなどの点でむしろ後退したように感じた
  • 約30年のキャリアの中盤に、JVM以外の言語でプロジェクトを試した2年間は、キャリアの中で最悪の時期だった
• James Goslingの功績に感謝している。Java World Tourをきっかけに「Java consultant」で検索すると最上位に出るようになり、リモート勤務で地方でも安定して生計を立てられた経験がある。Javaのおかげで人生に良い影響を受けた人は数え切れないほどいる。ClojureチームがJVMベースで素晴らしいエコシステムを築いた功績にも感嘆している
  • 自分もJames Goslingに感謝している。1995年にTaligentでC++の仕事をしていたとき、Javaを初めて使ってその新しさに感嘆した。その後Taligentが解体された後も、長くJavaと関連ソフトウェアに携わってきた
  • James Gosling（Java）とRich Hickey（Clojure）は、それぞれの時代にプログラミングの世界へ新鮮さを吹き込んだ創造者だと評価する
• ここ数年は.NET/C#で働いていたが、全体としてJVM/Javaは自分が経験した中で最高のエコシステムだと感じる。Javaの方が、うまく解決している部分がずっと多い。たとえばJavaはfork/join poolで作業分割を解決したが、.NETは単にグローバルスレッドプールにwork-stealingを入れたため、sync-over-asyncコードが全体のdeadlockを簡単に引き起こす問題がある。大規模コードベースでsyncコードを全面的にasyncへ変換しろというのは、実際には不可能に近い。Java側はライブラリ/フレームワークのレベルでミスをしても早く乗り越える一方、.NETは標準ライブラリ、言語、ランタイムで問題が起きると直しにくい。Javaは基準の置き方がうまい例が多い
  • .NETのthread pool starvationは非常に苛立たしく、最近は影響が減ったと聞く。thread poolの誤用に免疫を持つ実装は不可能だと思う。できるのはスレッドを増やすか、作業順序を賢く調整することくらい。自分はthread poolの専門家ではないので断言はできない
  • .NETはJavaエコシステムの成功したアプローチを模倣してきたのだと思っていたが、実際にはかなり違う点があることに注目
  • .NETコードをまったく書かずにdeadlock問題を持ち出すのは公平ではなく、13年前のブログを根拠にするのも説得力に欠けるという指摘
• Javaは偉大な成功例だという認識。ただしJames Goslingは出発点ではあったが、実質的なリーダーではなかった。Java 1.1〜1.2の時代からMark Reinholdが主導してJIT統合、HotSpot開発、1.2での大規模なクラス増加、Oracle買収後の動的言語サポート、オープンソース化、高速リリース、現代的な言語機能の基盤など数多くの革新を牽引してきた。Javaの強みはすべてMark Reinholdのリーダーシップによるものだと評価する
  • 主要開発チーム全体が印象的。Goslingは実用的な言語を望み、その後Mark ReinholdやBrian Goetzのような人々が開発者に優しい形で言語を進化させてきた。Oracleは好きではないが、優れたグループを前進させた点には感謝している
  • KotlinはJavaと同じく静的型付け言語であり、動的言語ではないと指摘
  • Linusがgitをたった2週間ハックして作り、火付け役になっただけだとしても、コミュニティが拡張したことを考えれば、出発点だけで評価するのは不完全だという意見
• 40代以上のソフトウェアエンジニアとして、現実的には「仕事がきちんと進む道具」を選ぶのが賢明だと判断している。今日ではJavaやC#がその役割を十分に果たしている。個人的にはC#の方がエコシステムがより統合されている印象がある。どんなユースケースでもC#なら1分でアプリを作れるし、言語の進化も速く、人材確保も安定している。.NETもクロスプラットフォームをサポートしており、言語そのものの優雅さと効率性のおかげで仕事が楽になる
• 大学でOSコードをJavaでシミュレーションした経験がある。抽象的なアルゴリズム学習にはJavaが複雑さを減らしてくれてよいこともあるとは理解するが、個人的にはPythonの方が適していただろうと思う。産業界の影響で大学の初学者教育に無条件でJavaを使い続けるのには賛成しにくい。高校ではすでにBASICやCに触れていたので、JavaでOSの低レベルコードをシミュレーションするのは一歩後退のように感じた
  • 大学ではCでマイクロコントローラ、Javaでデータ構造/OOP、CとMIPSアセンブリでシステム/OS/並行性の概念を学んだ経験がある。データ構造/アルゴリズムではPythonよりJavaの方が抽象型と構造を明確に区別でき、むしろ正確な概念を持つのによい。ただしOSの概念をJavaで教えるのは少しやりすぎだと感じる
  • Joelが述べたJava教育の欠点はPythonのような他の高水準言語にも当てはまると考えており、皮肉なことにMapReduce（GoogleがJavaで作った）がMicrosoftより先を行った事例を強調
• Javaの成功は認めるが、さまざまな理由で強い拒否感が残っている。主に大企業の冗長なコード、複雑なフレームワーク、質の低いコードの遺産のせいだ。コードが「石炭のように」量産され、情熱もなく没個性化していく文化が嫌だった。JVMは内部がブラックボックスで、strace や gdb のようなツールでデバッグしにくく、メモリの過剰割り当てでカーネルがワークロードを把握しづらかった。JVMを使うと、専門家の助けがなければ深刻な問題が起きるリスクも高いと感じた。さらにOracle、ライセンス、JDKバージョン管理、2025年時点での格好良さのなさ、レガシーコードに足を引っ張られる点なども残念だ。個人的にはJavaをできるだけ避けつつキャリアを積んできた。最近は運用上の複雑さが少ない静的コンパイルの高性能言語や小さな実行ファイルベースの言語が多く、JVMやPython VMのようなソリューションの役割も徐々に小さくなっている流れだと思う
  • JVMは世界最高水準のデバッグ、ホットリロード再開、変数変更、例外ブレークポイントなど、非常に強力な動的デバッグ機能を提供している。Idea/EclipseのようなIDEとの連携も他言語とは比べものにならない。JMX/JConsole、Java Flight Recorder、jstack、HPROFなど各種診断ツールも非常に豊富。ライセンスはオープンソースで利用制限はなく、Oracle JVMの購入は自由選択にすぎないと指摘。レガシーコード問題とは何なのかと問い返す
  • JAVAに「格好良さ」がないというのは説得力のない主張で、strace や gdb ではなくJDKツールやIDEの方が圧倒的に性能が良い
  • ツールは最初は見た目に難しそうでも、慣れるのは簡単。JVMのGCチューニングも1週間で専門家になれる。GCはアプリケーションの文脈でカーネルよりよいコンテキストを持って管理でき、実際の利点が大きい一方で、多少のプロビジョニングの複雑さは認める
  • 20年以上Javaを使ってきたが、strace や gdb が必要になったことは一度もなく、デバッグ/IDE支援は非常に強力。性能面でPythonとJVMを同列に置くのは不適切
  • 実際にはJavaをあまり使っていないからこうした判断になったのだろうし、Javaのデバッグ/診断ツールが最高だという点を再確認
• GoslingがSunにいた頃、NeWSウィンドウシステムを共同設計していた事実。NeWSはPostscriptベースで、クライアントがサーバーにプログラムを送る構造だった。GoslingがJavaを設計した際、NeWSのようにWebページをプログラム可能なものとして捉えた痕跡が見える。実際、著者のサイン入りの『The Java Programming Language』に「JavaはNeWSへの復讐なのか」と尋ねたところ、Goslingは笑みで答えた
  • Xに対するWayland、NeWSに対するブラウザ+JavaScript（PWA、Electron）のように後継が現れた今、結局NeWS方式がMicrosoft環境でも勝利したように見え、Goslingがどう考えるか気になる
  • これに似たものとしてDisplay PostScriptがあった。SPARCStation+SPARCprinterの組み合わせでは、印刷ロジックがすべてサーバー側で処理され、サーバーかプリンターのどちらか一方が壊れるだけでシステム全体が麻痺した。プリントサーバーとプリンターの連携は悪夢で、結局プリンター不信だけが強まった経験がある。SunOSやSPARCエコシステムは懐かしいが、Display PostScriptだけはなくなってくれてよかった
• キャリアのかなりの期間をJVMでコーディングしてきた。最近はJavaの代わりにScala、Clojure（好み）、Kotlinなどを使っている。最近は失業後にPythonの仕事の提案を受けて引き受けた。JVM経験に対する需要が減っているのを感じる。とはいえ、給料さえ出るならどんな言語でも構わないという気持ちだ。現在の個人プロジェクトはScalaで進めている

[roxie]

途中にC#派が隠れていますね