• Oracle Technology Network
• ソフトウェアのダウンロード
• ドキュメント

検索

Java™製品のバージョン管理

第1章

1.1 はじめに

どのようなシステムでも、時とともに更新していくシステムにはサポートを提供する必要があります。通常、既存のシステムには、変更の適用方法を指定する規約およびメカニズムが定められています。これらのシステムは、ソフトウェア・プログラムがコンピュータにインストールされていることを前提としています。一般に、開発者は、必要とするほかのパッケージのバージョンを指定できており、インストール・プロセスは、システムの検証と構成に役立っています。

オープンな分散システムでは、既存システムが静的であるという仮定は当てはまらず、パッケージが変化する方法と時期を制御することは不可能なため、また的確な運用はパッケージ間の多くの依存関係に基づいているため、その更新はさらに困難です。オープンで信頼性が高く、かつ拡張性のある分散システムの構築という目標を達成するには、システム・パッケージの更新方法を規定する最新の規約とメカニズムのセットが必要となります。

このドキュメントでは、次について指定します。

1.2 要件

分散システム内の変更は、エンド・ユーザー、サポート組織、Web管理者、および開発者に重大な影響を及ぼします。

これらのグループごとに、更新を続けるネットワーク製品に対する要件を満たさねばなりません。

ユーザー

ユーザーには、時の経過とともにJavaベース製品は信頼性および互換性が向上するという確信を持たせる必要があります。ユーザーがアップグレードを躊躇する場合、「Write Once, Run Anywhere」という哲学に対するユーザーの確信を築くことが必要です。Javaでは、「アップグレードしたらどこかに障害が生じる」とか「ほかのユーザーが使用するデータを読み書きすることができなくなってしまう」という心配がないようにしなければなりません。

製品サポート

製品サポート組織にとって、使用されている製品とその使用環境、および製品パッケージの完成度を容易にかつ正確に識別できることは非常に重要です。

Webマスターおよび管理者

Webマスター、管理者、およびサービス・プロバイダは、信頼性が高く、サポート可能な方法で、Webまたはネットワーク・ファイル・システムを介してクライアントにアプリケーションを配備する必要があります。

製品開発者

製品開発者は、ユーザー、管理者、およびサポート・スタッフの要求を満たすアプリケーションおよびライブラリの記述およびデプロイ方法を理解する必要があります。開発者には、以下の製品およびパッケージの開発が求められます。

1.3 分散システムの更新で生じる問題

オープンな分散システムでは、パッケージが拡大し、個別に更新される場合に、多くの問題が発生することがあります。publicインタフェースを使用する際に、インタフェース固有の特定動作が維持されないと、予期しない方法でシステムに障害が発生する場合があります。オープン・システムは、異なる会社や組織が作成したパッケージで構成されています。これらの組織は、相互に連絡を取りながら運営されているわけではなく、独自のスケジュールで新製品を発表したり、アップグレードしたりします。アップグレードされたこれらの製品の配布には時間がかかり、しかもアップグレードを採用するかどうかという問題もあります。

Javaでは、ローカルおよび分散システムのコンポーネントは、publicインタフェースおよびほかのパッケージの動作規定に依存しています。それぞれのパッケージは時とともに更新されます。パッケージが正しく動作するためには、そのパッケージが依存するパッケージが、アップグレード後も期待される動作を継続して提供できなければなりません。

分散システムでは、システム全体の状態を把握することはできないため、部分的に整合性を保つことしかできません。システムの各プロセスおよび各パッケージは、システムの現在の状態を部分的にしか見ておらず、分散システムのほかの部分に情報を要求することにより情報を蓄積していきます。情報の断片は、それが起動したアプレット、ロードされたクラス、呼び出されたリモート・メソッド、または取得されたWebページのどれからであっても、すでに得ているシステムの情報と一貫性を保って使用できるように、注意深く扱う必要があります。

ロードされたクラス内の不一致により、クラスの検証ができない、行われた不正なクラス計算を認識できない、ユーザーが要求した機能が特定不能な障害を示すなどのさまざまなエラーが発生する可能性があります。

典型的な問題が生じるのは、以下のような場合です。

