Ben Evans 氏、『The Cultivation of Java Programmers』の著者: 保守的な設計思考は Java の最大の利点です

Ben Evans は jClarity の共同創設者です。彼の会社は、開発チームと運用チームを支援するパフォーマンス ツールとサービスを開発しています。彼は LJC (London Java User Group) の主催者の 1 人であり、JCP (Java Community Process) の実行委員会のメンバーでもあり、Java エコシステムにおけるいくつかの標準の定義に貢献しています。彼は「Java Champion」の栄誉も受賞しています。彼は、『The Well-Grounded Java Developer』および『Java Authoritative Technical Manual (6th Edition)』(Java in a Nutshell) を共著しています。彼は、Java プラットフォーム、パフォーマンス、同時実行性、および関連トピックについて数多くの講義を行ってきました。

質問: 「Java in a Nutshell」は古典ですが、その最終版 (第 5 版) は 1,200 ページあり、10 年後に第 3 版が中国で出版されます。第 6 版はわずか 400 ページです。 2 つのエディションの間にはどのような変更がありますか?この 10 年は Java にとって何を意味しますか?

『Java Definitive Technical Manual』の初版は、Java が普及した直後に出版されました。当時、人々は Java について想像力に満ちていました。その後 5 回の版を重ねるうちに、この本のサイズと内容は大きくなっていきました。したがって、いくつかのバージョン間には進化的な関係があるため、各巻の焦点はある程度歴史的なものになります。これはいくつかの要因の結果です。理由の 1 つは、単純に、以前のバージョンと比較してこのバージョンに何が追加されたか、何が削除されたかを把握するだけで済むからです。しかし、もっと重要なことは、初期の頃、ほとんどの企業では Java のライフサイクルが長かったため、非常に古いバージョンの Java が頻繁に見られたことです。したがって、異なるバージョン間の違いを理解することが重要になります。したがって、特定の会社で特定の Java バージョンに取り組む場合、そのバージョンがわかれば、何ができて何ができないのか、またこのバージョンが他のバージョンと比べてどのような変更点があるのか​​もわかります。

新しい版を書き始めるときに、まず変えたいのはこれです。なぜなら、最新バージョンの Java 8 のライフサイクル (この時点で混同されやすいため、「Java Authoritative Technical Manual」の第 6 版では Java の第 8 版について説明しています) が以前よりもはるかに短いからです。もちろん、これは特定のドメインによって異なりますが、一般的な使用法を見ると、古いバージョン (Java 6 など) はごく少数の人だけが使用していることがわかります。もちろん、まだ 6 より前のバージョンを使用しているおかしな人もいますし、ほとんどのユーザーはバージョン 7 を使用しています。現在、バージョン 8 は非常に速いスピードで市場を占めており、わずか半年で 15% ～ 20% のユーザーがすでに Java 8 を使用しています。したがって、新しいバージョンの「Java 権威技術マニュアル」では、Java の外の世界にも焦点を当て、現在と将来についても議論します。

2 番目の重要な変更は長さです。あなたが言ったように、第 5 版は 1200 ページの長さですが、第 6 版はその 3 分の 1 に過ぎません。コンテンツの 3 分の 2 を削除します。第 5 版を読んだことがある方は、Java の主な内容に加えて、この本の第 2 部ではインデックスについても説明していることをご存知でしょう。もちろん、これには歴史的な理由もあります。Java が最初に登場したとき、インターネットの使用はそれほど一般的ではなかったので、この本に独自の索引があるのは非常に合理的です。しかし、他にも 2 つの理由があります。「決定版 Java テクニカル マニュアル」の最初の章では、Java バージョンの進化について説明し、Java プラットフォームの急速な成長について指摘しました。 Java 5 プラットフォームの基礎知識を説明するには 800 ページかかりました。Java 8 についても同じ方法で説明すると、天井まで届くほどの本になります。この方法が実現不可能であることは明らかです。もう 1 つの理由 (おそらくこれら 2 つは関連しています) は、人々の技術情報の利用方法が変化し、インターネットがどこにでも普及し、人々は重い本を持ち歩きたがらず、すべての索引が PDF や Web サイトなどでオンラインで検索できるようになったことです。リソースで。したがって、現時点で紙の本の巻末に分厚い索引を付けるのは無理がある。これは、「Java Definitive Technical Manual」の 2 つのバージョン間の大きな変更点です。

