BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Java SEプラットフォームとJDKの新しいバージョン体系

Java SEプラットフォームとJDKの新しいバージョン体系

原文(投稿日:2017/11/08)へのリンク

他の主要な変更と並び、最近リリースされたJava 9に、新しいバージョン体系が導入された。この体系はJEP 223に基づき、Javaプラットフォームの将来のリリースのために作られたものだ。

しかし、リリース直後に、JavaチーフアーキテクトのMark Reinhold氏が、再び、バージョン体系を変更し、厳密な時間ベースのリリースモデルを採用する新しい計画を発表した。

JEP 223ベースのバージョン体系の主な目的は次の通りだ。

  • 人が簡単に理解できるバージョンにする。
  • 最新の業界の習慣に合わせる。
  • 既存のパッケージングシステムとプラットフォーム開発メカニズムで採用できる。
  • バージョンの文字列を1つの要素とし、2つの情報を符号化する現在のやり方を除く。
  • バージョン文字列のパース、検証、比較のための簡単なAPIを提供する。

新しいバージョン文字列のフォーマットは、Java 9のリリースノートに次のように記述されている。

$MAJOR.$MINOR.$SECURITY.$PATCH
  • $MAJOR バージョン番号は、メジャーリリースで更新する。メジャーリリースは、Java SE プラットフォームの仕様に明記される重要で新しい機能を含む。メジャーリリースの機能は計画され、前もって広く告知される。
  • $MINOR バージョンは、不具合修正、標準APIの修正、関連するプラットフォーム仕様の範囲外の機能の実装等、マイナーアップデート毎に更新される。
  • $SECURITY バージョン番号は、セキュリティアップデートリリースで更新される。セキュリティ向上のための緊急の修正を含む。
  • $PATCH バージョン番号は、同時にテストされた、セキュリティと顧客のための優先度の高い修正を含むリリースで更新される。

Reinhold氏は、時間をベースにしたリリースモデルのために、この体系に変更すると提案した。Java SE プラットフォームとJDKは、過去20年以上、大きく、不規則で、何か予測できない段階を経て進化してきたことを、Reinhold氏は論じた。

各機能リリースは、数は少ないが、新しい重大な機能によって出され、リリーススケジュールは、大抵、それらの機能の開発に合わせて、必要に応じて調整される。Reinhold氏によると、そのようなリリーススケジュールは時代遅れで、今、Javaは、より速いペースで進化する、数多くのモダンなプラットフォームと競争しなければならない。

Reinhold氏:他のプラットフォームや様々なオペレーティングシステムの配布で使われるリリースモデルから発想を得て、Java 9の後、私たちは厳密な時間ベースのモデルを採用します。6ヵ月毎の新機能リリース、四半期毎のアップデートリリース、そして、3年毎の長期サポートリリースです。

このモデルによると、急速な革新を好む開発者は、最新の機能リリースか、アップデートリリースを使い、出荷され次第、次のものを利用できる。安定性を望む企業は、代わりに、最新の長期サポートリリースを使う。そして、長期サポートリリースから次のリリースに移行することは、事前に計画できる。

提案されたバージョン文字列は、次の形式になるだろう。

$YEAR.$MONTH

2018年3月のリリースは、18.3であり、2018年9月のリリースは18.9だ。Reinhold氏は、jdk-devメーリングリストの投稿で、バージョンに絶対的な時間を使うことについて説明した。

 

Reinhold氏:
  • 絶対時間は、リリース日を反映します。そのため、JDKの開発者とJDKのユーザという関係する人たち全員に、時間ベースのリリースであることが明確です。「もう1つだけ機能を追加する」ためにリリースを遅らせることは問題外です。
  • 絶対時間は、リリースがいつのものか分かりやすく、ユーザとして、自分たちがどれだけ古いものを使っているか理解できます。相対時間の場合、時間単位が何か、いつこれらの時間ベースのバージョン番号が採用されたのかを知る必要があります。
  • 絶対時間の場合、リリースのリズムは独立しています。2、3年で、3ヵ月毎のように、もっと速いリズムに切り替えたら、絶対的な体系は変更する必要はありませんが、相対的な体系は、新しい時間単位と開始点を見直す必要があるでしょう。

絶対時間のバージョンモデルは、コミュニティでは人気がないことが証明され、Reinhold氏は、メーリングリストの投稿で見直した提案を出した。見直して提案された体系は、もともとJEP 223で提案されたものと似ていて、2つの見解の折衷案を表している。

新しいバージョン文字列のフォーマットで提案された最新の形式は、次の通りだ。

$FEATURE.$INTERIM.$UPDATE.$EMERG
  • $FEATURE カウンタは、リリースの内容に関わらず、6ヵ月毎に更新される。
  • $INTERIM カウンタは、互換性のある不具合修正や拡張を含む、機能リリースではないリリースで更新される。互換性のない変更は含まれない。このカウンタは、最新の6ヵ月毎のリリースモデルでは、常に0になる。
  • $UPDATE カウンタは、セキュリティ問題、以前はなかった不具合、新機能の不具合を修正する互換性のあるアップデートリリースのために、3ヵ月毎に更新される。
  • $EMERG カウンタは、重大な問題を解決するために緊急リリースする必要がある場合のみ、更新される。

これは、本来、時間ベースの体系だ。$FEATURE は、リリース内容に関わらず6ヵ月毎に更新され、機能リリース毎に、$UPDATE が3ヵ月毎に更新される。

このモデルでは、Javaの次の機能リリース(以前は、メジャーリリースと呼ばれた)は、それでもJava 10であり、2018年3月に作られるだろう。そして、Java 11は、2018年の9月だ。この提案は、活発に議論した後、すぐに最終決定されて、発表されるだろう。

 
 

Rate this Article

Adoption Stage
Style
 
 

この記事に星をつける

おすすめ度
スタイル

BT