これらの問題は、動的にロードされたパッケージ間の非整合性から発生するため、予防したり、直接解決することはできません。これらのパッケージは1人のシステム管理者の管理下にあるわけではないため、現在の構成管理技術では特定することができません。

1.4 更新を考慮した設計

これらの問題に対処し、前述の要件を満たす鍵となるのは、パッケージおよびシステムのパッケージ化を注意深く設計し、一貫した単位ごとの更新、配布、およびロードを可能にすることです。大量生産される製品で一般的なのは、フィールド交換可能ユニットという概念です。これは製品の最小単位で、仕様およびサプライヤによって識別されます。また配布、再配布、および障害がある場合には交換も可能です。同様のモデルは、ソフトウェアの配布に利用されています。製品には名前やバージョン番号があり、1つまたは複数の仕様に準拠し、ネットワークまたはCD-ROMによって配布されます。また、その問題はサポート組織に報告できます。これらのパッケージは、配布、使用、検証、および置換またはアップグレード(必要な場合)が可能な最小単位です。パッケージは他のパッケージと組み合わせることができますが、その後もパッケージごとに識別、検証、および配布が可能です。

Java言語ベースのパッケージ・メカニズムは、置換え可能な単位という考え方とよく適合します。Javaパッケージは、publicインタフェースだけを公開し、ほかのパッケージのpublicインタフェースだけを使用します。Java言語仕様は、互換性を維持しつつ更新されるパッケージへのアプローチを定義しています。

1.4.1 下位互換に関するJava言語仕様

Java言語仕様は、適正な更新が期待されるパッケージ開発の基礎となります。以前にコンパイルおよび配布した他のクラスと下位互換を保ちながら、クラスをどのように変更できるかを定義するからです。堅牢な更新を実現するために重要なのは、public、protected、およびpackageインタフェースの安定性と、実装更新時の動作です。これでは、「互換性」のある変化を「既存のインタフェースまたは動作を変更しない変化」と定義しています。そのため、あるクラスがメソッドを定義し、そのメソッドが特定の動作をする場合、同じ規約がクラスのその後のバージョンすべてでサポートされる必要があります。詳細については、「Java言語仕様」の第13章を参照してください。ここでは、互換性のない変更が1つ追加されています。publicインタフェースへのメソッドの追加は、互換性がありません。

互換性のない変更は許可されませんが、新規または類似の機能はいつでも、新規または既存のインタフェースやクラスに追加できます。

Javaパッケージを更新単位として選択することによりクラスのpackage privateメソッドを変更でき、publicおよびprotectedクラスとメソッドに外部インタフェースおよびセマンティックスを保ちつつ、パッケージの実装に柔軟性を持たせることができます。

1.4.2 下位互換におけるオブジェクトの直列化仕様

コンポーネント間のストレージ保持機能および通信機能が強力であることは、分散システムにとって重要です。クラスを拡張しつつストレージ中の以前のデータをクラスが読めるようにするには、永続的なストレージを維持しつつコンポーネントを更新しなければなりません。分散システムでは、各コンポーネントの更新速度はそれぞれ異なりますが、コンポーネント間の通信の信頼性は維持できなくてはなりません。

オブジェクトを直列化する際、互換性に関する要件に従うことにより、より新しいまたはより古いバージョンのオブジェクトが一般的かつ一貫した方法で通信することが可能になります。詳細については、「Java^(tm)オブジェクト直列化仕様」の第5章を参照してください。

1.5 パッケージ・バージョンの仕様

確認が必要なアーティファクトのカテゴリがいくつかあり、それには仕様、実装、Java仮想マシン、およびJava Runtime Environmentが含まれます。

1.5.1 仕様のバージョン管理

オープン・システムは、仕様には複数の実装が含まれるという考えに基づいています。仕様は、組織や企業の援助のもとに更新されます。仕様に互換性のない複数のバージョンが含まれるというのは、望ましいことではありません。仕様または実装の各バージョンは、単一の次期バージョンにだけ更新しなければなりません。仕様に下位互換性を要求する考え方では、仕様を以前の仕様のスーパー・セットとみなすことができます。バージョンの配列順序は1とおりしかないため、特定のバージョン番号は特定の仕様を意味するセマンティックスを備えています。仕様のバージョン番号には、ピリオドで区切られた数字で構成されるデューイ10進数表記法が使用されます。

