多くの人々は、Javaに何かが欠けている、バグがある、または遅いと不平を言っています。 良いニュース：文句を言うのではなく、自分でJavaを改善する機会があります。 JavaはOpenJDKプロジェクトとしてほぼ完全にオープンです。 このプロジェクトには独自の特徴がありますが、一般に、問題を自分で報告したり、修正したり、新しい機能を開発したりすることを妨げるものは何もありません。 この記事では、初心者向けにこれを行う方法を少し説明します。

バグを報告するには？

OpenJDKプロジェクトにはバグトラッカーJIRAがあります。 そこで、問題が既知か新しいかを検索して確認できます。 ただし、通りの人はそこに登録して書き込むことはできません。 Javaの問題を報告する（または改善を提案する）公式の方法は、 Java Bug Reportフォームを使用することです。 このフォームは、JIプレフィックスを使用してJIRAにチケットを作成します（Javaの問題、チケット番号は指定した電子メールに送信されます）。 事前調整の時点では、チケットはpr索好きな目から隠されています。 事前モデレーションが成功すると、問題はパブリックプロジェクト（たとえば、JDKプレフィックス付き）に移行し、誰でも見ることができます。 このフォームの利点は、比較的単純であり、登録や一般に個人データを必要としないことです。 欠点は、これらのフォームがJava開発者によって直接表示されるのではなく、特別なwebbugグループチームによって表示されることです。 （開発者の観点からは重要であるとしても）メッセージが長時間調査されずにハングするリスクがあります。 このチケットは、Oracleの良き友人に人々を揺さぶるように頼むまで、私のチケットは1か月ほど前から調整されていました。 偶然にも、たとえばここにいる私の同僚と同じように、チケットが完全に拒否されることさえあります 。 この問題はOpenJDKでのみ現れましたが、OracleJDKでは現れませんでした。webbugグループはこの問題は注目に値しないと考えました。 繰り返しますが、私は親友のおかげでそれを理解することができました。

また、チケットが事前調整を正常に通過し、パブリックプロジェクトに参加したこともありますが、これについては通知されませんでした。 したがって、 https://bugs.openjdk.java.net/browse/JI-xxxxxxx



の形式のURLをときどき確認し、最後にあるJI番号に署名することができます。 事前調整が完了すると、パブリックチケットにリダイレクトされます。そうでない場合は、エラーメッセージが表示されます。

いずれにしても、問題を明確に説明し、それを再現する最小限の例を挙げてください。 それが単純であるほど、彼らはそれに注意を払う可能性が高くなります。

もっと良い方法はありますか？

ご覧のとおり、このフォームには問題があります。 多くの場合、問題を適切なメーリングリストに報告する方が適切です。 OpenJDKは多くのメーリングリストをサポートしているので、関心のある分野のリストを間違いなく購読する必要があります。 リストアーカイブを参照して、それらが死んでいるかどうかを確認します。 たとえば、 ラムダに何らかの問題がある場合、ラムダプロジェクトがJava-8で完了し、リストが非アクティブであるため、ラムダ開発に書き込む価値はほとんどありません。 通常、lambdaの問題はJavaコンパイラの問題であるため、ほとんどのcompiler-devが適しています。

誰でもリストにサブスクライブして書き込むことができます。問題はありません。 添付ファイルに注意してください：ほとんどのファイルタイプはカットされます。 信頼性のために、 *.txt



以外は送信せず、メッセージが実際にリストに入ったかどうかをアーカイブから確認します（通常の状況では、送信直後にアーカイブに表示されます）。 これらのリストは実際の開発者によって読み取られるため、興味深い問題が発生した場合、それを解決するためのパスは短くなります。

そしてもっとエキゾチックな方法は？

代替案は、あなたの意見では、あなたの問題に興味があるだろうJava開発者への個人的な手紙かもしれません。 多くの開発者のメールアドレスは、同じメーリングリストのアーカイブで簡単に見つけることができますが、もちろんこの方法は危険であり、タクト感が必要です。 あなたの手紙は簡単に無視できます。 ただし、 JMHツールに簡単な機能要求を提供することができました。