私が試みる 3 番目のことは、Java の変化する傾向とパターンを捉えることです。そのため、過去の Java の使用方法に関する多くの内容は削除され、読者がガベージ コレクション、メモリ割り当て、同時プログラミングについて理解する必要がある、より現代的な使用方法を追加しました。オリジナルバージョンはオリジナルのコンテンツを維持することに重点を置いていたため、多くの作業が必要でした。第 5 版に残った 3 分の 1 の内容のうち、第 6 版には 25 ～ 30 ％ しか残されておらず、残りの約 70 ％ は完全に新たに編集されたものです。 。

この本は Java 8 が実用化されるときに出版したいと考えていたため、Java 8 が登場する前に書き始めましたが、その後、当初予想していなかった作業がいくつか登場しました (Java 8 の隠し機能など)。しかし、今回はより多くの経験があるため、Java 9 がリリースされる 2016 年 4 月には次のバージョンを完成させたいと考えています。実は、具体的な計画を立てていたんです。

質問: 「The Well-Grounded Java Developer」の次の計画はありますか?

このプロジェクト「Java プログラマーとしての育て方」は非常に優れており、執筆プロセスも非常に楽しかったです。しかし、「The Definitive Technical Manual of Java」を書く過程で多くのエネルギーを費やしたので、おそらくこの本の第 2 版は書かないと思います。この本の初版発行者であるマニング氏と話をしましたが、最新の動向については承知していないため、この本の第 2 版は出版されない可能性が非常に高いです。

質問: Java エキスパートと普通の Java プログラマーの違いは何ですか?

プログラマーのレベルはピラミッドで見ると大きく3つのレベルに分かれると思います。最下位のプログラマーは非常に勤勉ですが、プログラミング自体にはあまり興味がないかもしれません。彼らも良い仕事はできますが、仕事を終えた後はプログラミングのことを考えません。これは通常の現象であり、ソフトウェア業界では多くのプログラマーが必要であり、この需要は依然として増加しています。中級レベルのプログラマーは、より多くのことをやりたいと考えており、テクノロジー ニュースや Web サイトのニュースを読み、次のバージョンの進捗状況を追い、自分のスキルを気にしており、このレベルのプログラマーは非常に興味深いです。トップのプログラマーは常に職人技とテクノロジーの性質に魅了されています。このピラミッドの頂点に達すると、自分自身から学び、技術をより深く理解するフィードバック ループが始まります。しかし、最も難しいのは、2 レベルからトップまでどうやって突破するかだと思います。自分の仕事以外の知識に少しでも興味がある場合は、自分のポイントを探す必要があります。この点は人によって異なります。一度、興味を惹かれた分野を見つけたら、その好奇心に従って深く勉強することができます。 。

オープンソース ソフトウェアについては、優れたオープンソース開発者は自分自身の問題点を見つけ、その問題を解決しなければならないという格言があります。これが、ほとんどの人がオープンソース ソフトウェアに興味を持ち、多くの人が Java 開発者と呼ばれる理由です。興味のある点を見つけて、理由が分からないから学び続ける、それが成長の秘訣です。

質問: Lambda が Java 8 に追加されましたが、開発者の間では Java 構文が冗長すぎるという不満が常にあります。これが、多くの開発者やチームが Java の使用に消極的である主な理由だと思いますか?

私はそうは思わない。 James Gosling は、Java の言語設計と、なぜ Java が現在のようになっているかを説明する 3 つの文章を書いています。最初の文は、英語で「ブルーカラー」と呼ばれる言語です。ブルーカラー労働者は第一線の仕事に従事する人々であり、ホワイトカラーはオフィスや管理者の仕事を表します。 Java は、現役プログラマーが実際の問題を解決できるように設計されたブルーカラー言語です。 Java は、現実世界のビジネス上の問題を解決する実用的な言語です。

James Gosling 氏は、2014 年の JavaOne カンファレンスで、Lambda と Java の初期バージョンには登場しなかったいくつかの設計について語りました。「何かを行うための正しい方法が見つからない場合、私は何もしません。」この文は、ゆっくりとした保守的な進化設計哲学を表現しています。Java とは何かを理解したい場合は、これを理解する必要があります。多くの人は Java は古いのでプログラミング言語を変える必要があると考えていますが、彼らが理解していないのは、本当の変化は自分たち自身であるということです。彼らは自分の能力を発達させ、より遠く、より深くを見たいと考えており、言語はそれを反映しています。言語を変える必要があるということではなく、このアイデアを思いついたプログラマー自体が変わったということです。 Java はこれまでも、そしてこれからも保守的に設計された言語です。これは Java の大きな利点でもあります。

