ジョーカーが沈黙していること。 カンファレンスストーリー

10月15日、サンクトペテルブルクの栄光の街はジョーカー宇宙のスーパーヴィランが訪れました。

いいえ、彼は誰も殺しませんでした。バットマンは負傷しませんでした。 しかし、彼の訪問は多くの人に記憶されるでしょう。 まず、Javaテクノロジーに関する新しい会議の初演でした。 第二に、この会議は成功でした。つまり、大きな未来があり、最初の会議は常に歴史です。

楽しい驚き

私は会議で講演者として話をしました。主催者は2ヶ月前に私に連絡し、話すことを申し出ましたが、これは嬉しい驚きでした。 サンクトペテルブルクJUGのリーダー、アレクセイ・フェドロフ（@ 23derevo）、アンドレイ・ドミトリエフ（@real_ales）、イヴァン・ドルゴフ（@jetliner）（およびその他多くの支援者）によって組織されました。 アフターパーティーの1つで、アレクセイは会議の名前のアイデアがどのように彼に伝わったのかを語りました。「私は聞いた」と彼は言います、「プロコフィエフの3つのオレンジへのマリインスキー愛、それから長い間眠れなかった。 さまざまなキャラクターが頭の中で回転していました：スペードの王、クラブの王、道化。 そして、新しい会議のコンセプトの締め切りはすでに迫っています。 だから、トランプでなんとかして話題を打ち負かすというアイデアが生まれました。 Javaカンファレンスは通常Jという文字で呼ばれているため、ジョーカーという言葉はそれ自体が何らかの形で登場しました。」



さらに驚くべきことに、2か月で、彼らは非常にまともなプログラムを作成し、すべてのスピーカーと個別に作業し、あらゆる方法で実行し、支援しました。 しかし、プログラムにはいくつかの奇妙な点がありました。レポートの3つのタイトルは、「何が沈黙しているのか...」で始まりました。

どのように起こったのか、この話は沈黙している。

宿泊施設

私たちの会社Excelsiorの 2人が会議で話をしました：私とPavel Pavlov（@noinline）。 コンファレンスは、Pribaltiyskaya HotelのVasilievsky Islandで開催されました。 地下鉄を出て、ホテルまで歩いて行くことにしました。ピーターの夜を歩き回るのは良い考えのようです。 しかし、約10メートル後、ノボシビルスクの街に突然出くわしました。痛いほどよく知られているソビエトの建物と、ノボシビルスクとまったく同じ天気です。 要するに「3rd Street Builders」。



訪問者とオーガナイザーのほぼ全員が同じホテルに住んでおり、会議もホテルで開催されていたため、スリッパでレポートに行くことができました。 それはある種の奇跡でした。初めて出会ったのは、朝目を覚まし、朝食に行き、たくさんの親しい人に会い、昼食のために彼らを追い出し始めてから、2階に上がって、そして会議、そしてアフターパーティー、その後ホテルに戻り、アフターパーティがあります。 要するに、私は人生でこれまでにないようなプログラミングのトピックについて話しました。

コンファレンス

そして2階に上がって、私は会議に出席していました。 主催者にふさわしい目で会ったので、私はすぐに「私たちの時代のヒーロー」が誰であるかを実感しました。チームが過去数日間ほとんど眠っていなかったことは疑いもなく推測できました。

リョーシャ・フェドロフ氏は、会議のオープニングはほとんど気付かれないままで、誰もが行ったホール（カードスーツでマークされている-スタイルを維持する必要がある）がどこにあるかを語った。 廊下では、ジョーカー（上の写真を参照）で写真を撮り、古代のコンピューターゲームをプレイできます。

「9,000,000回ダウンロードされたJavaデスクトップアプリケーションの作成方法」

JUG.ruについてのセンセーショナルなレポートの著者であるAnton Keks（@antonkeks）のレポートに行きました。「 Javaを保存するにはどうすればよいか 」。Antonは、主な仕事「流血の企業」（ Antonは元々Cで記述してからJavaで書き直した「Angry IP scan」グリッドを盗聴するための人気のあるデスクトップアプリケーションを作成しました。