よりエキゾチックなオプションは、 StackOverflowの問題について文句を言うことです。 OpenJDKの開発者はもちろん、Oracleの従業員もいますが、もちろん、彼らはすべてを読んでいるわけではなく、あなたのメッセージに気付かない可能性があります。 そして、彼らが気づいた場合、彼らはこれをしたくないでしょう。 それは私のために一度だけ、そして報奨金の宣言の後でだけ働いた。 Brian Goetzが私に答え、私の問題をバグとして認識しました。 開発者自身がチケットを作成して修正しました。 もちろん、この場合の成功に依存することは価値がありません。

さらにエキゾチックなオプションは、Javaカンファレンスで問題について不平を言うことです。 前回のJPointで、 chereminはエスケープ分析について話し、 Arrays.asListが壊れる興味深い事例の例を示しました（ プレゼンテーション 、スライド69以下）。 彼の報告を聞いた後、私はこの問題を修正するのが面倒ではありませんでした。 もちろん、この場合でも誰も成功を保証しません。

しかし、バグを修正する方法は？

これで、バグを報告する多くの方法があります。 しかし、コードを書くために手がかゆい場合はどうでしょうか？ まず、インフラストラクチャに対処する必要があります。

すべてのOpenJDKプロジェクトは、 こちらから入手可能なMercurialリポジトリに保存されます 。 Jdk9は現在開発中であり、通常はdevリポジトリが必要です。 jdk （クラスライブラリ）、 hotspot （仮想マシン）などのいくつかの個別のリポジトリからさらに選択できます。Javaの現在のバージョン（java8など）で問題が検出され、java9に残っている場合は、最初に修正されますjava9、次にjava8の更新に移植します（移植の意図する利点が変更を行うリスクを上回る場合）。 8つの問題のほとんどはまだ9つだけで修正されていますが、8つに転送することはできません。 必要なリポジトリをダウンロードし、そのデバイスの調査に時間を費やしてください。 クラスライブラリを修正する場合は、 jdk9/dev/jdk



/src/<jigsaw-module>/share/classes/



などのパスが必要jdk9/dev/jdk



。

コードを修正した場合、パッチが正常に機能することを確認してください。 私は正直に、OpenJDKをゼロから適切にアセンブルする方法を理解していませんでした。 代わりに、 KenaiプロジェクトからJava-9の最新ビルドをインストールします。 変更したjavaファイルのみを別のディレクトリにコピーし、次のようにコンパイルします（ java.base



モジュールのjava/util