James が Java を設計する当初の意図を説明したとき、次のように言いました。「私が設計していたとき、人々が自動メモリ管理を望んでおり、強力な型付けを望んでいることはわかっていましたが、これらの機能はブルーカラーの労働者を怖がらせるでしょう。」たとえば、Smalltalk は優れた言語ですが、高度すぎて、開発者がアプリケーションを構築する際の実際の考え方から乖離しています。そこで、Java はこれらのアイデアの一部を継承し、簡略化して、言語と形式にまとめました。これらのことが、この言語の設計の基本的な動機を説明しています。

確かに Java は冗長な言語だと言えますが、余分な内容は読みやすさのためだと思います。特にあなたが初級または中級のプログラマーである場合、これらの一見冗長な単語が役に立つことがあります。生産性に対する要求がますます高くなっているにもかかわらず、コードは依然として書かれていることを人々は常に覚えているでしょう。したがって、Java が冗長であるとは思いません。高度な機能を追加することはできますが、言語内で決して変更できないものもあります。これは残念です。もちろん進歩はしますが、私がいつも言っているように、人々は言語で何が達成できるかよりも文法を常に気にしすぎます。

質問: 現在、多くの大企業 (Paypal など) が Java から Node.js に切り替えていますが、Java と Node.js がそれぞれ得意とする分野は何ですか?

この質問には誤解があります。実際、企業が Java を放棄して Node.js に切り替える大きな波はありません。 Paypal の Node.js 対応部分は小さく、Paypal の実行コードの大部分は依然として Java です。 Node.js はパイロット プロジェクトに参加していますが、これは理解できます。Node.js はいくつかの興味深いアイデアを備えた興味深い環境です。 Node.js は非常に若いですが、同時に多くの深刻な問題を抱えているため、Node の将来の発展を予測するのは時期尚早です。したがって、さまざまな開発者の Web サイトで Node を支持する声がたくさんあり、GitHub には興味深いプロジェクト (Ardruino を書くために Node を使用する、ハードウェアで遊ぶなど) がたくさんありますが、実稼働環境のすべての製品の中で Java が優れた機能を備えていることは疑いの余地がありません。コードのほとんどの行。企業は正当な理由がなければ稼働中のソフトウェアを放棄しません。Node.js を使用している起業家はたくさんいますが、起業家はすぐに現れては去っていきます。

近年の面白いプロダクトの一つであるTwitterですが、その開発を観察してみると、当初はRuby on Railsを使っていたことがわかります。 3、4 年前、非常にかわいい漫画のキャラクター「Fail Whale」がウェブサイトに登場し始めました。それは恥ずかしいことであり、何が起こっているのかを解明するために彼らは多くの調査を行いましたが、Ruby のガベージ コレクションを調べた結果、何もできることがないことがわかりました。同時に、Java パイロット プロジェクトは成功し、Java がスケーラビリティの問題を解決できることに気づきました。その後 18 か月にわたって、一部の JRuby をステージング グラウンドとして使用し、システム全体を Java に書き直しました。最終的な効果も非常に優れており、Java を中心とした新しいサービスと新しいアーキテクチャが導入されました。かつて、Ruby はエンタープライズ ソフトウェアの未来とみなされていましたが、現在では、Ruby は数多くあるプログラミング言語の中の 1 つにすぎません。現在最も広く使用されている言語は Java、JavaScript、C/C++ の 3 つですが、JavaScript コードのほとんどはクライアント側にあります。これら 3 つの言語が削除されると、他の言語の市場シェアは失われます。非常に少ない。

質問: これまで、Java アプリケーションの仮想ホスティング モデルでは、個別の JVM インスタンスをホストするために x86 仮想マシン全体を割り当てる必要がありました。相対的に言えば、インスタンスは個別の Java アプリケーションもホストします。この方法は非常に非効率ですが、Java はマルチテナント仮想化とクラウド コンピューティング構成をネイティブにサポートしていません。幸いなことに、クラウド コンピューティングの問題を解決するためのマルチテナント Java ソリューションがコミュニティで見つかります。どのソリューションが実稼働環境に適用できるほど成熟していると思いますか?

ここには 2 つのことが関係しており、仮想化とクラウドおよびマルチテナントを混合することは完全に正しいわけではありません。たとえば、QCon Shanghai では、docker (docker は仮想化に依存しないプラットフォームです) に関する多くの共有があり、その素晴らしい共有の 1 つが Chris Swan によるものでした。彼は、CPU メモリを仮想環境から Docker ベースの環境に移行する利点を示しました。これはまだ完全ではありませんが、Docker 上で Java を実行するだけですでに実感できるでしょう。クラウドと仮想性の関係を明確に整理する必要があります。さらに、複数の JVM ホストを設定できるなど、他にもできることはたくさんあります。