レポートは小さなファカプから始まりました。すべてのレポートはオーガナイザーのコンピューターからのもので、Javaはこれらのコンピューターにインストールされていませんでした！ その結果、アントンは自分のアプリケーションを実際に表示できませんでした。 この事実は、Javaでデスクトップアプリケーションを作成する場合、エンドユーザーがこのJavaを持っているという事実に頼ることができないことを改めて確信させました（この問題の解決方法については 、モスクワのJavaOne ） しかし、残念ながら、これはアントンを納得させませんでした。



アントン全体のレポートは、Javaデスクトップアプリケーションで何をすべきかが可能であり、必要であるという単純なアイデアを人々に伝えようとしました。 私はこれに完全に同意しますが、デスクトップ上のJavaがあまり人気がなく、特にMacとUbuntuの人気が高まっているという事実に、私はまだ本当に驚いています。 後者の事実により、AntonはアプリケーションをCおよびWin APIからJavaに書き換えるようになりました。これは、彼自身がWindowsを長い間使用していないが、Windowsユーザーを失いたくないためです。



JavaのUIとして、アントンはSWTを推進しました。 誰も知らない場合-これは、Eclipse UIの作成に基づいたIBMのUIライブラリです。 このライブラリの冗談は、SWTで記述されたアプリケーションが常にターゲットプラットフォームのネイティブアプリケーションのように見えるということです。単に、ネイティブコントロールを使用してUIを描画するからです。 JavaのデフォルトUIの何が問題なのかはSwingで、ターゲットプラットフォームのUIがエミュレートされます（常に良いとは限りません）。 ゼネラルウォースイングvs. SWTは2000年代初頭に非常に人気がありました。 これに関する私の個人的な立場は、両方のUIが優れていることです。SWTで常にターゲットプラットフォームのネイティブUIを取得する場合、SwingではネイティブUIよりも優れたUIを実行できます。この例はIntelliJ IDEAです（Windowsはそうではないと思います）ボタンをうまく描画します）。 最後の声明を踏まえると、JavaFXの選択も悪いとは思いません。



アントンはまた、HIG-ヒューマンインターフェイスガイドラインについても話しました。 このことの考え方は、さまざまなプラットフォーム上でコントロールの配置/命名規則があり、エンドユーザーがアプリケーションを操作するときに使い慣れた経験を得るためにこれらの規則に従うことをお勧めします。 したがって、UIを作成するときは、特定のプラットフォームのHIGルールを考慮する必要があります。 はい、プラットフォームに依存するコードが少しありますが、別のトリック（レイアウトマネージャーなど）を使用すると、このコードの量を非常に小さくすることができます。



報告の後、アントンと私は廊下でさらに20分間話しました。彼に会えてとてもうれしいです。おそらく私にとっては、この会議で最も印象的なイベントの1つです。

プロジェクトジグソーパズル。 新しい失敗

コーヒーブレイクで、シュリンイリン（@shurymury）に会いました-彼はこのカンファレンスでプレゼンテーションを行いました。 2枚撮ります。 私は彼に会えてとてもうれしかったし、友好的な方法で彼に尋ねた：「まあ、どのように、レポートの準備ができていますか？」。 彼は私を魅了しました。「もちろん、準備はできています。レポート全体に1つの簡単な考えがあります。PFC！ 「。 私は言います：「PFCの意味がわかりませんか？ 「。シュラ：」そして、それはつまり、ジグソーパズル、PFCがないことを意味します！より正確には、パブリックモジュラーJavaシステムはありません。「連絡します！シュラ：」想像してみてください、ジグソーパズルについてマーク（ラインホールド）を聞くこのレポートを作成するために、彼はモジュラーシステムをリリースしないことに決めたと言います。誰もそれを必要とせず、ホールに「モジュラーシステムが必要ですか？」と尋ねます。彼らが後で言ったように、シュラは彼の多くを失望させた15分で彼のレポート全体を入れました、しかし、私を信じて、彼はそれほど失望していません ！私のように。



今回はプロジェクトに何が起こったのかを推測することしかできませんが、Javaコミュニティーがこの方法でプロジェクトを終了せず、Javaで標準のモジュラーシステムを使用できることを願っています。