仕様は、次の項目で識別できます。

1.5.2 Virtual Machineのバージョン

Java仮想マシンの実装は、仕様と実装の両方から識別する必要があります。これらのプロパティは、java.lang.System.getPropertiesを使用してすでに利用可能なものに追加する必要があります。

これらのプロパティへは、java.lang.System.getPropertyメソッドを使用してアクセスします。その結果、文字列が返されます。

1.5.3 Java Runtimeのバージョン識別

Java Runtimeの識別に必要な情報は、すでに「Java言語仕様」のセクション20.18.7で指定されたプロパティにより、System.getPropertiesを使用して部分的に取得されています。

現時点では、これらのプロパティは、Java Runtimeの実装および利用可能なコア・クラスを識別します。これらのプロパティは、このJDKが実装するJava言語仕様を識別しません。

この実装が準拠するJava Runtime Environment仕様のバージョンの識別には、追加のプロパティが必要です。必要なプロパティは次のとおりです。

これらのプロパティには、java.lang.System.getPropertyメソッドを使用してアクセスできます。結果として、値が文字列で返されます。

1.5.4 パッケージのバージョン管理

各Javaパッケージは、クラス・ファイルおよびオプションのリソース・ファイルで構成されます。パッケージの中身を識別するために必要な情報も、パッケージの中に格納されています。

この仕様は、パッケージがJava Runtimeとともに配布される主要パッケージとして開発されたか、標準拡張として開発されたか、アプレットまたはアプリケーション・パッケージとして開発されたかに関係なく、すべてのパッケージに適用されます。

仕様のバージョン番号と異なり、実装のバージョン情報は、パッケージに以前のバージョンと下位互換性があることを示すものではありません。パッケージのバージョン番号は、バグなどの仕様と実装の相違を識別するためのものです。実装の新バージョンは、望ましくない動作または不正確な動作を取り除くために作成されるもので、下位互換性を意図したものではありません。パッケージのバージョンを示す文字列は、任意の固有値を持ち得るため、等価かどうかの比較だけが可能です。詳細については、セクション1.5.10「実装のバージョン番号を識別用に限定する理由」を参照してください。

次の属性名は、パッケージごとに定義されます。それぞれの属性の値は、文字列です。

これらの属性は、マニフェストに保存され、次で説明するjava.lang.Package APIを使用したプログラムにより取得できます。

1.5.5 パッケージ・バージョン情報へのAPI

java.lang.Packageクラスは、パッケージに関する情報を検索してアクセスするためのオブジェクトを提供します。

パッケージ・オブジェクトは、クラス・ローダーで明示的に作成します。これは、パッケージでクラスを最初に定義する前に作成する必要があります。各パッケージの属性はマニフェストに保存され、クラス・ローダーにより取得できます。

package java.lang;
public class Package {  

        // Return the name of this package.     
        public String getName(); 
        
        // Return the title of the specification of this package.       
        public String getSpecificationTitle();  
        
        // Return the version of the specification of this package.     
        public String getSpecificationVersion();        

        // Return the vendor of the specification of this package.      
        public String getSpecificationVendor(); 
        
        // Return the title of the implementation of this package.      
        public String getImplementationTitle(); 
        
        // Return the version of the implementation of this package.    
        public String getImplementationVersion();       
        
        // Return the vendor of the implementation of this package.     
        public String getImplementationVendor();        
        
        // Is this package is compatible with the requested version     
        public boolean isCompatibleWith(String desired);        
        
        // Get the Package for the named class  
        public static Package getPackage(String classname);     
        
        // Return the packages for currently loaded classes.    
        public static Package[] getAllPackages();       
        
        // Return true if this package is equal to another object.      
        public boolean equals(Object obj);      
        
        // Return the hashcode for this object  
        public int hashCode();  
        
        // Return the string describing this package.   
        public String toString();
} 

getNameメソッドは、このパッケージの名前、たとえば、java.langを返します。

getSpecificationTitleメソッドは、このパッケージの仕様タイトルを認識している場合はそのタイトルを、それ以外の場合はnullを返します。

getSpecificationVersionメソッドは、このパッケージが実装する仕様のバージョン番号を返します。バージョンを認識していない場合はnullを返します。

