CanonicalのOpenJDKビルドの概要
by Canonical on 1 August 2025
Javaは長年にわたり、大企業におけるソフトウェア開発で最も多く使われてきた言語であり、特に金融、医療、行政などの業界では、Fortune 500企業の90%がバックエンド開発にJavaを使用しています。
Javaの開発者は、他の開発者に比べ、新しい機能の導入と、レガシーアプリケーションのセキュリティ、安定性、パフォーマンスの両立に苦労します。Javaの各種バージョン、セキュリティ更新、そしてデプロイメントアーティファクトの管理は、かなり複雑です。
このためCanonicalはツールチェーンに大きく投資し、企業にもコミュニティメンバーにもメリットのある包括的なサービスを提供することにしました。CanonicalのOpenJDKサポートは、以下の基本方針に基づいて提供されています。
- 業界をリードするセキュリティメンテナンス:Ubuntu Proを通じて、OpenJDK 8に対しては2034年まで、その他のすべてのOpenJDK LTSリリースに対しては少なくとも12年間のセキュリティサポートを提供します。
- 新しいJavaリリースに速やかに対応:最新のOpenJDKリリースを次のUbuntuリリースに組み込みます。これはLTSリリースにも適用されます。
- コンテナのパフォーマンス最適化:Chisel生成のOpenJREによるサイズの削減と、CRaC(Coordinated Restore at Checkpoint)などの新しいテクノロジーを組み合わせます。
- 正確性の検証:AdoptiumのEclipse AQAvitテストフレームワークを使用し、Technology Compatibility Kit(TCK)に基づいてOpenJDKリリースの正確性をテストしています。
- 幅広いアーキテクチャのサポート:AMD64、ARM64、S390x、RISC-V、ppc64elなどをサポートしています。
では、これらの要素について詳しく見ていきましょう。
強化されたセキュリティ保証:長期的なセキュリティと安定性
Ubuntu Proのサブスクリプションは、すべてのOpenJDK LTSビルドについて最低10年間のセキュリティサポートを保証します。これにより、新しいアプリケーションを頻繁に導入する必要がなくなります。つまり、既存のレガシーアプリケーションの寿命を延長すると同時に、ユーザーエクスペリエンスを改善する機能の開発を優先できます。
これは特に、Java 8で実行されるレガシーワークロードにとって重要です。最近のNew Relic社のレポートによると、実運用環境の33%では、依然としてJava 8が使われています。24.04 LTSで実行するワークロードについては、Ubuntu Proのセキュリティメンテナンスが少なくとも2034年まで延長されます。これはRed Hatよりも8年、Azul Zuluよりも4年長い期間です。
Ubuntu LTSの各リリースでサポートされているOpenJDK LTSのバージョン
OpenJDK LTSのバージョン | 一般提供の開始 | 利用可能なUbuntu LTSのリリース | (Ubuntu Proを通じた)サポートの終了 |
8 | 2014年 | 18.04、20.04、22.04、24.04 | 少なくとも2034年 |
11 | 2018年 | 18.04、20.04、22.04、24.04 | 少なくとも2034年 |
17 | 2021年 | 18.04、20.04、22.04、24.04 | 少なくとも2034年 |
21 | 2023年 | 20.04、22.04、24.04 | 少なくとも2034年 |
イノベーションの促進:新しいJavaリリースへのタイムリーなアクセス
Ubuntuでは、長期的なサポートと短いリリースサイクルを両立させます。開発チームがすぐに試せるよう、OpenJDKの新バージョンはすぐにUbuntuで利用可能とします。
Ubuntu 24.04 LTS以降は、OpenJDKとUbuntuのリリースサイクルを次のように調整する予定です。
- 新しいOpenJDK LTSのリリースは、それ以降のUbuntu LTSリリースに組み込み、長期プロジェクトの安定性を確保します。
- LTS以外のOpenJDKのリリースは、次のUbuntuの中間リリースで利用可能となるため、新しい言語機能、API、パフォーマンスの改善をすぐにテストできます。
このような二重のアプローチにより、実運用環境でエンタープライズグレードの安定性を維持しながら、迅速にイノベーションを進める柔軟性が得られます。
さらに、CRaC(Coordinated Restore at Checkpoint)などの革新的なテクノロジーを使用して、実行中のJVMとアプリケーションの状態をチェックポイント化し、後で復元できるようにすることで、コンテナ化されたアプリケーションと従来のJavaアプリケーションの起動時間とウォームアップ時間を短縮しています。
デプロイの最適化:Chiselで生成した安全で最小限のJREコンテナ
コンテナイメージのサイズが大きくなると、CI/CDのサイクルが遅くなり、セキュリティリスクが高まります。Chisel生成のOpenJRE向けUbuntuコンテナは、不要なパッケージや依存関係のスライスをすべて削除することで、Javaランタイムのフットプリントを大幅に削減します。サイズが小さくなってもスループットは低下せず、他のOpenJDKディストリビューションのイメージと同等です。
以下のパブリックレジストリからイメージをダウンロードし、Ubuntu Proサブスクリプションに加入することで、追加の長期セキュリティとサポートを受けることができます。
Chisel生成のJREコンテナの情報:
特徴 | Chisel生成のJRE 8 | Chisel生成のJRE 17 | Chisel生成のJRE 21 |
圧縮サイズ | 37/38MB(AMD64/ARM64) | 44/42MB(AMD64/ARM64) | 50/51MB(AMD64/ARM64) |
Temurinと比較したサイズ | 約52%削減 | 約51%削減 | 約56%削減 |
パフォーマンスへの影響 | スループット/起動への影響はほぼ0% | スループット/起動への影響はほぼ0% | スループット/起動への影響はほぼ0% |
セキュリティメンテナンス | Ubuntu Proを通じて最長12年間のサポート | Ubuntu Proを通じて最長12年間のサポート | Ubuntu Proを通じて最長12年間のサポート |
今後数週間のうちに、Chisel生成のOpenJRE向けUbuntuコンテナと、他の主要なOpenJDKディストリビューションの同様の製品を比較した詳細なベンチマークを公開する予定です。
正確性の検証とコンプライアンスプロセスの簡素化
エンタープライズアプリケーションの開発において避けたいのは、実行時に想定外の動作が発生し、デバッグに時間を取られることです。Canonicalは2023年にEclipse FoundationのAdoptium Working Groupに参加して以来、OpenJDKバージョン17および21のすべてのビルドの正確性を検証し、すべてのUbuntuユーザーが信頼できる基盤上で最新のJavaアプリケーションを構築できるよう尽力してきました。
Eclipse Foundationでエグゼクティブディレクターを務めるMike Milinkovich氏は、次のように述べています。「Canonicalは、EclipseのメンバーがAdoptium Working Groupにどのように貢献し、参加によってどのような利点を得ているかを明確に示しています。Canonicalは、オープンソースJavaエコシステム全体のイノベーションを推進すると同時に、Eclipse AQAvitテストフレームワークを活用してJava TCKに基づくビルドを効率的にテストおよび認証しています。コラボレーションの今後の成果にも期待しています。」
当社のOpenJDKビルドは、AQAvitテストフレームワークを活用し、Technology Compatibility Kit(TCK)に基づいて厳密にテストされています。これは、以下のすべてのアーキテクチャのビルド(Ubuntu 22.04 LTSおよび24.04 LTS)に適用されます。
- AMD64
- ARM64
- s390x
- Ppc64el
- RISC-V
暗号化のコンプライアンス要件にも同じアプローチが適用されます。Ubuntu Proはopenjdk-11-fips(FIPS 140-2認証済みのBouncyCastleを含む)へのアクセスを提供します。また、専用のOpenSSL-FIPS Javaプロバイダに対するFIPS 140-3認証の取得も積極的に推進しているため、規制の厳しい業界や政府機関であってもコンプライアンスの遵守が容易になります。
GraalVMとCRaCによるクラウドネイティブなワークロードのパフォーマンスの向上
Javaアプリケーションは、実行時のパフォーマンスに優れていますが、Java仮想マシン(JVM)の初期化とジャストインタイム(JIT)コンパイルプロセスの影響で起動時間が遅くなるという問題を抱えています。そこで効率的なクラウドネイティブアプリケーションの開発を支援するため、この数年間でGraalVMとCRaC(Coordinated Restore at Checkpoint)という2種類のソリューションが登場しました。
Canonicalは、このようなプロジェクトがJavaエコシステムの将来にとって重要であることを踏まえ、必要なすべてのコンポーネントをパッケージ化してdebまたはsnapとして提供することで、Ubuntuでの導入と保守を容易にしました。
GraalVMは、高性能な多言語対応の仮想マシンであり、Java開発者に多大なメリットをもたらします。GraalVMにより、Javaのバイトコードをネイティブ実行ファイルに変換する事前(Ahead-Of-Time:AOT)コンパイルが可能になります。このAOTコンパイルにより、実行時のJITコンパイルが不要になり、起動時間が大幅に短縮され、メモリ使用量も削減されます。また、開発者がGraalVMの最新機能に容易にアクセスし、24.04以降のリリースで小型かつ高速なアプリケーションを構築できるように、snapを作成しました。
一方CRaCは、実行中のJVMをフリーズさせ、その状態をディスクに保存して、後で迅速に復元できるようにするソリューションです。アプリケーションを事前にウォームアップし、チェックポイントを取得することで、その後の起動が大幅に高速化され、多くの場合、わずか数ミリ秒で完了します。Canonicalは、CRaCのOpenJDKビルドとCRIU(Checkpoint/Restore In Userspace)の両方をパッケージ化し、アーカイブに追加しました。これにより開発環境のセットアップが容易となり、Ubuntu Pro(Ubuntu 26.04 LTS以降)を通じて最低10年間のセキュリティメンテナンスが得られます。
CanonicalのOpenJDKビルドの詳細
ニュースレターのサインアップ
関連記事
OpenJRE 8、17、21に対応するChisel生成のUbuntuコンテナ
Canonicalは、OpenJDKプロジェクトが提供するOpenJRE 8、17、21(Open Java Runtime Environment)に対応したChiselコンテナを発表しました。これらのコンテナイメージはサイズとセキュリティを重視し、必要不可欠な依存ファイルのみを含みます。AMD64とARM64の両アーキテクチャに対応しており、12年間のセキュリティサポートが付属します。 イメージは、以下のリンクからダウンロードできます。 Canonicalは、Chiselで生成したUbuntuコンテナを同等のJREイメージと比較するため、一連のベンチマーク測定を実施しました。GitHubリポジトリへのリンクは、このページの下部に記載されています。 Chisel生成のJ […]
コンテナイメージのセキュリティをソースで管理する
ソフトウェアサプライチェーンのセキュリティは、開発者やDevOpsエンジニア、さらにはIT責任者にとって最大の関心事です。セキュリティ侵害や依存ファイル侵害の大事件からわかるように、適切な検証と保守のないオープンソースコンポーネントはリスクの源となります。近年の開発とデプロイではコンテナ化が一般的な手法ですが、再現性とセキュリティの面に弱点があります。 コンテナには、簡単に導入できるだけでなく、安全で繰り返し使用でき、長期的なメンテナンスで新たな脅威に対応することが求められています。このことからCanonicalはコンテナ構築サービスの提供を開始しました。 オープンソースが抱えるセキュリティの課題 企業環境では、オープンソースソフトウェア(OSS)の利用が広がっています。 […]
BroadcomとCanonical、VMware Cloud FoundationをAI・コンテナ向けに最適化
大手クラウドOSと業界初の統一プライベートクラウドプラットフォームを組み合わせ、クラウドネイティブ化を推進 Broadcom(NASDAQ:AVGO)とCanonicalは、両社の技術を利用する企業が現代のコンテナベースのアプリケーションやAIアプリケーションをより短時間で安全に出荷できるよう、提携を拡大すると発表しました。このパートナーシップでは、Canonicalの信頼性高いオープンソースソフトウェアと、業界初の統一プライベートクラウドプラットフォームを組み合わせることで、利用企業による低コスト、低リスクの革新を推進します。 BroadcomのVMware Cloud Foundation部門製品担当バイスプレジデントであるPaul Turner氏は、次のように述べて […]