ガベージコレクションプロセスとそれに対してできることを理解する

その後、CTO兼共同設立者のAzul Systems-Gil Teneに1時間半かかりました。 それは素晴らしい報告でした-私はそれを強くお勧めします。 誰も知らない場合、AzulはVegaマルチプロセッサコンピューターの生産を開始しました。このコンピューターでは、54個のコアとテラバイトのRAMを搭載した各プロセッサーをこのようなマシンに挿入できます。 そして、これらのコンピューター用に特殊なJVMを作成しました。膨大な数のプロセッサーとメモリーでJVMをスケーリングする問題を解決する必要がありました。 Azulは、大量のメモリで拡張可能なGCを作成する方法を学び、全員に幸福を与えることにし、Azul ZingというJVMをリリースしました。 このJVMはHotSpotから継承されているため（そこにはMMとGCしかありません）、HotSpotと同じハードウェアで動作します。



Gilは、Javaのガベージコレクションについて詳しく説明し、基本から始めて最も洗練された手法で終わり、GCについて知っていたすべてのことを思い出しました。 数日で、JVMでGCについてExcelに通知する必要がありました-Excelsior JET 。 ちなみに、私はAzul GCが少なくとも外部的には私たちのものと似ていることに非常に感銘を受けました。それは同じブリックから組み立てられていますが、私たちは独立してこれに来ました。







ギルが伝えようとした主なアイデアは、ガベージコレクションの過程で、HotSpotが持つポイントとGCセットがポイントからはほど遠いということでした。 その結果、通常のJava開発者は、Javaでメモリ管理の問題を解決するためにGCを構成するために100万のペンを知る必要があります。 彼の意見では、ペンは正確に1つである必要があります。–Xmx（さらに先に進み、GCでもこのペンは不要です ）。 そして、砂の中に頭を隠してJavaのメモリ管理に問題はないと言う代わりに、Javaの世界をより広く見てみると、おそらくメモリ管理の問題がよりよく解決される他のJVM実装があることがわかります。



これは会議で最も強力なレポートだったようです。したがって、HotSpotオブジェクトのフィールドのレイアウトに関するレポートがこのトップに入ったにもかかわらず、彼が聴衆の推定によるとトップ10のレポートに入らなかったことは非常に驚くべきことです。 人々は、代替のJava実装を非常に警戒していると感じています。 しかし、なぜですか？ 結局のところ、Javaを使用して代替の実装を行うことができ、同時にアプリケーションがJava互換の実装で動作することを保証できることは大きな喜びです。 そして、これらの実装は、Oracleが人生で決して手に入らない問題を解決できます。



報告後、私はなんとかギルと話をすることができました。GCについて話しました。 彼が私たちについて完全によく知っていることを嬉しく思いました。 一般に、世界のJVMの開発者は原則として私たちのことを知っていますが、残念ながらJava開発者については言えません。

楽しいJVMテクニカルサポートライフストーリー

昼食後（ところで、非常に良い）、私に話をするのは私の番でした：ミシャビコフとOracleは共同報告をしました。 レポートのアイデアは1月に生まれました。 会議の時間は、ミーシャの休暇の時間とうまく一致しました。ミーシャは、ヨーロッパとロシアで過ごすことに決めました（彼はアメリカに住んでいます）。 MishaはOracle Java Licensee Engineeringで働いており、少し前にオラクルの公式の専任テクニカルサポートエンジニアであり、JCKテストに合格するのを本当に助けました。 さらに、オラクルの大規模な顧客の技術サポートに関与しています。 また、Excelsiorでテクニカルサポートを提供しており、私を含むすべてのJVM開発者が順番に勤務しています。 長年にわたり、ミーシャと私は、テクニカルサポートの人生からかなり多くの興味深い事例を蓄積してきました。それらを世界中の人々と共有することにしました。 レポートを最も一般的で典型的なテクニカルサポートの問題の4つの部分に分け、楽しいストーリーでそれらを希釈しました。 私たちはこのレポートを面白くしたかったのですが、私にはそうでした。それは楽しかったです、人々は笑いました。

プロフェッショナル向けのScala