getSpecificationVendorは、仕様を所有する組織、グループ、またはベンダーを返します。

getImplementationTitleメソッドは、このパッケージの実装タイトルを認識している場合はそのタイトルを、それ以外の場合はnullを返します。

getImplementationVersionメソッドは、このパッケージが実装する実装のバージョン番号を返します。バージョンを認識していない場合はnullを返します。

getImplementationVendorメソッドは、この実装を所有する組織、グループ、またはベンダーを返します。

isCompatibleWithメソッドは、このパッケージの仕様のバージョン番号が目的のバージョン番号と互換性がある場合にはtrueを返します。このパッケージの仕様のバージョン番号が、提供されたバージョンの文字列より大きい場合は、trueが返されます。バージョンの文字列は、ピリオドで区切られた一連の正の数値です。番号は左から右へとコンポーネントごとに比較されます。番号が供給された文字列の対応する番号よりも大きい場合は、メソッドはtrueを返します。番号が供給された文字列の対応する番号よりも小さい場合は、falseを返します。対応する番号が等しい場合は、次の番号を調べます。

getPackageメソッドは、名前でクラスのパッケージを検索します。現在のクラス・ローダーを調査して、そのクラス・ローダー内でパッケージ名からパッケージ・オブジェクトへのマッピングを行います。メソッドは、パッケージの属性を含むパッケージ・オブジェクトを返します。パッケージ情報がまだロードされていない場合、あるいはクラス・ローダーによりパッケージ情報が何も定義されていない場合は、nullが返されます。

getAllPackagesメソッドは、現在のクラス・ローダーに認識されているパッケージの配列を返します。配列には、システムとクラス・ロードされたクラスの両方のパッケージが含まれます。クラス・ローダーによりロードされる利用可能なすべてのパッケージを識別するわけではありません。クラス・ローダーが情報を提供しているパッケージだけを識別します。

equalsメソッドは、パッケージが、オブジェクトが渡したものと同じ名前および同じクラス・ローダーを持っている場合は、trueを返します。

hashCodeメソッドは、Java言語仕様が必要とする等価の定義と一貫性を持つハッシュ・コードを返します。

toStringメソッドは、「package」とパッケージ名で構成される文字列を返します。利用可能な場合には、仕様タイトルと仕様バージョン番号が文字列に付け加えられます。

1.5.6 java.lang.Classの追加

このクラスのパッケージを取得するために、java.lang.Classにメソッドが追加されました。

package java.lang;
public class Class {    
        ...     
        public Package getPackage();    
        ...
} 

1.5.7 java.lang.ClassLoaderの追加

パッケージをサポートするために、クラス・ローダーが拡張され、クラスからパッケージへのマッピングを追跡し、クラス・ローダーがロードするクラスのパッケージ・インスタンスを定義できるように対応しています。追加されるメソッドは、サブクラスがクラス・ローダー内のパッケージを定義できるようにして、パッケージ実装がこのクラス・ローダーで定義されるパッケージに関する情報を取得できるように定義します。

java.lang.Package実装は、システム・コードから現在のクラス・ローダーを呼び出すために、そのクラス・ローダーを識別する必要があります。

package java.lang;
public class ClassLoader {      
        ...     
        // Return the non-null classloader of callers   
        public static ClassLoader currentClassLoader(); 
        // Define a Package     
        protected Package(String pkgname,                                       
                        String spectitle, String specversion,                                   
                        String specvendor,      String impltitle,                                       
                        String implversion, String implvendor); 
        ...
} 

currentClassLoaderメソッドは、システム・クラスから呼び出される場合も、現在のクラス・ローダーを検索するのに使用されます。クラス・ローダーがロードしたクラスから呼び出される場合、このメソッドはthis.getClass().getClassLoader()と同等のものを返します。この動作は、publicであることを除いて、現在のSecurityManager.currentClassLoaderメソッドと同じです。

保護されたアクセスのdefinePackageメソッドは、ロードしているクラスのパッケージを定義するのに使用されます。指定された名前を持つパッケージは、一度だけ定義され、そのパッケージの最初のクラスがロードされる前に定義されなければなりません。クラス・ローダーは、利用可能な場合には、マニフェストからバージョン管理の属性を提供する必要があります。

