目次 | 前へ | 次へ

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


第 1 章

1.1 はじめに

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

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

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

  • Java パッケージを構成するクラス、リソース、およびファイルのバージョンの設定方法。パッケージは、開発、パッケージング、検証、更新、および配布が可能な一貫した単位を定義する。パッケージごとのマニフェスト情報により、パッケージの内容を知ることができる。
  • 製品は、パッケージをアーカイブファイルに収めた形式で配布される。アーカイブファイルには、製品のバージョンおよび含まれるパッケージを示すマニフェストが含まれる。
  • 開発者および管理者が使用する標準や規約について指定する。パッケージおよびそれが依存するパッケージの更新を行なっても安定して稼動する、信頼性の高い製品の構築および配置に使用される。

1.2 要件

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

  • エンドユーザー
  • 製品サポート組織
  • Web マスターおよび管理者
  • 製品開発者

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

ユーザー

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

  • ユーザーは、アップグレードしても、ほかのプログラムを破壊したり、既存のデータが使えなくなったり、作成されるデータをほかのユーザーが使用できないといった問題は発生しないことを理解する必要がある。
  • ユーザーは、基本的に、手持ちのバージョンの製品に必要な機能が組み込まれているか、特定の機能を使用するにはどのバージョンを入手する必要があるのかを知ることに関心がある。
  • さらに経験を持つユーザーは、どのバージョンの製品のどのバグがあるかという情報を手に入れて、バグに対処したり、回避したりする。

製品サポート

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

  • よく発生する問題およびその解決方法が格納されたデータベースは、製品 ID 情報によりインデックスが設定されている。
  • 製品およびパッケージの相互運用は新種の問題を招くことがあるため、システム内のすべてのパッケージを識別しておく必要がある。問題は、十分に仕様が定められていない public インタフェース、仕様に準拠しない実装、仕様に含まれない実装固有の部分を使用するクライアントで発生する可能性がある。

Web マスターおよび管理者

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

  • サポートスタッフは、個々のパッケージの問題点およびパッケージ間の相互作用を正確に理解した上で、クライアントのサイトをサポートする必要がある。
  • サイトの構成は、自動化されたサイト管理ツールによるサイトの拡張に対応可能でなければならない。
  • 更新されたパッケージのインストールにより、既存のパッケージまたはアクティブなユーザーの訂正操作に問題が発生するようなことがあってはならない。

製品開発者

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

  • Web のオープンかつ動的な環境で正確に動作できる
  • クライアントとの互換性を損なうことなくアップグレードが可能である。
  • 依存するパッケージがアップグレードされた場合、その機能を利用できる。
  • パッケージの動的拡張機能を利用できる。
  • 開発する製品やパッケージが依存するパッケージを特定して問題を報告できる。
  • ユーザー、Web マスター、およびサポート組織のニーズを満たすようにパッケージ化されている。
  • アプリケーションや組織に適した監査要件、セキュリティー要件を満たすパッケージとその組み合わせが理解できている。

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

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

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

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

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

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

  • アプレットの実行中、Web サーバーの新しいバージョンへの更新時に、クラスの一部だけをロードした場合。アプレットがさらにほかのクラスをロードすると、新たにロードされたクラスは、すでにロードされているクラスとの整合性が保てなくなることがある。
  • 複数の Web サイトからのライブラリを使用しているアプリケーションが、必要とするクラスの一部だけをロードした場合。ライブラリが更新されると、互換性を保てなくなる可能性があり、アプレットまたはユーザーが検知しなければならなくなる。
  • アプリケーションまたはアプレットの実行中に RMI 呼び出しを行い、クラスをロードする必要のあるオブジェクトが返される場合。ロードされるクラスは、すでにロードされたクラスに対して整合性を保てないことがある。
  • アプリケーション、またはアプレットの実行中に RMI 呼び出しを行い、より新しいまたはより古いバージョンのクラスに対応したオブジェクトが返される場合。
  • ライブラリにバグがある場合、クライアントの側でバグに対処してきた場合には、バグの修正時に問題が連鎖的に発生することがある。

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

1.4 更新を考慮した設計

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

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

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

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

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

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

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

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

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

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

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

1.5.1 仕様のバージョン管理

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

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

  • 仕様の所有者
  • 仕様の名称
  • バージョン番号 - メジャー番号、マイナー番号、マイクロ番号。メジャーバージョン番号は重要な機能変更を示し、マイナーバージョン番号は機能の小規模な拡張を示す。マイクロバージョン番号は、バージョンをさらに細かく分類したもの。続くバージョン番号には、現在のバージョンより大きな数字が使用され、仕様の追加が行われたことを示す。

1.5.2 Virtual Machine のバージョン

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

  • java-vm.specification.version、例: 1.2
  • java-vm.specification.vendor、例: Sun Microsystems Inc.
  • java-vm.specification.name、例: Java™ Virtual Machine Specification
  • java-vm.version、例: Solaris 5.5 Native 1.0 build32
  • java-vm.vendor、例: Sun Microsystems Inc.
  • java-vm.name、例: Solaris 5.x JVM

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

1.5.3 Java Runtime のバージョン識別

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

  • java.version、例: Solaris 1.2
  • java.vendor、例: Sun Microsystems Inc.

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

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

  • java.specification.version、例: 1.1
  • java.specification.name、例: Java™ Language Specification
  • java.specification.vendor、例: Sun Microsystems Inc.

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

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

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

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

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

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

  • Package-Title パッケージのタイトル
  • Package-Version バージョン番号
  • Package-Vendor ベンダー企業または組織
  • Specification-Title 仕様のタイトル
  • Specification-Version バージョン番号
  • Specification-Vendor ベンダー企業または組織

これらの属性は、マニフェストに保存され、次で説明する 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

Name: java/util/
Specification-Title: “Java Utility Classes”
Specification-Version: “1.2”
Specification-Vendor: “Sun Microsystems Inc.”.
Package-Title: “java.util”
Package-Version: “build57”
Package-Vendor: “Sun Microsystems. Inc.” 

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

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

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

  • パッケージのロード内容
    package.getAllPackages メソッドではアクティブパッケージを返す。

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

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

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

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

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

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

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

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

  • Java 言語仕様を読み取り、下位互換性を保つ
  • 「直列化仕様」を読み取り、下位互換性を保つ
  • 必要なすべての機能を備えたプラットフォームを開発する。
  • プラットフォームの仕様の以前の各バージョンに含まれない新機能をテストし、フォールバックを行う、または適切なメッセージを表示する
  • パッケージと製品のバージョン管理情報を記述し、必要なファイルを作成する
  • アーカイブモデルによっては、内容全体に署名し、マニフェストを作成する必要がある
  • いちばん古いプラットフォームでテストする
  • マニフェストを持つアーカイブ内でのみ配布し、一貫性と整合性を保証する
  • Java パッケージ全体、またはアーカイブファイル全体を更新する

 


目次 | 前へ | 次へ

Copyright © 1993, 2013, Oracle and/or its affiliates. All rights reserved.