弊社からは、Pasha Pavlovが作成したScalaに関するレポートもありました。



数年前、私たちはJVMのコアをほぼ完全に書き直すことにしました。 他のJVMと区別するJVMの重要なコンポーネントの1つは、AOTコンパイラ、つまりプログラム実行前に最適化されたマシンコードを生成するコンパイラです（「正直なexe」を取得します）。 ScalaでAOTコンパイラを書き直すことにしました。 したがって、最初は「JavaのJava」レポート（JavaのJavaとは対照的に、Oracle Labsのかなり有名なGraalプロジェクトはJavaのHotSpot JITを書き換える試みです）を作成したかったのです。 しかし、ここでの投票では、このレポートはあまり人気がなかったため、主催者はトピックをより一般的なものに変更するように頼みましたが、Scalaについてです。 その結果、パシャはレポートを作成するのにたった2.5週間しかありませんでした。 そして彼はまさにパフォーマンスまでそれを調理しました！ 「Passenger Ivanov、緊急に搭乗ゲートに乗ります」というアナウンスの中で、彼は空港での唯一の走行を成功させました。それは確かにパフォーマンスに影響を及ぼしましたが、話の途中で面白いエピソードが発生しました：PashaがJava 8でラムダを「安い中国の模倣」と呼んだ瞬間、Lesha Shipilev（@TheShade）はツイートしました：

アプリケーションにメモリリークがありますか？

このレポートがHabréの投票に登場し、予想外にリーダーになったとき、多くの人がそのトピックに驚きました。Javaがガベージコレクションを持っているように見えるため、メモリリークは原則として不可能です。 しかし、このトピックは私をまったく驚かせませんでした。私の人生では、これらのリークの多くがクライアントの例で見られました！



ガベージコレクターは、クラスのグローバル（静的）フィールドおよび呼び出されたメソッドのスタックから利用できないオブジェクトのみを収集します。 そして、ハッシュテーブルのようなグローバルフィールドを取得したら、そこにオブジェクトの追加を開始し（キャッシュなど）、このハッシュテーブルのクリーニングを忘れると、すぐにメモリリークが発生します。



多くの一般的なJavaフレームワークには内部キャッシュ（ハッシュテーブルとして配置されることが多い）があり、これを知らずに、突然メモリリークが発生する場合があります。 Nikita Salnikov-Ternovskyのレポートは、そのようなフレームワークでこれをプルするのを忘れると、リークが発生するという事実に正確に構成されていました（これをどのように知る必要があるかは明確ではありません）。



特に興味深いのは、ThreadLocalの場合です。 Nikitaは、WebアプリケーションでThreadLocalのようなグローバルを取得し、このWebアプリケーションを（サーバーを再起動せずに）再インストールすると、リークが発生することが保証されていると主張しました。 Lyosha Shipilevの参加を得てアフターパーティでこのケースを詳細に調べたところ、Java APIのThreadLocal実装にバグがあることがわかりました！ その後、これを処理する方法を見つけ、Leshaはこのバグを報告することを約束しました。

ヒープダンプのサイレントについて

このレポートのアイデアは、モスクワのJavaOneのリョーシャ・シピレフから聞いた。 彼は、Javaオブジェクトにフィールドを正しく配置する方法についてのハブに関するさまざまな 投稿を読むのにうんざりしていて、HotSpotがフィールドを広げる方法についてレポートを作成したいと言いました。 原則として、すべてのJava実装は、アライメント、プロセッサキャッシュの動作、およびオブジェクトのサイズの最小化のために、オブジェクト内のフィールドのレイアウトを最適化します。 したがって、クラスで指定するフィールドの順序はまったく意味がありません。JVMの場合は、必要に応じて自由に配置できるフィールドのセットにすぎません（異なるJVMでも、同じJVMの異なるバージョンでも）順序は異なる場合があります）。 したがって、Javaプログラミングでは、ソースレベルでフィールドの順序で何かを最適化しようとする以上に愚かなことはありません。 しかし、その後モスクワで、私がここであなたが2文で言ったことから全体の報告をすることができることに驚いた。 しかし、リョーシャは管理しました（ただし、リョーシャがハンズフリーマイクを死に至らしたときにレポートの最後にマイクを保持していたBaruch（@jbaruch）の助けなしではありません）！