1.5.8 JARマニフェスト・フォーマット

現在のマニフェスト・フォーマットは拡張され、パッケージのバージョン情報属性の仕様に対応しました。マニフェスト・エントリは、Javaパッケージごとに作成する必要があります。エントリ名は、パッケージのクラスおよびリソース・ファイルを格納するアーカイブ内のディレクトリ名になります。たとえば、

Manifest-Version: 1.0
Created-By: 1.8.0 (Oracle Corporation)
Name: java/util/
Specification-Title: Java Utility Classes
Specification-Version: 1.2
Specification-Vendor: Example Tech, Inc.
Implementation-Title: java.util 
Implementation-Version: build57
Implementation-Vendor: Example Tech, Inc.

これらの属性は、マニフェスト・ファイルのプロトタイプを作成し、jarツールの「-m」スイッチを使用してマニフェストの構築時に属性をマージします。今後、jarツールはマニフェスト中でバージョン属性をブラウズおよび設定できるように拡張される予定です。

1.5.9 ユーザーが実行中のパッケージを識別する方法

ユーザーは、バグの発生時に、使用中のパッケージのIDをレポートできなくてはなりません。ユーザーから要求されたとき、またはエラーが発生したときに、入手可能な情報をユーザーに公開するかどうかは、アプリケーション、アプレット、またはブラウザにかかっています。APIでは次の情報を入手してレポートできるようになっています。

1.5.10 実装のバージョン番号を識別用に限定する理由

実装はそれぞれ独自に、バグの修正、パフォーマンスの向上、または仕様の以降のリビジョンで必要とされる新規の関数の追加を目的として更新されます。パッケージは、仕様を実装すると同時に、どのバージョンの仕様を実装したかを識別する必要があります。パッケージ間のやり取りは、publicおよびprotectedインタフェースおよびクラス経由でだけ行われます。publicのAPIおよび動作は、時間が経過しても安定している必要があります。そのため、あるパッケージの実装の変更が、別のパッケージの動作に影響を与えないように注意する必要があります。

パッケージのクラスが常に仕様を忠実に実装している場合には、仕様を識別するだけで十分です。しかし現実にはこのようなことはまれなので、バグに関係している可能性のあるパッケージが報告されるために、パッケージは自らの身分を明らかにする必要があります。

実装のバージョン識別子になんらかの意味を持たせるのには、重要な目的があります。バグを追跡するのが目的である場合、固有の番号を付ければ十分目的を果たすことができます。また、クライアントのパッケージがベンダーのパッケージの特定のバージョンに含まれるバグを回避する場合にも、固有の番号を付けると効果的です。該当する番号のバージョンをテストし、バグを回避できるからです。

ただし、1つのパッケージがほかのパッケージに含まれるバグを回避しようとすると、多くの付加的な問題が発生することがあります。ほかのパッケージは、仕様の一部ではない動作を識別する必要があり、実装にだけ属する動作を使用しようとするかもしれません。そのような実装固有の動作は、開発者によって確認およびテストされた特定のバージョンでないかぎり、信用することはできません。

ベンダー・パッケージのあるバージョンではじめて発生したバグは、次のバージョンでも障害になる場合と、ならない場合とがあります。バグを含むパッケージのクライアントが、バージョン番号に基づくバグの回避を行うと、特定のバージョンのバグを正しく回避できる場合があります。バグを含むパッケージが修正された場合、クライアント・パッケージはバグが修正されたかどうかをどのようにして知ることができるのでしょうか。あとのバージョンにもバグが含まれていると仮定した場合、クライアントは依然としてバグを回避する処置をとらなければなりません。バグを含まないパッケージでは、バグの回避そのものが正しく機能しない可能性があります。このため、バグの修正により一連のバグが発生する可能性があります。新しいバージョンをテストすることにより、バグの回避が必要か、あるいはバグの回避が正常に動作しているパッケージに問題を発生させることになるのかを見極めることができるのは、開発者だけです。また、あるバージョンにバグが存在することを知っているのは、開発者だけです。

1.6 開発方法のドキュメント化

このセクションでは、製品の開発と配布のそれぞれの側面について説明し、頑強かつ更新可能な製品を実現する方法についての方向付けを示します。