チーム名や業務名から分かると思いますが、一つの業務を担当するよりは、サービスのライフサイクルにおいてインフラ、開発、サービス技術の間で発生しうる死角を補う役割を担っています。JDKを使用できなくなりました。force)を立ち上げました。その作業内容や技術のことについてまとめるためにこの記事を書くことにしました。はじめに本格的な話に入る前に、OpenJDKの導入検討で感じたことがあったので昔の記憶を辿ってみます。Software)の信頼度についての評価は両極端で、公共機関や大規模な事業所で実際OSSを導入するのは容易ではありませんでした。Webサーバーを使っていました。恥ずかしながら、私はその製品に関する書籍を書いたこともあります(今はかなり年を取りましたね...)。最近は、Webサーバーに導入コストをかけるというのは理解できないかもしれませんが、当時は、1CPU当たり約20万円かかるサービスしか選択できませんでした。ほかの選択肢は多くなかったのです。Webサーバーはマルチプロセスとマルチスレッド対応で、Javaサーブレットコンテナを実装しており、一般的なウェブ環境では競合がありませんでした。ウェブサービス環境が発展して、iplanet+WebLogic形の3層構造があたり前のように採用されていた時期でした。Webサーバーが一般的だった時期を経て、最近はイベント駆動型のNginxや軽量のWebサーバーがさまざまな形で構築されています。Beans)が衰退してからは、ほとんどTomcatのサーブレットコンテナを実装し、安定的なサービスが運用できるように発展してきました。過去を振り返ってみると、商用のインフラソフトウェアを使っていた会社でOSS製品の話を持ち出すと、よく次のような質問が返ってきました。私は当時、OSSの導入を検討している組織に次のように言っていました。「OSSを使うためには、組織がOSSを受け入れられるように文化を変えるべきです。「責任の話なんかしないで、業者からの障害対応を待つよりは自ら対応して、コードのバグ修正くらいは直接できるように、ある程度コーディングもしなければなりません。」もちろん、ジョブローテーションしたり昇進すると現場から離れることになる公共機関や大手企業の場合は、そういう文化を作るのは難しかったんですが、当時ベンチャーと呼ばれていたドットコム企業や最近のスタートアップ企業では、次第にOSSを受け入れられる下地ができました。今はWebサーバー、サーブレットコンテナの設置または構成が特別な技術ではない環境になりました。JDKのライセンスの変更により、ネット上に出てくるOpenJDKに関しての質問と回答を見ると、約20年前の悩みが続いている気がします。今までと同様に、もしかしたらバグの問題があるかもしれません。他のバージョンに変えてテストしながら解決すればいいです。大きな心配なく、進められるでしょう。オラクルがなくなってもOpenJDKが消えることはないと思います。Kit)でテストしてから提供するので、Javaの互換性について確認されます。性能や安定性については直接社内で確認してから導入する予定です。v1.3から開発およびインフラ製品をサポートしてきましたが、インターネットの公式・非公式ドキュメントや掲示板を見て面白いと思ったことがあります。それは、当時のサン・マイクロシステムズや現在のオラクルに費用を払って技術サポートを受けるケースはごく稀なのに、上記のような心配の声があることでした。私は、OpenJDKのエバンジェリストではないですが、すでにOSS環境への信頼が市場に形成されており、周りを見ると多くのOSS製品を使ってサービスを構築しています。そのため、OpenJDKを導入することも同じく「OSSを導入する」という程度で考えたらどうかと思います。いくつか違う点があると思いますので、それについての検討は必要になるでしょう。OpenJDK導入にあたって考えること結果から申し上げますと、導入する過程で「大した苦労はなかった」です。いろんなバージョンのOpenJDKがあり、いちいちテストするのに時間がかかったことを除くと、深刻な欠陥や性能偏差などの問題はありませんでした。最後に話をしますが、「生産性」と「費用」の面をより考慮しました。JDKからOpenJDKに移行した時の問題を掘り出して解決方法を探ることでした。JDKからバグやセキュリティーの脆弱性が発見されても、2019年1月以降はオラクルがアップグレードを提供しないことになりました。そのため、Javaのメジャーバージョンのアップグレードは検討しませんでした。11に変更することとは違うレベルの問題です。Javaのメジャーバージョンを変更するというのは、ソフトウェア(JDK)の入れ替え以外に、アプリケーションコードで非推奨とするかどうかも考慮すべきです。利用しているフレームワークの互換性の検討だけでなく、新しいコードスタイルや改善事項に関するコード開発などを含めて検討が必要です。そのため、JDKの互換性、性能問題よりアプリケーションコードに関しての争点が大きいと思います。Support)となったバージョンや対応しない環境についての悩みもそれほど大きくありませんでした。サーバーが古かったり、最近のものであってもアップデートされていないサーバーへのOpenJDKの導入を検討するのであれば、私見ではありますが、「現状を維持し、JDKをこれ以上アップデートしないでください」**。新しいサーバーを構築する際に、OpenJDKを検討することをおすすめします。License)が適用されています。該当バージョン以降アップデートしなければ、そのまま使い続けられます。JDKのパブリックアップデートは終了し、その最後のバージョンは8u202です。JDKからOpenJDKに移行する際に、どの配布バージョンを選択するか、どのような方式で互換性や安定性または性能について検証するかを考慮する必要があります。ドキュメントで確認することもあり、特定ツールを使って負荷を検証することもあります。OpenJDKには、さまざまな提供元があります。Request)標準が策定されたため、その内容をもとに各提供元が実装を行います。communityからJDKコードを提供しており、このソースは公開されています。そのため、他の提供元は、該当ソースを参照したり改善してOpenJDKを配布しています。8までバックポート(backport)で提供されます。未完成のレベルですが、今後の流れによってはOpenJDKで両方のGCを使ったり、提供元によって違うものを使うなど、さまざまな形になるでしょう。安定性や性能をそれぞれ区別して考慮するには、やや曖昧なところがありますが、目標数値を定めてテストで検証しました。安定性を確認するために、プログラムを長時間(10時間以上)動作させて問題がないことを確認しました。性能確認は、一部の運用サーバーにOpenJDKを導入し、実際にユーザーからのリクエストを処理しながら負荷を増やして目標値(通常の3倍)でも問題なく動作することを確認しました。以下は、各提供元から配布するOpenJDKのバージョンの種類と特徴についてまとめた表です。8を使うためにライセンスが必要です。検討の基準値として使いました。Machine)です。あり、またアーキテクチャーが異なることもあり、検討対象から除外しました。サン・マイクロシステムズ時代に作られたコミュニティーグループで、一般に知られているOpenJDKが作られるところです。コミュニティーがメインなので、ここでソースは配布していますが、バイナリーはhttps://jdk.java.netで配布されています。https://jdk.java.netで配布されているバイナリーは、リファレンスとして使うことをおすすめします(参考)。Azulがオープンソースで提供するJDKです。AzulのZingとはアーキテクチャーが違います。Zuluは、OpenJDKをもとに開発されます。Azulと別途契約することで、サポートを受けられます。Hatが提供しています。Linux)およびCentOSのyumレポジトリからrpm(バイナリ形式)で配布されます。OSバージョンごとに、対応するOpenJDKのバージョンが異なります。OpenJDKの配布を主な目的とする開発者が運営しているコミュニティーで、さまざまな企業からの後援を受けています。communityがリードするHotspot(openjdk)と、IBMのサポートでEclipse.orgがリードするOpenJ9(IBM)のVMのバイナリーをすべて提供します。IBMが独自のJDKをEclipse.orgに寄付してから始まったプロジェクトで、VMアーキテクチャーがHotspotとは異なります。IBM系列のJDKを使っていた企業が、OpenJDKの導入を検討する場合、OpenJ9は有望です。Hotspot系列のJVMとOpenJ9(IBM)系列のJVMでは、設定およびアーキテクチャーにおいて多くの違いがあります。アーキテクチャーが異なるため、検討対象から除外しました。JDKで実行していたコードがOpenJDKで問題なく動くか」について心配することは余計なことかもしれませんが、実際に問題が発生するかもしれません。一般的なウェブ基盤のアプリケーションの場合、前述のTCKによるテストを通ったバージョンでは互換性の問題はないはずです(性能などは置いておいて)。私たちも確認を進めて行くうえで深刻な問題はありませんでした。一部のコードからJavaFXのデータ型オブジェクトを使っているところが確認されました(OpenJDKでは、ライセンス問題でJavaFXが含まれていません。OpenJFXを別途使うことができます)。Server)を起動したらログに例外エラーが多数発生したので、確認してみたら「javafx.util.Pair」を使いました。そのコードを他のオブジェクトを使うように修正して解決しました。classpathに追加するか、該当コードを削除することで問題を解決できます。JVMの互換性JVMアーキテクチャーの違いにより、JVMオプションが適用できない場合もあります。GCを使うために「-XX:+UseG1GC」を使った場合は、Eclipse.orgのOpenJ9では該当JVMオプションが適用されないため、WASの起動が失敗することがあります。そのため、VMアーキテクチャーが異なるEclipseのOpenJ9やAzulのZingは、JVMオプションについても考慮が必要です。このような理由があり、JVMアーキテクチャーが異なるAzulのZingとEclipse.orgのOpenJ9を除き、互換性を確認するために以下のテストを行いました。安定性および性能の確認Javaのマイナーバージョンをアップグレードした後、いきなりJVMプロセスがダウンした経験があります。原因は、JVM内部のバグによるプロセスのクラッシュで、とりあえず元のバージョンをデプロイした後、次のアップデートをデプロイして問題を回避しました。ハードウェアやソフトウェアに初期不良またはバグがないことを期待しますが、現実ではどのハードウェアも故障はありますし、どのソフトウェアもバグはあります。商用製品を使う理由は、このような問題が発生したら適切なサポートが受けられるためで、保険のように導入してメンテナンス契約を結びます。OSSの場合、商用製品より多くの情報がより早く公開され、重要な対応はむしろ商用製品より早く解決されるケースが多くあります。独自に(企業内部で)解決可能な技術を保有するという前提条件はあります。商用製品の場合は、クリティカルパッチ(hotfix)を提供することもありますが、一般に問題をまとめて次の統合パッチやバージョンアップグレードに反映します。独自の解決能力がない組織の場合、このようなサポートがより安定的だと判断することもあります。導入とともにすぐ分かる問題は初期に対応できますが、負荷の増加によるスレッド数の増加やメモリー使用量の増加など、運用しているうちに問題がわかる場合もあります。した問題は、新規インストールまたはアップグレードの後、時間が経ってから確認できることなので、サービスを提供する組織にとって致命的な問題になる可能性があります。数百台のサーバーに導入されているJDKを元に戻す作業は、サービス品質の面やエンジニアの作業量から見て大きな問題になります。そのため、互換性の確認が終わったOpenJDKについて以下のような確認作業を行いました。communityが提供するベンチマーキングプログラムと、38のサンプルコードを10~14時間連続で動作させ、以下の内容を確認しました。ベンチマーキングプログラムと、38のサンプルコードを利用して、JVMが正常に動くかを確認します。ベンチマーキングプログラムを10時間以上動作させ、JVMの動作に異常がないか確認します(プロセスのダウンがない、GCログを見て問題がない)。出力されたベンチマーキングデータをほかのJVMの結果と比較し、OpenJDKの種類による問題はないか確認します。すべてのJVMで大きな性能の違いはありませんでした。JMHが提供するサンプルコードの条件(例:負荷量など)は、変更しませんでした。ここでは、38のサンプルとString演算を実行し、その中からいくつかの結果を紹介します。ここで紹介する結果は、OpenJDK製品間の性能差を確認するためで、絶対的な数値として扱わないでください。テスト環境によって異なります。Scopeによる(shared/unshared)性能を比較します。ops/sは、1秒当たりの処理件数を意味しており、数値が大きいほど高性能となります。OpenJDKを除けば性能の差はあまり見えません。多量のループを実行し、性能を比較します。sec/opsの数値が小さいほど高性能となります。sec/opsであり、10万回を見ると、全体的に性能の差はほぼないと思います。Queueに割り込みをかけて処理にかかる時間を比較します。sec/opの値が小さいほど高性能となります。sec程度の差があり再測定しましたが、あまり変わりがなかったので、そのまま示しました。Builderの場合と「+」演算の場合を比較します。us/opの値が小さいほど高性能となります。Builderのappend()(stringBuilderConcatenation)より性能が格段と低くなりました。Builderのappend()を使うと性能が良かっものの、「+」演算では性能が低くなりました。sec/opであるため、問題はないと判断しました。運営サーバーの一部で実際にユーザーからのリクエストを処理しました。以下は、LINEのシステムモニタリングツール(IMON)で作成したグラフです。テストの結果、どのOpenJDKでも正常に動作することが確認できました。運営しているサーバーの一部にOpenJDKを導入してサービスを運営します。groupとして管理します。groupに入っているサーバーにOpenJDKを導入し、異常はないか最終確認をしました。2019年2月現在で異常はなく、正常に運営中です。プロビジョニング(provisioning)LINEで使っているサーバーは、プロビジョニングツールであるPMCを利用してJDKをインストールしてからsoftlinkに接続し、JAVA_HOMEの環境変数をsoftlinkで設定して構成されます。した管理方法は、サーバーを生成したり増設する際、スピーディーにシステムを構築でき、メンテナンス費用を抑えられるメリットがあります。今回のTFでは従来のシステムから一部のサーバーだけをOpenJDKに移行する作業を行い、臨時作業のために従来のシステムを調整することはできませんでした。下手をすると運営中のサーバーに問題が起きる可能性があったためです。いえ、数十台のサーバーを1台ずつ手作業で移行するのも簡単ではありません。サーバー1台に対して、ターミナルへの接続、コピー、インストール、リンクの変更、必要なjarファイルのコピー、再駆動などを作業するには、いくら速くても15分程度かかり、途中で一つでも漏れがあったら作業は失敗になりかねません。デプロイの際には同時に数百台に配布する必要もあります。そこで選んだのが、Ansibleです。Hatに買収されてからも、Ansibleはオープンソースで利用できます。この記事でAnsibleについては詳しく書けませんが、Ansibleのメリットを以下のようにいくつか取り上げますYAML形式で作成したPlaybookで、多数のサーバーに設定をまとめて適用できます。実際の作業はPythonで行われますが、Pythonよりは簡単なYAML形式のAnsible構文を勉強すれば、より簡単に自動化できます。Run)が可能になります。実際に適用する前に、Ansibleが正常に動作するか確認する作業は重要です。提供されるAnsibleモジュールを使うと、実行中に失敗しても例外処理が可能となります。多数のサーバーにインストールしたり設定を行ったりする操作は自動化できましたが、また他の問題がありました。LINEはサーバーにアクセスするためにKerberos認証を使いますが、OpenJDKを/usrの配下にインストールするにはroot権限も必要です。OpenJDKをインストールするだけのために、セキュリティーの根幹を無視することはできませんでした。少なくとも作業するユーザーの権限でサーバーへのアクセス権限を取得しOpenJDKを配布できるようにして、他の人が作業しても履歴が残って問題が発生したら追跡できるようにする必要があります。TFを進めるうえで、私一人で作業できるようにすることも可能でしたが、多数のサーバーを一人で作業することは無理で、今後の状況に応じてOpenJDKを配布できるプラットフォームが必要でした。TowerのOSS版であるAWXを採用することにしました。Towerのサイトをご参考ください。この過程で確認した問題と解決方法を紹介します(コードの詳細や構成は含まれていないことご了承ください)。認証キーの配布問題:Ansibleが動作するためには、作業対象のサーバーにSSH公開鍵を先に配布しておく必要があります。サーバー台数が少なければ、ターミナルでSSH公開鍵を入れることができますが、作業台数が多くなると1台ずつターミナルでSSH公開鍵を入れることは現実的ではありません。手作業でSSH公開鍵を入れる必要があるワークフローでは、作業台数が多くなったときに、自動化の意味が薄れてしまいます。Ansibleを使ってSSH公開鍵を配布するには、サーバーに接続しなければなりませんが、SSH公開鍵がなくてサーバーに接続できないジレンマ(?)状態になります。問題SSH公開鍵を作業対象のサーバーにインストールする必要があります。playbookからIDとpasswordを使って接続しようとすると、セキュリティー問題が発生する可能性があります。ID/passwordを入力してもらいます。セキュリティトークン(Keytab)を生成して対象のサーバーにアクセスします。実行するたびに作業する人のアカウント情報を使うため、コードからID/passwordが漏れることも避けられ、監査情報を残すこともできます。CLI環境でhostsファイルを作成するのも煩わしい作業ですが、AWXのGUIで多数のサーバーをいちいち登録することも大変です。多数のサーバーをGUIでいちいち登録することは大変です。LINEのサービスにはサービスをグループセット(GroupSet)とグループ(Group)に分ける概念がありますが、この情報を反映するのは非常に煩わしい作業です。Script機能を使います。AWXで作業対象サーバーのリストをInventoryと言います。社内のサーバー情報を抽出できるAPIサーバーから情報を受け、それをInventoryでインポートできるようにPythonコードを作成しました。作成したPythonコードのサンプルは以下のとおりです。セキュリティーの関係で一部の情報を取り除きました。grammar)を理解するうえで参考になると思います。以下のコードは、LINEの内部情報を取り除いて提供します。提供されたコードのままでは実行できない可能性があります。APIからJSON形式のサーバーリストを抽出できる環境の場合、ご自分の形式に合わせて修正が必要です。以下のドキュメントでfileベースのhostsファイルを読み込んで処理する部分も参考できると思います。ScriptでParsing可能な形式に出力する部分です。グループにサーバーリストを入れ、グループをグループセットの概念でまとめてくれる形です。グループの下にグループを追加する場合、'children'エンティティが使用されます。環境が異なるため、以下のコードのままでは実行できませんが、AWXで分析する形式を理解するうえで参考になると思います。以下から出力された内容がAWXパーシングフォーマットに合っていれば、Inventoryで生成されます。indent=3))テストに使用したツールテスト作業のために使ったツールがあります。ツールについての情報を簡単にまとめました。プロジェクトから提供されます。安定性テストおよびJVMごとの性能比較に使用しました。インストール方法は以下のとおりです。installJDKを選択するスクリプトです。PATH”を書き換えてください。"=================================="JDKの種類を選択し、負荷テスト(JMH)を実行するスクリプトは以下のとおりです。JDKから商用サービスとして提供されます。プロジェクトで開発されています。Buildsが開発中で、現在リリースされているバージョンで基本的なモニタリングは可能です。JVMのリアルタイムGC情報とスレッド状態をモニタリングするために使用しました。ViewerJVMで生成したGCログを分析するためのツールです。GCログをサポートするツールの中でオープンソースの製品です。UIが商用製品ほどの品質ではありませんが、データ分析用としては十分です。以下の画像は、今回のテストの内容ではなく、他のプロジェクトでメモリー漏れを分析したものです。今回のテストでは、異常がなかったため、分析する内容が特にありませんでした。ViewerのGitストレージはこちらから、バイナリーはこちらから確認できます。TowerのOSSバージョンです。OpenShift、Kubernetes、Docker環境で使用するように配布されています。compose環境でインストールして使いました。scriptを生成し、SSH公開鍵を配布してOpenJDKをインストールしました。確認された問題OpenJDKの導入を進める過程で確認された問題をいくつかご紹介します。OpenJDK自体の互換性、性能の問題ではなく、LINEが開発したアプリケーションで使われる一部のクラスがOpenJDKに含まれていないことが原因となった問題でした。Extension)のインストールの有無Java開発のセキュリティを強化するために、JCEを追加でインストールします。ビット数の高い暗号化に対応するために、プロバイダ情報が含まれたjarファイルをJDKのクラスパスに追加します。8_151より古いバージョンではJCEをダウンロードしてインストールする必要がありました。それ以降のバージョンには標準パッケージとして含まれており、以下のように設定することでJCEを有効にできます。“${JAVA_HOME}/jre/lib/security/java.security”ファイルを開き、”crypto.policy=unlimited”のコメントアウトを外すか、この行がない場合は追加します。“unlimited”);”コードを追加して有効にします。8バージョンにJCEが標準搭載され有効になっているので、別途インストールや設定は必要ありません。プロバイダの違いや実装されたコードをソースレベルで一つ一つレビューするには時間的に無理があるので、これまでと同様にJCEファイルをコピーしました。playbookを利用しました。WASの性能情報の収集LINEのモニタリングシステム(IMON)は、Tomcatのスレッドの情報などを収集するためにJavaのJMXを使用しており、独自のクラスが実装されています。.....OpenJDKでも正しく情報を収集するには、実装されているjarファイルをコピーする必要がありました。ここもOpenJDKをインストールする時に、Ansibleのplaybookで共通ファイルにコピーすることで解決しました。JavaFXの問題2006年11月、JDKの開発元であるサン・マイクロシステムズ社は、Javaのオープンソース化を決定しました。この過程で、サン・マイクロシステムズ社が直接開発していない一部のライブラリを外してOpenJDKとして提供されました。このとき、JavaFXも外されました。JavaFXは、デスクトップアプリケーションの開発時にGUIやマルチメディアを実装するための標準ライブラリであり、一般的なWebベースのプログラムで使われることはありません。必要な場合は、OpenJFXプロジェクトがありますので、ビルドしてインストールすることができます(https://openjdk.java.net/projects/openjfx)。通常、Webベースのアプリケーションでは使用しませんが、実際は不必要なJFXクラスを使っている場合がありました。その場合、解決策として以下の2つの方法があります。私たちは2つ目の方法を用いて、コードからJFXクラスを削除して解決しました。Hat社が提供するOpenJDKを使用することを決め、LINEの主要機能(メッセンジャー、認証、チャネルなどの一部)に導入しました。2019年2月現在、順調に運営されています。今回テストして導入したバージョンが、運よくバグや不具合がないバージョンだったのかもしれません。何らかの不具合が潜んでいても、私たちがその機能を使っていないため表面化していないのかもしれません。どの製品が正解というのはないので、現在の状況でベストと判断されるものを採用したのです。1.8.0_181、191です。途中で191が公開されたので一緒にテストしたからです。HatのOpenJDKを選択したのは、性能や互換性が優れていたからではありません。以下のように、「生産性」と「所有経費」を考慮した結果でした。他の製品も大体同じ性能を出しており、互換性の面でも問題ありませんでした。皆さんの環境では、私たちが選択したバージョンをそのまま適用できない場合がありますので、ご注意ください。生産性(エンジニアの作業の効率性と安定性)yumリポジトリを使用してリリースし、複数のサーバーに簡単にインストールできる。LINEのサーバーの多くはCentOSをベースにしており、最新版の6、7でしっかり管理されている。Ansibleのyumモジュールなどと組み合わせれば、自動化しやすい。バグのパッチなどの作業はCentOSによって行われる。所有経費(人件費、ライセンス費用)CentOSベースなので、追加の導入費用はかからない。独自でビルドする必要がなく、JDKの互換性確認(TCK)、セキュリティ、バグのパッチ、バージョン管理などを行う人材を維持する必要がない。今後、OSのアップグレードに合わせてJavaのマイナーバージョンのアップグレードも自然な流れで行われる可能性がある(ただし、安定性のために特定のバージョンに固定する)。Linux)に適用された後、hot-fixとしてリリースせずに次期バージョンに統合され公開される場合があります。この場合、商用のJDKよりパッチ適用が遅れることがあります。そのため、必要に応じてパッチを直接インストールしなければなりません。logにて、cveコードを利用して適用状況を確認できます。CVE-2008-0947単発性のセキュリティ問題が発生することはあり得ますが、それは一般的なことではありません。Exposures)が発生したのは2015年に1件だけです(https://www.cvedetails.com/product/23642/Oracle-Openjdk.html?vendor_id=93)。それ以外のセキュリティパッチは継続的に適用されています。CVEコードで管理すべきレベルのセキュリティ脆弱性は、大体迅速に対策が公開されます。一般に、JVM(WAS)は外部にサービスを直接提供しません(Webサーバーと比べた場合)。意見サービスを公開した時にインストールされていたJDKを何年もずっと維持するケースが多くあります。OSのアップグレード時またはyumのアップデート時にパッチを反映し、正しく動作するかを確認することを推奨します。JDKを使用しており、ライセンス契約を締結する計画がない場合は、注意すべきことがあります。私は専門家ではないので、ライセンスの詳細を解説することはできませんが、現在公開されている内容をもとにまとめてみました。11などのバージョンは、ライセンスを取得せずにアップデートしてはいけません。Oracleのサービスアカウント)を持っていないとアップデートをダウンロードすることができません。入手できたとしても、それをインストールする行為はOracle社のライセンスポリシーに反することになります。PC/Notebookサーバーと同じ制約があります。8u202をインストールすると、「企業のユーザーは2019年4月になると影響を受けます。」という案内画面が表示されます。update)が有効になっている場合は、その設定を無効に切り替えるか、それ以上アップデートが行われないように対策してください。OpenJDKをインストールするのも、解決方法の一つです。8のアップデートを提供します(https://www.oracle.com/technetwork/java/java-se-support-roadmap.html)。会社のPCやノートパソコン(個人の所有権とは関係なし)は、個人ユーザーではなく商用(Commercial)ユーザーとみなされ、ポリシー違反になり得ます。おわりに最後になりましたが、2018年10月から2019年1月までOpenJDKの導入に向けたTFに参加して経験したことをまとめておきます。TFに参加している間、どんな方法論を取り入れるか、どんな方法で検証するか、などを考えてテストすることに多くの時間を費やしました。製品自体に大きな不具合がなくてよかった、と思ったりもしました。冒頭で説明したように、OpenJDKも現在私たちが使っている数多くのオープンソースの一つです。コードと密接にかかわっているので、修正時に起こり得る不具合が懸念されることもあるでしょう。DBなど、問題が起こるとさらにクリティカルになりかねない基幹システムをすでに多数利用しているのが現状です。したことを考慮すれば、数十台から数百台までと比較的規模が小さいJVM(JDK)のオープンソース化も、できないことではないと思います。内容に不備があってサービスに不具合が発生したりすることがないように、丁寧な現状分析と徹底したテストが欠かせないことを忘れないでください。私たちの経験が、OpenJDKの導入に悩んでいる方々に少しでも参考になれれば幸いです。ありがとうございました。Developers日本語English。