最後に、聴衆の反応は面白かったです。「オブジェクトのフィールドがかなり違うかもしれないと想像できますか！」そして、人々が特定のJVM内部についての報告を聞きたがっている理由に再び驚きました。

アフターパーティー

会議には2つのアフターパーティがあり、1つは非公式で、1日目の終わりにあり、もう1つは公式でした。 初日は、さまざまなJVMの開発者が1つのコーナーに、Java EEマスターがもう1つのコーナーにいました。 そして真ん中に座っていたシュライリンは、パーティーの最高潮で叫びました：「それで、ここでJVMは筋金入りで、血なまぐさいエンタープライズがあり、私はここで何をしているのですか！」



アフターパーティーはネヴァの反対側にあったので、ホテルに住んでいた人々は、橋が離婚する前にそこに到着しなければなりませんでした。 これはすべて異なる方法で行われました。 私はかなり早く去り、誰かが「3時間」のミックスに取り掛かり、一部の人はそれをする時間がなかったため、朝6時までピーターを歩き回り、朝にホテルに戻りました。 そのため、翌日、一部の人は会議に参加できませんでした。

非会議

Unconferenceとは何を知るつもりだった人は誰もいません。 すべてのスピーカーの前夜には、イベントへの2つの招待状が与えられました。 そしてもちろん、ほとんどのスピーカーはこの招待を忘れていましたが、最初の日の終わりに思い出して誰かに手渡しました。



アンカンファレンスの初めに、サーシャ・ベロクリロフ（@alexbel）は形式を発表しました：イベントは3つのセマンティック部分に分割されています：いくつかのトピックが議論される円卓-誰によっても発表され、参加者がさらに投票するトピックについて議論されます; 落雷-トピックに関する5分間のレポート。 「観客からの詰め込み」-質問を記入した紙を投票箱に投げ込めば、観客全員がこれらの質問に答えます。







最初は、イベントの正確な形式を知らずに、昨年ノボシビルスクのDevDayで発言したテーマ「Web 3.0」で話そうと思いました。 この形式のレポートはどの会議にも適合しないため、Unconferenceの場合は適切だと思いました。 , : 5 . 20 : , , . , .



, , , . Java- , , ( ). Java Web . Java WebStart ( ), . , , , . , , JVM-, JavaScript Scala.



, , HTML+JavaScript. , , , . 3.0. Joker, , 2.0, .



Gil Tene, , -. , Java , challenges , .



, . “ ”. : “ Java ?”, “Java ++?», « OpenJDK?”, „ Java , ?”, “ ?».



. « Java RIA Mobile”, . , , : , , , , , , Java client-side . : ( ), , HTML + JavaScript , - , . , , , , , ( - , ), WORA (write once run anywhere), Java. „ Photoshop , ?“, , – “ !”.



mobile. mobile : , . : - , - JavaScript. , Java , ( ) ( JavaScript). , Java iOS, JIT ( iOS ). Excelsior JET, Java , Java, iOS. : , , .



OpenJDK. , - OpenJDK Oracle . , Java- OpenJDK, : GNU , Java.

2

, , , , . , JVM-, , , , : JVM ( ) .







, . Java vs. JavaScript. , JavaScript – : . , ( 16 JVM), , – JavaScript . , , JavaScript (, JSDoc , , - ?), JavaScript . , JavaScript . , Java vs. JavaScript: . .

JUG: Excelsior JET

, , Joker , . JUG Excelsior JET. JUG JavaOne . , JUG Joker. , , , JUG .







- , JUG . , , Oracle, . , , , : Excelsior JET , . , , , , .NET 4.0. , 200 . - , , , VLC – .NET. VLC . .NET , . : , .NET.



Excelsior JET, JVM : , Java. .



, , 3.5 , , ! , , . -: . SSA Regalloc, 2005 ( „ “), , . , ! , .

JCK

– , ! Oracl JCK .

. JCK, JCK. , Oracle ! , IBM, HP, SAP, .

. - ! - - .







, , !