変更例）：

 $ javac -Xmodule:java.base -d out/java.base src/java/util/*.java
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、次のコマンドを使用してテストアプリケーションを起動します。

 $ java -Xpatch:out MyTest.java
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

-Xmodule



および-Xpatch



は、Jigsawプロジェクトに登場しました 。 これに先立ち、 -Xbootclasspath/p:



は機能しましたが、Java-9ではこのオプションは機能しません。

そして、テストの書き方は？

ただし、リポジトリ内で通常の単体テストを作成することをお勧めします。 OpenJDKは、特別なjtregツールを使用してテストを実行します。 残念ながら、 完成したビルドは半年間更新されておらず、Jigsawに関連する変更がjtregの古いバージョンで問題を引き起こすため、これは重要です。 したがって、jtregを自分で構築する方法を理解する必要があります。

一般的に、テスト自体は通常TestNGを使用して記述されていますが、 main



メソッドでクラスを実行するだけでjunitと多くの古いテストがあり、例外で失敗することはありません。 jtregツールを使用すると、動物園全体を抽象化でき、多くの便利な設定が含まれています。

パッチの準備ができました！ どこに送る？

引き続きJavaに貢献することに決めた場合、OpenJDK階層の一番下にいます。 非常に簡単なパッチを送信できます（たとえば、ドキュメントの些細なタイプミス）。 これを行うには、パッチファイルを収集し（たとえば、 hg diff -g



を使用）、件名に[PATCH]



という単語を含む適切なメーリングリストに送信します。 小さなパッチは、説明と一緒にレターの本文に直接送信するのが最適です。 パッチのJIRAにチケットがある場合は、件名行にもチケット番号を示す必要があります。 次に、開発者の1人がパッチのスポンサーに同意するまで待ちます。 まったく回答がない場合は、数週間に1度、丁寧に相手を蹴ることができます。 メーリングリストで間違えられたかもしれませんが、実際にはパッチを実際にどこに転送するべきかが通知されます。

パッチが完全に自明でない場合、同じ方法で対応できますが、 Oracle Contributor Agreementに署名するまで、パッチはコミットできません。 当然、大企業がプロジェクトの背後にあるため、法的問題は不可欠です。 あなたは、あなたの個人的な著者のコードを送信し、それをOracleの共同所有者に譲渡することに同意します（しかし同時に、その権利に対するあなたの権利を失うことはありません。 契約書を印刷し、それを読んで（あまりありません）、署名し、スキャンして、指定した電子メールに送信します。 処理には少なくとも1週間かかることに注意してください。 成功すると、電子メールで通知され、名前が長いリストに表示されます 。 この時点で、OpenJDK Contributorのステータスを取得し、パッチを後援できます。

レベル8のエルフになるには？

2-3個の重要なパッチを正常にプッシュしたら、OpenJDK Authorのステータスを要求できます。 これを行うには、プロジェクトリーダーに手紙を書き（jdk9ではMark Reinhold）、コミットへのリンクを含むパッチをリストします。 成功すれば、新しい機会があなたに開かれます。 まず、サーバーcr.openjdk.java.net（SSh公開鍵が必要です）へのsftpアクセス。コードレビューのリクエストを発行できます。 次に、最終的にJIRAアカウントを取得します。 これで、記事の前半を喜んで忘れることができます。パッチを送信したコンポーネントだけでなく、自分でバグを適切に報告できます。 バグに投票したり、通知を購読したりすることもできます。 これから、あなたの名前がこのリストに表示されます 。 ここでは、さまざまなプロジェクトの人々のステータスを見ることができます。

ただし、OpenJDK Authorレベルでは、まだパッチのスポンサーが必要です。 パッチをメーリングリストに送信する必要はありませんが、 webrevツールを使用して特別なHTML-e-csのセットを生成する必要があります（これはkshスクリプトであり、Windowsの場合はUbuntuから仮想マシンをインストールする必要がありました。Windowsではピン留めできませんでした）。 こんな感じです。 webrevを生成することにより、コードレビューメーリングリストにリンクを送信し、コメントの準備をします。 誰かがコードをコミットすることに同意する必要がありますが、あなた自身がコミットの作成者になります。

次のレベルはOpenJDKコミッターです。 1つになるには、プロジェクトのメインリストのコミッター （たとえばjdk9-dev ）によってこのタイトルにノミネートされる必要があります。 このため、原則として、プロジェクトに少なくとも8つの重要な変更が必要です。 投票は非常に簡単です-反対するべきではありません。 このタイトルを使用すると、スポンサーは不要になります。 自分で変更をコミットし、他の人を後援することもできます。 しかし、もちろん、これはコードレビューをキャンセルしません。

最後に、OpenJDK Reviewerのレベルに到達できます。 ここでは、ほぼ同じことです-指名、投票ですが、要件はすでに厳しくなっています。 レビュアーのみが指名して投票できます。反対票がない場合、最低3票の賛成が必要です。 このステータスにより、他の人の変更を正式に確認できます。 ステータスとその取得手順については、 こちらをご覧ください 。

おわりに

Javaのバグを修正することは、すべてに対処するのに十分な忍耐と忍耐を示しれば、原則としてそれほど難しくありません。 パブリックAPIを変更する新機能を宣伝することははるかに困難です。 ここで素晴らしいアイデアを簡単にまとめることができます。 より重く見えるようにするために、機能から始めるのではなく、いくつかの単純なバグの少なくとも著者になることをお勧めします。 JIRAでオープンチケットを掘り下げて、簡単なものを見つけることができます。 これは非常に多くあり、上級開発者は常に小さなことをかき集める時間があるわけではありません。 それでも機能を提供する場合は、問題の履歴を調べるために怠tooにならないでください。メーリングリストのアーカイブを確認してください。 おそらく議論され、何らかの理由でそれをしないことに決めました。 新しい理由があるかどうかを考えてください。

喜んでプログラムし、Javaを改善しましょう！