しかし、この質問が本当に求めているのは、マルチテナントです。この問題に関して、私の中でチャンピオンに値する製品が 1 つあります。それが Waratek です。 Waratek は、別個の非ホットスポット JVM を分離し、その中でホスト JVM を実行できます。Java 仮想マルチテナント JVC は JVM 内で実行され、JVC は非常に軽量になります。 Waratek は、実用化できる非常に成熟した製品だと思います。ドイツ銀行が最初に動作する JVM を Waratek に移行すると発表したばかりなので、一度検討してみる価値はあると思います。 。

質問: Java はよく Scala と比較されますが、これら 2 つの言語の設計目的の違いは何ですか?将来的に 2 つの言語がまったく同じ方向に発展する可能性はありますか?

JavaとScalaは全く異なる言語です。以前に Java の設計哲学について話しましたが、今度は Scala の設計哲学とそれらの違いについて話しましょう。 Scala は元々、Martin Odersky によって作成された言語で、Pizza と呼ばれていました。この時点で、Pizza は Java パラダイムに似たいくつかの機能を徐々に追加し始めました。 Pizza の機能の一部はパラダイムとして機能します。

Martinはとても賢い人で、Scalaも素晴らしいデザインをたくさん持っています。しかし同時に、この言語には独自の問題もあります。それは「キッチンシンク」言語と呼ばれることもありますが、これは人々がこの言語に対して愛憎の関係を持っていることを示しています。この比喩の意味は、「シンクにはさまざまなものが過剰にある」ということです。これは本当に Scala の問題です。Scala には機能が多すぎます。言語設計には保守主義というルールがあり、これは Java 設計プロセスにおける重要な原則でもあります。具体的には、新しい機能を追加するたびに (具体的な例は『Java プログラマーの育成』の 14 ページで説明されています)、新しい問題が発生する可能性もあります。あなたの言語に 200 の機能があり、さらに 1 つ追加したい場合は、他のすべての機能とどのように相互作用するかを確認する必要があります。 Scala は常に新しい機能を追加しています。これらの機能がどのように相互作用するかを知るのは困難です。 Scala には変化を受け入れることができる非常に柔軟なコミュニティがありますが、言語機能の変更は簡単ではありません。したがって、Scala には優れたパフォーマンスが数多くありますが、どの機能が必要でどの機能には触れられないかを決める必要があることがわかります。チームでプログラミングする場合、これは問題になりません。本当の問題は、現代社会のソフトウェア スタックがコードだけに依存していないということです。問題は関数ライブラリに起因しています。 Scala の機能の中には、そのアクションがターゲット オブジェクトだけでなく他のものにも影響を与えるものがあります。 Scala の機能が増えるほど、これらの問題が重なりやすくなります。

さらに、彼らはバイナリ互換性の問題に常に苦労しています。 Java、Sun、Oracle は、これが Java の最も重要な設計概念であると常に信じてきました。そのため、Java 1.0 でプログラムを作成し、コンパイルして、Java 8 仮想マシンに配置しても実行できます。実行速度は以前よりも速くなります。以前よりも何倍も速くなります。 Scala はこの点について約束したことはなく、以前のバージョンでも問題が発生します。ライブラリ分野では、この問題はさらに深刻です。ライブラリをアップグレードするたびにシステム全体がクラッシュするため、多くのプロジェクトが Scala を放棄したことを私は知っています。

つまり、これら 2 つの言語の設計思想は大きく異なります。人は常に新しいものが好きで、最初にそれを試す人が多くの恩恵を最初に享受することになりますが、多くの場合、人は 2 番目に試す人を好みます。初めての人が間違いを犯すのを見て、そこから学ぶことができます。そして Java は、他の人の間違いから学ぶ言語です。先ほどプログラマのピラミッドについて触れましたが、Scala は最下層のプログラマの思考を刺激するのが役割だと思います。 Java はピラミッド全体に適用される言語であり、特に低レベルおよび中レベルのプログラマに適しています。私は今後何年にもわたって強力で健全な Scala コミュニティが存在すると信じており、彼らとアイデアを交換したいと考えています。しかし、私は Scala がニッチ言語からマス言語に成長するとは思いません。現在、地球上には Scala プログラマーが何百人もいるかもしれませんが、この数は Java プログラマーのせいぜい 1% であり、この比率は今後も増加しない可能性があります。