JP2001273131A - プログラムの編集方法、シングルパッケージ化システム、プログラム開発システム、プログラムの身元情報付加システム、編集プログラム、記憶媒体及びプログラム伝送装置 - Google Patents
プログラムの編集方法、シングルパッケージ化システム、プログラム開発システム、プログラムの身元情報付加システム、編集プログラム、記憶媒体及びプログラム伝送装置Info
- Publication number
- JP2001273131A JP2001273131A JP2000082556A JP2000082556A JP2001273131A JP 2001273131 A JP2001273131 A JP 2001273131A JP 2000082556 A JP2000082556 A JP 2000082556A JP 2000082556 A JP2000082556 A JP 2000082556A JP 2001273131 A JP2001273131 A JP 2001273131A
- Authority
- JP
- Japan
- Prior art keywords
- name
- program
- package
- class
- replacing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 97
- 238000004806 packaging method and process Methods 0.000 title claims description 19
- 230000008569 process Effects 0.000 claims description 35
- 230000008859 change Effects 0.000 claims description 16
- 230000005540 biological transmission Effects 0.000 claims description 4
- 238000010586 diagram Methods 0.000 description 12
- 238000012545 processing Methods 0.000 description 8
- 230000006870 function Effects 0.000 description 4
- 238000007689 inspection Methods 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 238000012856 packing Methods 0.000 description 2
- 238000011160 research Methods 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/468—Specific access rights for resources, e.g. using capability register
Abstract
(57)【要約】
【課題】 名前スコープを用いたアクセス制限を有効に
活用して、保護されるべきリソースを持つプログラムが
不正なプログラムに呼ばれることを防止できるようにプ
ログラムを編集する。 【解決手段】 複数のクラスにて構成されたＪａｖａの
プログラムに対し、各クラスが属するパッケージのパッ
ケージ名を単一のパッケージ名に置き換えるステップ
（１０１）と、このクラスにおけるこのプログラムの外
部から参照されない内部化可能なデータの名前スコープ
を、パッケージスコープに変更するステップ（１０２）
と、このパッケージ名の置き換えとこの名前スコープの
変更が行われたプログラムに対して、電子署名を行うス
テップ（１０５）とを含む。
活用して、保護されるべきリソースを持つプログラムが
不正なプログラムに呼ばれることを防止できるようにプ
ログラムを編集する。 【解決手段】 複数のクラスにて構成されたＪａｖａの
プログラムに対し、各クラスが属するパッケージのパッ
ケージ名を単一のパッケージ名に置き換えるステップ
（１０１）と、このクラスにおけるこのプログラムの外
部から参照されない内部化可能なデータの名前スコープ
を、パッケージスコープに変更するステップ（１０２）
と、このパッケージ名の置き換えとこの名前スコープの
変更が行われたプログラムに対して、電子署名を行うス
テップ（１０５）とを含む。
Description
【０００１】
【発明の属する技術分野】本発明は、保護されるべきリ
ソースを持つプログラムが不正なプログラムに呼ばれる
ことを防止できるようにプログラムの編集を行うプログ
ラム編集方法に関する。
ソースを持つプログラムが不正なプログラムに呼ばれる
ことを防止できるようにプログラムの編集を行うプログ
ラム編集方法に関する。
【０００２】
【従来の技術】Ｊａｖａは、一つのＪａｖａＶＭの中
に、複数のプログラムが実行時にロードされて実行され
るというユニークなプログラミング環境を持つ。このた
め、保護されるべきリソースを持つプログラム（以下、
プログラムＡと称す）が、不正なプログラム（以下、プ
ログラムＭと称す）に呼ばれることを防ぐためのメカニ
ズムが必要である。保護することが必要なプログラムＡ
としては、ローカルファイルなどをアクセスするシステ
ムクラス群（FileInputStream等）や、ユーザのプライ
バシー情報を管理しているクラス、署名されたことによ
ってシステムクラスを呼ぶ権限を保持しているクラスな
どがある。
に、複数のプログラムが実行時にロードされて実行され
るというユニークなプログラミング環境を持つ。このた
め、保護されるべきリソースを持つプログラム（以下、
プログラムＡと称す）が、不正なプログラム（以下、プ
ログラムＭと称す）に呼ばれることを防ぐためのメカニ
ズムが必要である。保護することが必要なプログラムＡ
としては、ローカルファイルなどをアクセスするシステ
ムクラス群（FileInputStream等）や、ユーザのプライ
バシー情報を管理しているクラス、署名されたことによ
ってシステムクラスを呼ぶ権限を保持しているクラスな
どがある。
【０００３】プログラムの実行時にプログラムＡをプロ
グラムＭから見えないようにする手段（動的なアクセス
制限）としては、通常、次の二つの方法が使われる。一
つは、プログラムＡとプログラムＭが異なるアプリケー
ションである場合に、クラスローダを分離する方法であ
る。Ｊａｖａのコードは全てクラス単位の .class ファ
イルによって構成されており、クラスが必要になるとク
ラスローダ（Class Loader）により動的にロードされ
る。クラスローダは、当該クラスのプリンシパル（Prin
cipal）を見て、ロードして良いかどうかを決定する。
他の一つは、プログラムＡがシステムクラスである場合
に、スタックインスペクションにより、プログラムＭの
プリンシパルをテストする方法である。
グラムＭから見えないようにする手段（動的なアクセス
制限）としては、通常、次の二つの方法が使われる。一
つは、プログラムＡとプログラムＭが異なるアプリケー
ションである場合に、クラスローダを分離する方法であ
る。Ｊａｖａのコードは全てクラス単位の .class ファ
イルによって構成されており、クラスが必要になるとク
ラスローダ（Class Loader）により動的にロードされ
る。クラスローダは、当該クラスのプリンシパル（Prin
cipal）を見て、ロードして良いかどうかを決定する。
他の一つは、プログラムＡがシステムクラスである場合
に、スタックインスペクションにより、プログラムＭの
プリンシパルをテストする方法である。
【０００４】しかしながら、クラスローダを分離する方
法では、プログラムＡとプログラムＭとを同じウェブペ
ージ（ディレクトリ）に置いたならば、プログラムＭが
プログラムＡのクラスローダを使用することができるた
め、アクセス制限を突破できてしまう。また、スタック
インスペクションを行う方法では、署名付きのプログラ
ムＡがアクセスに必要な権限を取得した場合や、ローカ
ルファイルからロードされたクラスに対しては、スタッ
クインスペクションが適用されない。
法では、プログラムＡとプログラムＭとを同じウェブペ
ージ（ディレクトリ）に置いたならば、プログラムＭが
プログラムＡのクラスローダを使用することができるた
め、アクセス制限を突破できてしまう。また、スタック
インスペクションを行う方法では、署名付きのプログラ
ムＡがアクセスに必要な権限を取得した場合や、ローカ
ルファイルからロードされたクラスに対しては、スタッ
クインスペクションが適用されない。
【０００５】プログラムの実行に先立ってプログラムＡ
を保護する手段（静的なアクセス制限）としては、名前
スコープを用いてアクセスを制限する方法がある。名前
スコープとは、フィールドやメソッドを参照できる範囲
を定義するために、当該フィールドやメソッドにおいて
宣言されるものである。すなわち、宣言された名前に応
じて、他のプログラムからの参照（アクセス）を制御す
ることができる。例えば、privateスコープは他のプロ
グラムから直接参照することは一切できないし、反対
に、publicスコープは他のプログラムから自由に参照す
ることができる。また、packageスコープは、当該packa
geスコープの宣言されたフィールドやメソッドと同一の
パッケージ内からでなければ参照することができない。
を保護する手段（静的なアクセス制限）としては、名前
スコープを用いてアクセスを制限する方法がある。名前
スコープとは、フィールドやメソッドを参照できる範囲
を定義するために、当該フィールドやメソッドにおいて
宣言されるものである。すなわち、宣言された名前に応
じて、他のプログラムからの参照（アクセス）を制御す
ることができる。例えば、privateスコープは他のプロ
グラムから直接参照することは一切できないし、反対
に、publicスコープは他のプログラムから自由に参照す
ることができる。また、packageスコープは、当該packa
geスコープの宣言されたフィールドやメソッドと同一の
パッケージ内からでなければ参照することができない。
【０００６】名前スコープを用いる場合、プライベート
と宣言されたフィールドやメソッドは、他のプログラム
から直接アクセスされることがないことが保証されてい
る。したがって、プログラムＡに関してプライベートと
宣言することにより、プログラムＭからのアクセスを制
限することができる。しかしながら、プログラムが複数
のクラスからなり、それらのクラス間にインタラクショ
ンが存在する以上、全てのフィールドやメソッドをプラ
イベートと宣言することはできず、いくつかのフィール
ド及びメソッドは、package以上（package、protecte
d、publicのいずれか）のスコープを持たざるを得な
い。
と宣言されたフィールドやメソッドは、他のプログラム
から直接アクセスされることがないことが保証されてい
る。したがって、プログラムＡに関してプライベートと
宣言することにより、プログラムＭからのアクセスを制
限することができる。しかしながら、プログラムが複数
のクラスからなり、それらのクラス間にインタラクショ
ンが存在する以上、全てのフィールドやメソッドをプラ
イベートと宣言することはできず、いくつかのフィール
ド及びメソッドは、package以上（package、protecte
d、publicのいずれか）のスコープを持たざるを得な
い。
【０００７】packageスコープは、ＪＤＫ 1.2.1までの
Ｊａｖａプログラムでは、任意のプログラムＭが、自由
に自分のパッケージを宣言することができる（ただし、
パッケージ内だけで有効な名前の範囲に限られる）。こ
のため、プログラムＭがプログラムＡと同じ名前のパッ
ケージを宣言することによって、当該プログラムＡのパ
ッケージに参加してしまう、いわゆる「Package Joinin
g Attack」が可能であった。すなわち、パッケージは、
誤って名前が衝突してしまうことは防げるが、セキュリ
ティ上のアクセスコントロールのメカニズムとしては不
十分だった。
Ｊａｖａプログラムでは、任意のプログラムＭが、自由
に自分のパッケージを宣言することができる（ただし、
パッケージ内だけで有効な名前の範囲に限られる）。こ
のため、プログラムＭがプログラムＡと同じ名前のパッ
ケージを宣言することによって、当該プログラムＡのパ
ッケージに参加してしまう、いわゆる「Package Joinin
g Attack」が可能であった。すなわち、パッケージは、
誤って名前が衝突してしまうことは防げるが、セキュリ
ティ上のアクセスコントロールのメカニズムとしては不
十分だった。
【０００８】ＪＤＫ 1.2.2では、一つのパッケージにお
ける署名者をただ一人だけとする１パッケージ１署名者
の原則（One-Package-One-Principal Policy）が取りい
れられたため、プログラムＡが署名されている限り、署
名されていないプログラムＭがプログラムＡと同一のパ
ッケージに参加することはできなくなった。従って、署
名されたプログラムでは、パッケージと宣言されたフィ
ールドやメソッドは不正なプログラムにアクセスされる
ことはなくなった。このため、Packageスコープは、セ
キュリティ上のアクセス制限の機能を果たせることとな
った。
ける署名者をただ一人だけとする１パッケージ１署名者
の原則（One-Package-One-Principal Policy）が取りい
れられたため、プログラムＡが署名されている限り、署
名されていないプログラムＭがプログラムＡと同一のパ
ッケージに参加することはできなくなった。従って、署
名されたプログラムでは、パッケージと宣言されたフィ
ールドやメソッドは不正なプログラムにアクセスされる
ことはなくなった。このため、Packageスコープは、セ
キュリティ上のアクセス制限の機能を果たせることとな
った。
【０００９】
【発明が解決しようとする課題】上述したように、Ｊａ
ｖａにおいて、保護されるべきリソースを持つプログラ
ムＡが不正なプログラムＭに呼ばれることを防ぐための
メカニズムとしては、名前スコープを用いた静的なアク
セス制限手段を用いることが有効である。しかし、セキ
ュリティ上のアクセス制限を実現するのは、プログラム
Ａに関してプライベートと宣言した場合か、署名された
プログラムＡに関してパッケージと宣言した場合に限ら
れ、protectedやpublicのスコープを持つクラス、フィ
ールド及びメソッドについては、依然としてセキュリテ
ィ上の保護はない。
ｖａにおいて、保護されるべきリソースを持つプログラ
ムＡが不正なプログラムＭに呼ばれることを防ぐための
メカニズムとしては、名前スコープを用いた静的なアク
セス制限手段を用いることが有効である。しかし、セキ
ュリティ上のアクセス制限を実現するのは、プログラム
Ａに関してプライベートと宣言した場合か、署名された
プログラムＡに関してパッケージと宣言した場合に限ら
れ、protectedやpublicのスコープを持つクラス、フィ
ールド及びメソッドについては、依然としてセキュリテ
ィ上の保護はない。
【００１０】しかしながら、ある程度以上の大きなＪａ
ｖａプログラムは、複数のパッケージからなることが多
く、パッケージ間のインタラクションのために、いくつ
かのクラス、フィールドまたはメソッドをパブリックに
せざるを得ない。したがって、そのようなプログラムで
は、privateスコープやpackageスコープを用いたアクセ
ス制限を有効に活用することができない。
ｖａプログラムは、複数のパッケージからなることが多
く、パッケージ間のインタラクションのために、いくつ
かのクラス、フィールドまたはメソッドをパブリックに
せざるを得ない。したがって、そのようなプログラムで
は、privateスコープやpackageスコープを用いたアクセ
ス制限を有効に活用することができない。
【００１１】そこで本発明は、名前スコープを用いたア
クセス制限を有効に活用して、保護されるべきリソース
を持つプログラムが不正なプログラムに呼ばれることを
防止できるようにＪａｖａプログラムを編集することを
目的とする。
クセス制限を有効に活用して、保護されるべきリソース
を持つプログラムが不正なプログラムに呼ばれることを
防止できるようにＪａｖａプログラムを編集することを
目的とする。
【００１２】また、本発明は、Ｊａｖａにおけるpackag
eスコープと同様の概念に基づくアクセス制御を実現す
るプログラミング言語において、保護されるべきリソー
スを持つプログラムが不正なプログラムに呼ばれること
を防止できるようにプログラムを編集することを目的と
する。
eスコープと同様の概念に基づくアクセス制御を実現す
るプログラミング言語において、保護されるべきリソー
スを持つプログラムが不正なプログラムに呼ばれること
を防止できるようにプログラムを編集することを目的と
する。
【００１３】
【課題を解決するための手段】かかる目的のもと、本発
明は、オブジェクト指向プログラミング言語で記述され
たプログラムの編集方法において、このオブジェクト指
向プログラミング言語は、一定の参照範囲を設定した場
合にこの参照範囲内のみでの相互参照を認めるパッケー
ジの概念を持っていること、及びアクセス要求者の身元
を特定する身元情報に基づいてアクセス権限を取得する
アクセス制御システムを持っていること、という二つの
条件を満足する言語であり、複数のクラスにて構成され
たアプリケーションプログラムに対し、各クラスに付さ
れたパッケージ名を単一のパッケージ名に置き換えるス
テップと、前記クラス中の、アプリケーションプログラ
ムの外部から参照されない内部化可能なデータにおける
属性を、同一パッケージ内からの参照を受け付けるよう
に変更するステップと、このパッケージ名の置き換えス
テップとこのデータ属性の変更ステップとを経たアプリ
ケーションプログラムに対して、アクセス要求者の身元
を特定する身元情報に基づくアクセス権限を取得させる
ステップとを含むことを特徴としている。このような構
成とすれば、システムクラスとの間で参照を行うような
内部化可能でないメソッド、変数などを除き、同一パッ
ケージ内からの参照を受け付けるように変更されたデー
タは、このアプリケーションプログラムと同一のアクセ
ス権限を取得したプログラム以外からのアクセスは受け
付けなくなる。そこで、一つのパッケージに対するアク
セス権限の取得者を一つに限定する原則を採用すれば、
このデータに対して、このアプリケーションプログラム
の外部からのアクセスが一切できなくなるため、外部か
らの不正なアクセスを防止できる。
明は、オブジェクト指向プログラミング言語で記述され
たプログラムの編集方法において、このオブジェクト指
向プログラミング言語は、一定の参照範囲を設定した場
合にこの参照範囲内のみでの相互参照を認めるパッケー
ジの概念を持っていること、及びアクセス要求者の身元
を特定する身元情報に基づいてアクセス権限を取得する
アクセス制御システムを持っていること、という二つの
条件を満足する言語であり、複数のクラスにて構成され
たアプリケーションプログラムに対し、各クラスに付さ
れたパッケージ名を単一のパッケージ名に置き換えるス
テップと、前記クラス中の、アプリケーションプログラ
ムの外部から参照されない内部化可能なデータにおける
属性を、同一パッケージ内からの参照を受け付けるよう
に変更するステップと、このパッケージ名の置き換えス
テップとこのデータ属性の変更ステップとを経たアプリ
ケーションプログラムに対して、アクセス要求者の身元
を特定する身元情報に基づくアクセス権限を取得させる
ステップとを含むことを特徴としている。このような構
成とすれば、システムクラスとの間で参照を行うような
内部化可能でないメソッド、変数などを除き、同一パッ
ケージ内からの参照を受け付けるように変更されたデー
タは、このアプリケーションプログラムと同一のアクセ
ス権限を取得したプログラム以外からのアクセスは受け
付けなくなる。そこで、一つのパッケージに対するアク
セス権限の取得者を一つに限定する原則を採用すれば、
このデータに対して、このアプリケーションプログラム
の外部からのアクセスが一切できなくなるため、外部か
らの不正なアクセスを防止できる。
【００１４】ここで、パッケージ名の置き換えステップ
によりパッケージ名を置き換えた結果、アプリケーショ
ンプログラム中の所定のクラスにおけるクラス名が同一
となる場合に、このクラスのクラス名を変更するステッ
プをさらに含むこととすることができる。このような構
成とすれば、異なるパッケージに同一のクラス名を持つ
クラスが存在している場合にも、このアプリケーション
プログラムのシングルパッケージ化を行える点で好まし
い。
によりパッケージ名を置き換えた結果、アプリケーショ
ンプログラム中の所定のクラスにおけるクラス名が同一
となる場合に、このクラスのクラス名を変更するステッ
プをさらに含むこととすることができる。このような構
成とすれば、異なるパッケージに同一のクラス名を持つ
クラスが存在している場合にも、このアプリケーション
プログラムのシングルパッケージ化を行える点で好まし
い。
【００１５】このクラス名変更ステップは、所定のクラ
スのクラス名を変更するために、パッケージ名の置き換
えステップによる変更前のこのクラスが属するパッケー
ジ名に用いられた文字列を用いて新たなクラス名を生成
することができる。このような構成とすれば、衝突を回
避する新たなクラス名を機械的に生成できる点で好まし
い。パッケージ名に用いられた文字列を用いて新たなク
ラス名を生成する具体的な手法としては、例えば、パッ
ケージ名のドットをアンダースコア（下線）に置き換え
てそのまま用いるといった方法を採ることができる。ま
た、確実に衝突を回避するために、どのクラス名にも現
れない文字列を新たなクラス名に追加するようにしても
良い。
スのクラス名を変更するために、パッケージ名の置き換
えステップによる変更前のこのクラスが属するパッケー
ジ名に用いられた文字列を用いて新たなクラス名を生成
することができる。このような構成とすれば、衝突を回
避する新たなクラス名を機械的に生成できる点で好まし
い。パッケージ名に用いられた文字列を用いて新たなク
ラス名を生成する具体的な手法としては、例えば、パッ
ケージ名のドットをアンダースコア（下線）に置き換え
てそのまま用いるといった方法を採ることができる。ま
た、確実に衝突を回避するために、どのクラス名にも現
れない文字列を新たなクラス名に追加するようにしても
良い。
【００１６】またここで、パッケージ名を変更した際に
重複するクラス名が存在するかどうかを検出せず、機械
的に、このアプリケーションプログラム中のクラスのク
ラス名を、相互に重複しない固有のクラス名に変更する
ステップをさらに含むこととすることができる。クラス
名を変更する具体的な手法としては、例えば、各クラス
に連続番号を振るといった方法を採ることができる。
重複するクラス名が存在するかどうかを検出せず、機械
的に、このアプリケーションプログラム中のクラスのク
ラス名を、相互に重複しない固有のクラス名に変更する
ステップをさらに含むこととすることができる。クラス
名を変更する具体的な手法としては、例えば、各クラス
に連続番号を振るといった方法を採ることができる。
【００１７】また、本発明によれば、Ｊａｖａのプログ
ラムをシングルパッケージ化する、次のようなシングル
パッケージ化システムを実現することができる。すなわ
ち、複数のクラスにて構成されたＪａｖａのプログラム
を入力する入力手段と、この入力手段にて入力されたプ
ログラム中の、各クラスが属するパッケージのパッケー
ジ名を単一のパッケージ名に置き換えるパッケージ名置
き換え手段と、前記クラス中の、このプログラムの外部
から参照されない内部化可能なデータの名前スコープ
を、パッケージスコープに変更する名前スコープ変更手
段と、このパッケージ名の置き換えとこの名前スコープ
の変更とが行われたプログラムを出力する出力手段とを
備える。このような構成とすれば、このプログラム中の
メッセージや変数のうちで、このプログラムの中でのみ
参照が行われるものに関しては、このプログラム全体を
含む単一のパッケージの外部からのアクセスを受け付け
なくなる。したがって、このプログラムに電子署名を施
し、一つのパッケージにおける署名者をただ一人だけと
する１パッケージ１署名者の原則を併せて採用すること
により、このメッセージや変数に対して、このプログラ
ムの外部からのアクセスが一切できなくなるため、外部
からの不正なアクセスを防止できる。
ラムをシングルパッケージ化する、次のようなシングル
パッケージ化システムを実現することができる。すなわ
ち、複数のクラスにて構成されたＪａｖａのプログラム
を入力する入力手段と、この入力手段にて入力されたプ
ログラム中の、各クラスが属するパッケージのパッケー
ジ名を単一のパッケージ名に置き換えるパッケージ名置
き換え手段と、前記クラス中の、このプログラムの外部
から参照されない内部化可能なデータの名前スコープ
を、パッケージスコープに変更する名前スコープ変更手
段と、このパッケージ名の置き換えとこの名前スコープ
の変更とが行われたプログラムを出力する出力手段とを
備える。このような構成とすれば、このプログラム中の
メッセージや変数のうちで、このプログラムの中でのみ
参照が行われるものに関しては、このプログラム全体を
含む単一のパッケージの外部からのアクセスを受け付け
なくなる。したがって、このプログラムに電子署名を施
し、一つのパッケージにおける署名者をただ一人だけと
する１パッケージ１署名者の原則を併せて採用すること
により、このメッセージや変数に対して、このプログラ
ムの外部からのアクセスが一切できなくなるため、外部
からの不正なアクセスを防止できる。
【００１８】したがって、このシングルパッケージ化シ
ステムは、パッケージ名の置き換えと名前スコープの変
更とが行われたプログラムに対して、電子署名を行う電
子署名手段をさらに備えた構成とすることができる。
ステムは、パッケージ名の置き換えと名前スコープの変
更とが行われたプログラムに対して、電子署名を行う電
子署名手段をさらに備えた構成とすることができる。
【００１９】さらに、このシングルパッケージ化システ
ムは、クラス名及びクラス中の内部化可能なデータにお
ける名前スコープの名前リストを作成する名前リスト作
成手段と、この名前リスト作成手段にて作成された名前
リスト中において、パッケージ名置き換え手段によるパ
ッケージ名の置き換えによって、同一となるクラス名を
検出し、このクラス名の重複を回避するようにこの名前
リストにおけるクラス名を変更する名前衝突回避手段と
をさらに備え、名前スコープ変更手段は、この名前リス
トを参照して名前スコープを変更し、かつクラス名を衝
突の回避されたクラス名に変更する構成とすることがで
きる。このような構成とすれば、シングルパッケージ化
前のプログラムにおける異なるパッケージに同一のクラ
ス名を持つクラスが存在している場合にも、このプログ
ラムのシングルパッケージ化を行える点で好ましい。
ムは、クラス名及びクラス中の内部化可能なデータにお
ける名前スコープの名前リストを作成する名前リスト作
成手段と、この名前リスト作成手段にて作成された名前
リスト中において、パッケージ名置き換え手段によるパ
ッケージ名の置き換えによって、同一となるクラス名を
検出し、このクラス名の重複を回避するようにこの名前
リストにおけるクラス名を変更する名前衝突回避手段と
をさらに備え、名前スコープ変更手段は、この名前リス
トを参照して名前スコープを変更し、かつクラス名を衝
突の回避されたクラス名に変更する構成とすることがで
きる。このような構成とすれば、シングルパッケージ化
前のプログラムにおける異なるパッケージに同一のクラ
ス名を持つクラスが存在している場合にも、このプログ
ラムのシングルパッケージ化を行える点で好ましい。
【００２０】また、本発明は、Ｊａｖａのプログラムを
開発するためのプログラム開発システムにおいて、複数
のクラスにて構成されたプログラムに対し、各クラスが
属するパッケージのパッケージ名を単一のパッケージ名
に置き換えるパッケージ名置き換え手段と、前記クラス
中の、このプログラムの外部から参照されない内部化可
能なデータの名前スコープを、パッケージスコープに変
更する名前スコープ変更手段と、このパッケージ名の置
き換えとこの名前スコープの変更が行われたプログラム
に対して、電子署名を行う電子署名手段とを備えたこと
を特徴としている。このような構成とすれば、Ｊａｖａ
によるプログラム開発の最終段階において、作成された
プログラムをシングルパッケージ化して電子署名を施す
ことができる点で好ましい。
開発するためのプログラム開発システムにおいて、複数
のクラスにて構成されたプログラムに対し、各クラスが
属するパッケージのパッケージ名を単一のパッケージ名
に置き換えるパッケージ名置き換え手段と、前記クラス
中の、このプログラムの外部から参照されない内部化可
能なデータの名前スコープを、パッケージスコープに変
更する名前スコープ変更手段と、このパッケージ名の置
き換えとこの名前スコープの変更が行われたプログラム
に対して、電子署名を行う電子署名手段とを備えたこと
を特徴としている。このような構成とすれば、Ｊａｖａ
によるプログラム開発の最終段階において、作成された
プログラムをシングルパッケージ化して電子署名を施す
ことができる点で好ましい。
【００２１】ここで、クラス名及びクラス中の内部化可
能なデータにおける名前スコープの名前リストを作成す
る名前リスト作成手段と、この名前リスト作成手段にて
作成された名前リスト中において、パッケージ名置き換
え手段によるパッケージ名の置き換えによって、同一と
なるクラス名を検出し、このクラス名の重複を回避する
ようにこの名前リストにおけるクラス名を変更する名前
衝突回避手段とをさらに備え、名前スコープ変更手段
は、この名前リストを参照して名前スコープを変更し、
かつクラス名を衝突の回避されたクラス名に変更するこ
ととしている。このような構成とすれば、シングルパッ
ケージ化前のプログラムにおける異なるパッケージに同
一のクラス名を持つクラスが存在している場合にも、こ
のプログラムのシングルパッケージ化を行える点で好ま
しい。
能なデータにおける名前スコープの名前リストを作成す
る名前リスト作成手段と、この名前リスト作成手段にて
作成された名前リスト中において、パッケージ名置き換
え手段によるパッケージ名の置き換えによって、同一と
なるクラス名を検出し、このクラス名の重複を回避する
ようにこの名前リストにおけるクラス名を変更する名前
衝突回避手段とをさらに備え、名前スコープ変更手段
は、この名前リストを参照して名前スコープを変更し、
かつクラス名を衝突の回避されたクラス名に変更するこ
ととしている。このような構成とすれば、シングルパッ
ケージ化前のプログラムにおける異なるパッケージに同
一のクラス名を持つクラスが存在している場合にも、こ
のプログラムのシングルパッケージ化を行える点で好ま
しい。
【００２２】また、本発明によれば、プログラムに対し
て身元情報を付加する、次のような身元情報付加システ
ムを実現することができる。すなわち、一定の参照範囲
を設定した場合にこの参照範囲内のみでの相互参照を認
めるパッケージの概念を持ち、各々所定の当該パッケー
ジに属する複数のクラスにて構成されたアプリケーショ
ンプログラムを入力する入力手段と、この入力手段にて
入力されたこのアプリケーションプログラムにおける各
クラスが属するパッケージのパッケージ名を単一のパッ
ケージ名に置き換えるパッケージ名置き換え手段と、前
記クラス中の、このアプリケーションプログラムの外部
から参照されない内部化可能なデータにおける属性を、
同一パッケージ内からの参照を受け付けるように変更す
る属性変更手段と、このパッケージ名の置き換えとこの
データ属性の変更とが行われたアプリケーションプログ
ラムに対して、アクセス要求者の身元を特定する身元情
報を付加してこの身元情報に基づくアクセス権限を取得
させる身元情報付加手段と、この身元情報を付加された
アプリケーションプログラムを出力する出力手段とを備
える。このような構成とすれば、作成されたアプリケー
ションプログラムに対してアクセス権限を取得するため
の身元情報の付加を行う際に、このアプリケーションプ
ログラムをシングルパッケージ化することができる点で
好ましい。
て身元情報を付加する、次のような身元情報付加システ
ムを実現することができる。すなわち、一定の参照範囲
を設定した場合にこの参照範囲内のみでの相互参照を認
めるパッケージの概念を持ち、各々所定の当該パッケー
ジに属する複数のクラスにて構成されたアプリケーショ
ンプログラムを入力する入力手段と、この入力手段にて
入力されたこのアプリケーションプログラムにおける各
クラスが属するパッケージのパッケージ名を単一のパッ
ケージ名に置き換えるパッケージ名置き換え手段と、前
記クラス中の、このアプリケーションプログラムの外部
から参照されない内部化可能なデータにおける属性を、
同一パッケージ内からの参照を受け付けるように変更す
る属性変更手段と、このパッケージ名の置き換えとこの
データ属性の変更とが行われたアプリケーションプログ
ラムに対して、アクセス要求者の身元を特定する身元情
報を付加してこの身元情報に基づくアクセス権限を取得
させる身元情報付加手段と、この身元情報を付加された
アプリケーションプログラムを出力する出力手段とを備
える。このような構成とすれば、作成されたアプリケー
ションプログラムに対してアクセス権限を取得するため
の身元情報の付加を行う際に、このアプリケーションプ
ログラムをシングルパッケージ化することができる点で
好ましい。
【００２３】ここで、この身元情報付加システムにて付
加される身元情報として、電子署名を用いることができ
る。このようにすれば、既に現存する電子署名に基づい
てアクセス権限を取得するアクセス制御システムに本発
明を適用することができる点で好ましい。
加される身元情報として、電子署名を用いることができ
る。このようにすれば、既に現存する電子署名に基づい
てアクセス権限を取得するアクセス制御システムに本発
明を適用することができる点で好ましい。
【００２４】また、本発明は、一定の参照範囲を設定し
た場合にこの参照範囲内のみでの相互参照を認めるパッ
ケージの概念を持つオブジェクト指向プログラミング言
語で記述されたプログラムを対象として、コンピュータ
に当該プログラムを編集させる編集プログラムにおい
て、各々所定のパッケージに属する複数のクラスにて構
成されたアプリケーションプログラムに対し、各クラス
が属するパッケージのパッケージ名を単一のパッケージ
名に置き換える処理と、前記クラス中の、このアプリケ
ーションプログラムの外部から参照されない内部化可能
なデータにおける属性を、同一パッケージ内からの参照
を受け付けるように変更する処理とを含むことを特徴と
している。
た場合にこの参照範囲内のみでの相互参照を認めるパッ
ケージの概念を持つオブジェクト指向プログラミング言
語で記述されたプログラムを対象として、コンピュータ
に当該プログラムを編集させる編集プログラムにおい
て、各々所定のパッケージに属する複数のクラスにて構
成されたアプリケーションプログラムに対し、各クラス
が属するパッケージのパッケージ名を単一のパッケージ
名に置き換える処理と、前記クラス中の、このアプリケ
ーションプログラムの外部から参照されない内部化可能
なデータにおける属性を、同一パッケージ内からの参照
を受け付けるように変更する処理とを含むことを特徴と
している。
【００２５】ここで、このパッケージ名の置き換え処理
により、パッケージ名を置き換えた結果、このアプリケ
ーションプログラム中の所定のクラスにおけるクラス名
が同一となる場合に、このクラスのクラス名を変更する
処理をさらに含むことができる。これにより、異なるパ
ッケージに同一のクラス名を持つクラスが存在している
場合にも、このプログラムのシングルパッケージ化を行
える点で好ましい。
により、パッケージ名を置き換えた結果、このアプリケ
ーションプログラム中の所定のクラスにおけるクラス名
が同一となる場合に、このクラスのクラス名を変更する
処理をさらに含むことができる。これにより、異なるパ
ッケージに同一のクラス名を持つクラスが存在している
場合にも、このプログラムのシングルパッケージ化を行
える点で好ましい。
【００２６】また、本発明は、コンピュータに実行させ
るプログラムをこのコンピュータの入力手段が読取可能
に記憶した記憶媒体において、このプログラムは、複数
のクラスにて構成されたＪａｖａのアプリケーションプ
ログラム中の、各クラスが属するパッケージのパッケー
ジ名を単一のパッケージ名に置き換える処理と、前記ク
ラス中の、このアプリケーションプログラムの外部から
参照されない内部化可能なデータの名前スコープを、パ
ッケージスコープに変更する処理とをこのコンピュータ
に実行させることを特徴としている。このような構成と
すれば、このプログラムをインストールした全てのコン
ピュータにおいて、Ｊａｖａのプログラムのシングルパ
ッケージ化を行うことができる点で好ましい。
るプログラムをこのコンピュータの入力手段が読取可能
に記憶した記憶媒体において、このプログラムは、複数
のクラスにて構成されたＪａｖａのアプリケーションプ
ログラム中の、各クラスが属するパッケージのパッケー
ジ名を単一のパッケージ名に置き換える処理と、前記ク
ラス中の、このアプリケーションプログラムの外部から
参照されない内部化可能なデータの名前スコープを、パ
ッケージスコープに変更する処理とをこのコンピュータ
に実行させることを特徴としている。このような構成と
すれば、このプログラムをインストールした全てのコン
ピュータにおいて、Ｊａｖａのプログラムのシングルパ
ッケージ化を行うことができる点で好ましい。
【００２７】ここで、このパッケージ名の置き換え処理
により、パッケージ名を置き換えた結果、このアプリケ
ーションプログラム中の所定のクラスにおけるクラス名
が同一となる場合に、このクラスのクラス名を変更する
処理をさらに含むこととすることができる。
により、パッケージ名を置き換えた結果、このアプリケ
ーションプログラム中の所定のクラスにおけるクラス名
が同一となる場合に、このクラスのクラス名を変更する
処理をさらに含むこととすることができる。
【００２８】また、本発明は、コンピュータに、複数の
クラスにて構成されたＪａｖａのアプリケーションプロ
グラム中の、各クラスが属するパッケージのパッケージ
名を単一のパッケージ名に置き換える処理と、前記クラ
ス中の、このアプリケーションプログラムの外部から参
照されない内部化可能なデータの名前スコープを、パッ
ケージスコープに変更する処理とを実行させるプログラ
ムを記憶する記憶手段と、この記憶手段からこのプログ
ラムを読み出してこのプログラムを送信する送信手段と
を備えたことを特徴としている。このような構成とする
ことにより、このプログラムをダウンロードした全ての
コンピュータにおいて、Ｊａｖａのプログラムのシング
ルパッケージ化を行うことができる点で好ましい。
クラスにて構成されたＪａｖａのアプリケーションプロ
グラム中の、各クラスが属するパッケージのパッケージ
名を単一のパッケージ名に置き換える処理と、前記クラ
ス中の、このアプリケーションプログラムの外部から参
照されない内部化可能なデータの名前スコープを、パッ
ケージスコープに変更する処理とを実行させるプログラ
ムを記憶する記憶手段と、この記憶手段からこのプログ
ラムを読み出してこのプログラムを送信する送信手段と
を備えたことを特徴としている。このような構成とする
ことにより、このプログラムをダウンロードした全ての
コンピュータにおいて、Ｊａｖａのプログラムのシング
ルパッケージ化を行うことができる点で好ましい。
【００２９】ここで、このパッケージ名の置き換え処理
により、パッケージ名を置き換えた結果、このアプリケ
ーションプログラム中の所定のクラスにおけるクラス名
が同一となる場合に、このクラスのクラス名を変更する
処理をさらに含むこととすることができる。
により、パッケージ名を置き換えた結果、このアプリケ
ーションプログラム中の所定のクラスにおけるクラス名
が同一となる場合に、このクラスのクラス名を変更する
処理をさらに含むこととすることができる。
【００３０】
【発明の実施の形態】以下、添付図面に示す実施の形態
に基づいてこの発明を詳細に説明する。本発明によるプ
ログラムのシングルパッケージ化は、次の三つの条件を
満たすオブジェクト指向のプログラミング言語に対して
実施することができる。すなわち、パッケージの概念を
持っていること、アクセス要求者の身元を特定する情報
に基づいてアクセス権限を取得するアクセス制御システ
ムを持っていること、一つのパッケージに対するアクセ
ス権限の取得者を一つに限定する原則を遵守することで
ある。
に基づいてこの発明を詳細に説明する。本発明によるプ
ログラムのシングルパッケージ化は、次の三つの条件を
満たすオブジェクト指向のプログラミング言語に対して
実施することができる。すなわち、パッケージの概念を
持っていること、アクセス要求者の身元を特定する情報
に基づいてアクセス権限を取得するアクセス制御システ
ムを持っていること、一つのパッケージに対するアクセ
ス権限の取得者を一つに限定する原則を遵守することで
ある。
【００３１】ここで、パッケージとは、他のプログラム
から参照できる範囲（visibility）を定義する概念であ
る。パッケージと宣言されたフィールドやメソッドは、
当該フィールドやメソッドの置かれたパッケージ内から
でなければ参照することができないこととする。ただ
し、ここで要求されるのは、アクセス権限を制御する機
能であって、ここで述べたパッケージは、特定のプログ
ラムにおける特定のフォーマットを指すものではない。
したがって、実質的に上述した他のプログラムからの参
照範囲を定義する機能を持つものであれば、その書式な
どは問わない。
から参照できる範囲（visibility）を定義する概念であ
る。パッケージと宣言されたフィールドやメソッドは、
当該フィールドやメソッドの置かれたパッケージ内から
でなければ参照することができないこととする。ただ
し、ここで要求されるのは、アクセス権限を制御する機
能であって、ここで述べたパッケージは、特定のプログ
ラムにおける特定のフォーマットを指すものではない。
したがって、実質的に上述した他のプログラムからの参
照範囲を定義する機能を持つものであれば、その書式な
どは問わない。
【００３２】また、アクセス要求者の身元を特定する情
報としては、例えば、公開鍵暗号方式を応用したアクセ
ス制御方式である電子署名を用いることができる。すな
わち、電子署名に基づいてアクセス権限を取得するアク
セス制御システムを持つことは、上記の条件を満たす。
報としては、例えば、公開鍵暗号方式を応用したアクセ
ス制御方式である電子署名を用いることができる。すな
わち、電子署名に基づいてアクセス権限を取得するアク
セス制御システムを持つことは、上記の条件を満たす。
【００３３】さらにまた、一つのパッケージに対するア
クセス権限の取得者を一つに限定するとは、例えば、電
子署名を用いたアクセス制御を行うシステムでは、一つ
のパッケージに対する署名を一つに制限するということ
である。すなわち、所定のプログラムに対して署名がな
されている場合は、署名されていない他のプログラムが
当該署名されたプログラムと同一のパッケージに参加
（アクセス）することを拒絶することを意味する。
クセス権限の取得者を一つに限定するとは、例えば、電
子署名を用いたアクセス制御を行うシステムでは、一つ
のパッケージに対する署名を一つに制限するということ
である。すなわち、所定のプログラムに対して署名がな
されている場合は、署名されていない他のプログラムが
当該署名されたプログラムと同一のパッケージに参加
（アクセス）することを拒絶することを意味する。
【００３４】このような条件を満足するプログラミング
言語として、Ｊａｖａ 1.2.2がある。そこで、本実施の
形態では、Ｊａｖａ 1.2.2を対象として本発明を適用し
た場合について説明する。以下、上述したパッケージ
も、Ｊａｖａにおける名前スコープの一つとしてのpack
ageスコープを意味するものとする。ただし、本発明
は、上記の条件を実質的に満足する全てのプログラミン
グ言語に対して適用可能であることは言うまでもない。
言語として、Ｊａｖａ 1.2.2がある。そこで、本実施の
形態では、Ｊａｖａ 1.2.2を対象として本発明を適用し
た場合について説明する。以下、上述したパッケージ
も、Ｊａｖａにおける名前スコープの一つとしてのpack
ageスコープを意味するものとする。ただし、本発明
は、上記の条件を実質的に満足する全てのプログラミン
グ言語に対して適用可能であることは言うまでもない。
【００３５】図１は、本実施の形態におけるプログラム
のシングルパッケージ化の方法を説明するフローチャー
トである。図１を参照すると、本実施の形態によれば、
まず、シングルパッケージ化の対象であるプログラム中
の全てのパッケージ名を、単一のパッケージ名で置き換
える（ステップ１０１）。例えば、所定のアプリケーシ
ョンプログラムＡが、複数（ｋ個）のクラスとして開発
され、Ｐ１、Ｐ２、…Ｐｋというパッケージに属してい
るものとする。この場合、これらのパッケージ名を単一
のパッケージ名Ｐ０で置き換える。
のシングルパッケージ化の方法を説明するフローチャー
トである。図１を参照すると、本実施の形態によれば、
まず、シングルパッケージ化の対象であるプログラム中
の全てのパッケージ名を、単一のパッケージ名で置き換
える（ステップ１０１）。例えば、所定のアプリケーシ
ョンプログラムＡが、複数（ｋ個）のクラスとして開発
され、Ｐ１、Ｐ２、…Ｐｋというパッケージに属してい
るものとする。この場合、これらのパッケージ名を単一
のパッケージ名Ｐ０で置き換える。
【００３６】また、当該プログラム中の全ての内部化可
能な名前スコープをpackageスコープで置き換える（ス
テップ１０２）。ここで、内部化可能な名前スコープと
は、当該名前を持つフィールドやメソッドが当該プログ
ラムの外部から参照されていないものであることを言
う。上記プログラムＡの例では、パッケージＰ１、Ｐ
２、…Ｐｋの各クラスが作成された時点で、パッケージ
間あるいは他のプログラム（例えばシステムクラス）と
のインタラクションのために、各パッケージには、publ
icやprotectedな名前がいくつかある（これらを外部名
と呼ぶことにする）。これらのうちで、当該プログラム
Ａの外部から参照されていないもの全てをpackageスコ
ープで置き換える。なお、ステップ１０１、１０２の処
理は、いずれを先に行っても良いし、並列に行っても良
い。
能な名前スコープをpackageスコープで置き換える（ス
テップ１０２）。ここで、内部化可能な名前スコープと
は、当該名前を持つフィールドやメソッドが当該プログ
ラムの外部から参照されていないものであることを言
う。上記プログラムＡの例では、パッケージＰ１、Ｐ
２、…Ｐｋの各クラスが作成された時点で、パッケージ
間あるいは他のプログラム（例えばシステムクラス）と
のインタラクションのために、各パッケージには、publ
icやprotectedな名前がいくつかある（これらを外部名
と呼ぶことにする）。これらのうちで、当該プログラム
Ａの外部から参照されていないもの全てをpackageスコ
ープで置き換える。なお、ステップ１０１、１０２の処
理は、いずれを先に行っても良いし、並列に行っても良
い。
【００３７】次に、パッケージ名が置き換えられたこと
によってクラス名の衝突が発生したかどうかを調べ、衝
突が発生したならば、当該クラス名を変更して当該衝突
を回避する（ステップ１０３、１０４）。ここで、クラ
ス名が衝突するとは、本来複数のパッケージにおいて別
個に付されていたクラス名が、パッケージ名が置き換え
られたことによって、同一の名前になって重複してしま
うことである。例えば、シングルパッケージ化を行う前
の２つのパッケージＰi、Ｐjにおいて、名前Ｃを持つク
ラスがそれぞれ存在するとする（例えば、Ｐi.ＣとＰj.
Ｃ）。この場合、パッケージ名を共通にすることによっ
て、二つのクラス名が衝突してしまう（例えば、パッケ
ージ名をＰ０とした場合、いずれのクラス名もＰ０.Ｃ
となってしまう）。そこで、クラス名の衝突を回避する
ように名前の付け替えを行う。
によってクラス名の衝突が発生したかどうかを調べ、衝
突が発生したならば、当該クラス名を変更して当該衝突
を回避する（ステップ１０３、１０４）。ここで、クラ
ス名が衝突するとは、本来複数のパッケージにおいて別
個に付されていたクラス名が、パッケージ名が置き換え
られたことによって、同一の名前になって重複してしま
うことである。例えば、シングルパッケージ化を行う前
の２つのパッケージＰi、Ｐjにおいて、名前Ｃを持つク
ラスがそれぞれ存在するとする（例えば、Ｐi.ＣとＰj.
Ｃ）。この場合、パッケージ名を共通にすることによっ
て、二つのクラス名が衝突してしまう（例えば、パッケ
ージ名をＰ０とした場合、いずれのクラス名もＰ０.Ｃ
となってしまう）。そこで、クラス名の衝突を回避する
ように名前の付け替えを行う。
【００３８】クラス名の付け替え方法としては、種々の
方法が考えられるが、ここでは、機械的な処理で実現で
きる次の方法を例示する。まず、プログラムＡの中で、
どのクラス名にも現れない文字（または文字列）を一つ
選んでおき、これをαとする。このようなαが有限のプ
ログラムで選べることは自明である。そして、Ｐi.Ｃと
Ｐj.Ｃの二つのクラスには、以下のようなクラス名を割
り当てる。ただし、以下の説明において、「＋」は文字
列の連結を表わし、replace_dot（β）は、文字列βの
中のドット（．）を、下線（＿）に置き換えた文字列を
表わす。 パッケージＰi中のクラスＣ（Ｐi.Ｃ）＆rarr； クラス名α＋"_"＋replace_dot（Ｐi）＋"_"＋Ｃ パッケージＰj中のクラスＣ（Ｐj.Ｃ）＆rarr； クラス名α＋"_"＋replace_dot（Ｐj）＋"_"＋Ｃ このようにして、新しいクラス名には、元のパッケージ
名で用いられていた文字列とどのクラス名にも現れない
文字とが当てられるため、名前が異なることとなり、衝
突が回避される。
方法が考えられるが、ここでは、機械的な処理で実現で
きる次の方法を例示する。まず、プログラムＡの中で、
どのクラス名にも現れない文字（または文字列）を一つ
選んでおき、これをαとする。このようなαが有限のプ
ログラムで選べることは自明である。そして、Ｐi.Ｃと
Ｐj.Ｃの二つのクラスには、以下のようなクラス名を割
り当てる。ただし、以下の説明において、「＋」は文字
列の連結を表わし、replace_dot（β）は、文字列βの
中のドット（．）を、下線（＿）に置き換えた文字列を
表わす。 パッケージＰi中のクラスＣ（Ｐi.Ｃ）＆rarr； クラス名α＋"_"＋replace_dot（Ｐi）＋"_"＋Ｃ パッケージＰj中のクラスＣ（Ｐj.Ｃ）＆rarr； クラス名α＋"_"＋replace_dot（Ｐj）＋"_"＋Ｃ このようにして、新しいクラス名には、元のパッケージ
名で用いられていた文字列とどのクラス名にも現れない
文字とが当てられるため、名前が異なることとなり、衝
突が回避される。
【００３９】なお、上述したクラス名の変更方法は、一
例に過ぎない。上記の例では元のパッケージ名における
ドットを下線に置き換えたが、他のどのような規則に基
づく変更であってもかまわない。また、元のパッケージ
名で用いられた文字列を用いるほか、連続番号を用いて
クラス名を生成するなどの方法を用いることもできる。
さらに、パッケージ名を置き換えたことによってクラス
名の衝突が発生することを防ぐためには、上記のように
衝突するクラス名を検出して当該クラス名を変更する他
に、プログラム中の全てのクラスに対して、連続番号な
どを用いた重複のないクラス名を生成して付する用にし
ても良い。この場合、ステップ１０３の判断処理は不要
となり、ステップ１０４において全てのクラスのクラス
名を変更することとなる。
例に過ぎない。上記の例では元のパッケージ名における
ドットを下線に置き換えたが、他のどのような規則に基
づく変更であってもかまわない。また、元のパッケージ
名で用いられた文字列を用いるほか、連続番号を用いて
クラス名を生成するなどの方法を用いることもできる。
さらに、パッケージ名を置き換えたことによってクラス
名の衝突が発生することを防ぐためには、上記のように
衝突するクラス名を検出して当該クラス名を変更する他
に、プログラム中の全てのクラスに対して、連続番号な
どを用いた重複のないクラス名を生成して付する用にし
ても良い。この場合、ステップ１０３の判断処理は不要
となり、ステップ１０４において全てのクラスのクラス
名を変更することとなる。
【００４０】最後に、以上のようにして単一のパッケー
ジ名で括られた当該プログラムに対して電子署名を行う
（ステップ１０５）。電子署名は、プログラムをシング
ルパッケージ化する処理とは別個の処理であるが、本実
施の形態におけるプログラムのシングルパッケージ化を
セキュリティー手段として実効あらしめるために、必要
不可欠な処理である。すなわち、プログラムをシングル
パッケージ化したのみでは、他のプログラムが当該プロ
グラムと同一の名前のパッケージを宣言することによっ
て当該プログラムに参加するPackage Joining Attackを
防止することができない。そこで、シングルパッケージ
化によりパッケージ間相互の参照だけのために設定され
た外部名をpackageスコープで置き換え、同一パッケー
ジ以外からの参照ができないようにした上で、電子署名
を行い、一つのパッケージにおける署名者を一人だけと
する１パッケージ１署名者の原則に基づいてPackage Jo
ining Attackを防止する。これにより、パッケージ間相
互の参照だけのために設定された外部名に関しては、外
部からのアクセスを拒絶できることとなる。
ジ名で括られた当該プログラムに対して電子署名を行う
（ステップ１０５）。電子署名は、プログラムをシング
ルパッケージ化する処理とは別個の処理であるが、本実
施の形態におけるプログラムのシングルパッケージ化を
セキュリティー手段として実効あらしめるために、必要
不可欠な処理である。すなわち、プログラムをシングル
パッケージ化したのみでは、他のプログラムが当該プロ
グラムと同一の名前のパッケージを宣言することによっ
て当該プログラムに参加するPackage Joining Attackを
防止することができない。そこで、シングルパッケージ
化によりパッケージ間相互の参照だけのために設定され
た外部名をpackageスコープで置き換え、同一パッケー
ジ以外からの参照ができないようにした上で、電子署名
を行い、一つのパッケージにおける署名者を一人だけと
する１パッケージ１署名者の原則に基づいてPackage Jo
ining Attackを防止する。これにより、パッケージ間相
互の参照だけのために設定された外部名に関しては、外
部からのアクセスを拒絶できることとなる。
【００４１】図２は、上述したプログラムのシングルパ
ッケージ化の処理を実行するシステムの構成例を説明す
る図である。このようなシステムは、ＪＤＫ（Java Dev
elopers Kit）に組み込まれたり、生成されたアプリケ
ーションプログラムに署名する電子署名システムの機能
として設けられたりすることにより、実現される。図２
において、符号２１は第１の入力手段であり、複数のク
ラスからなるプログラムと当該プログラムのmanifestを
入力する。符号２２は名前リスト作成手段であり、入力
したプログラムにおける全てのクラス名及び内部化可能
な名前スコープの名前リストを作成する。符号２３は名
前衝突回避手段であり、名前リスト作成手段２２によっ
て作成された名前リスト中のクラス名を、衝突を回避す
るための名前に書き換える。符号２４は、名前リスト作
成手段２２により作成され、名前衝突回避手段２３によ
り名前の書き換えが行われた名前リストである。符号２
５は第２の入力手段であり、再度当該プログラムを入力
する。符号２６は名前置き換え手段であり、名前リスト
２４を参照して当該プログラム中の内部化可能な名前ス
コープをpackageスコープに置き換える。また、名前置
き換え手段２６の処理において、当該プログラムを構成
する各クラスのパッケージ名が単一のパッケージ名に変
更される。この名前の置き換えによって当該プログラム
のシングルパッケージ化が実行される。符号２７は出力
手段であり、名前置き換え手段２６の処理によってシン
グルパッケージ化されたプログラム（Ｐ０）を出力す
る。符号２８は電子署名手段であり、出力されたプログ
ラム（Ｐ０）に対して署名する。これらの各構成要素
は、上述したＪＤＫや電子署名システムを実装したコン
ピュータにおいて、プログラム制御されたＣＰＵ、ＲＡ
Ｍなどの内部メモリ、ハードディスクなどの外部記憶装
置などを用いて実現される。
ッケージ化の処理を実行するシステムの構成例を説明す
る図である。このようなシステムは、ＪＤＫ（Java Dev
elopers Kit）に組み込まれたり、生成されたアプリケ
ーションプログラムに署名する電子署名システムの機能
として設けられたりすることにより、実現される。図２
において、符号２１は第１の入力手段であり、複数のク
ラスからなるプログラムと当該プログラムのmanifestを
入力する。符号２２は名前リスト作成手段であり、入力
したプログラムにおける全てのクラス名及び内部化可能
な名前スコープの名前リストを作成する。符号２３は名
前衝突回避手段であり、名前リスト作成手段２２によっ
て作成された名前リスト中のクラス名を、衝突を回避す
るための名前に書き換える。符号２４は、名前リスト作
成手段２２により作成され、名前衝突回避手段２３によ
り名前の書き換えが行われた名前リストである。符号２
５は第２の入力手段であり、再度当該プログラムを入力
する。符号２６は名前置き換え手段であり、名前リスト
２４を参照して当該プログラム中の内部化可能な名前ス
コープをpackageスコープに置き換える。また、名前置
き換え手段２６の処理において、当該プログラムを構成
する各クラスのパッケージ名が単一のパッケージ名に変
更される。この名前の置き換えによって当該プログラム
のシングルパッケージ化が実行される。符号２７は出力
手段であり、名前置き換え手段２６の処理によってシン
グルパッケージ化されたプログラム（Ｐ０）を出力す
る。符号２８は電子署名手段であり、出力されたプログ
ラム（Ｐ０）に対して署名する。これらの各構成要素
は、上述したＪＤＫや電子署名システムを実装したコン
ピュータにおいて、プログラム制御されたＣＰＵ、ＲＡ
Ｍなどの内部メモリ、ハードディスクなどの外部記憶装
置などを用いて実現される。
【００４２】図２を参照して本実施の形態によるプログ
ラムのシングルパッケージ化の処理の流れを説明する。
図２に示すシステムによる処理は、名前リスト２４を作
成する処理と、作成された名前リスト２４に基づいてプ
ログラム中の必要な名前を置き換える処理の二つの流れ
からなる。名前リスト２４を作成する処理では、まず、
第１の入力手段２１が、処理対象である複数のクラスか
らなるプログラムと当該プログラムのmanifestとを入力
する。そして、名前リスト作成手段２２が、入力された
プログラム中の全てのクラス名及び内部化可能な全ての
名前スコープを抽出して名前リスト２４を作成する。次
に、名前衝突回避手段２３が、名前リスト２４の中か
ら、パッケージ名を共通にした場合に衝突が発生するク
ラス名を検出する。そして、検出した名前を、衝突を回
避するための名前に書き換える。ここで書き換えられる
新しい名前は、上述したように、元のパッケージ名で用
いられた文字列を用いる方法や、連続番号を用いる方法
など種々の方法により生成することができる。
ラムのシングルパッケージ化の処理の流れを説明する。
図２に示すシステムによる処理は、名前リスト２４を作
成する処理と、作成された名前リスト２４に基づいてプ
ログラム中の必要な名前を置き換える処理の二つの流れ
からなる。名前リスト２４を作成する処理では、まず、
第１の入力手段２１が、処理対象である複数のクラスか
らなるプログラムと当該プログラムのmanifestとを入力
する。そして、名前リスト作成手段２２が、入力された
プログラム中の全てのクラス名及び内部化可能な全ての
名前スコープを抽出して名前リスト２４を作成する。次
に、名前衝突回避手段２３が、名前リスト２４の中か
ら、パッケージ名を共通にした場合に衝突が発生するク
ラス名を検出する。そして、検出した名前を、衝突を回
避するための名前に書き換える。ここで書き換えられる
新しい名前は、上述したように、元のパッケージ名で用
いられた文字列を用いる方法や、連続番号を用いる方法
など種々の方法により生成することができる。
【００４３】次に、第２の入力手段２５が、再度処理対
象であるプログラムを読み込む。そして、名前置き換え
手段２６が、名前リスト２４を参照して、入力されたプ
ログラム中の内部化可能な名前スコープをpackageスコ
ープに置き換える。また、当該プログラムを構成する各
クラスのパッケージ名を単一のパッケージ名に変更す
る。名前リスト２４に登録されているクラス名は、名前
衝突回避手段２３によりパッケージ名を統一しても重複
することがないように書き換えられているため、パッケ
ージ名を変更してもクラス名の衝突は起こらない。この
後、このようにしてシングルパッケージ化されたプログ
ラムを出力手段２７が出力する。出力されたプログラム
は、電子署名手段２８にて署名される。以上のように、
名前リスト２４を作成する処理と、プログラムの名前を
実際に置き換える処理とに分けて実行するのは、プログ
ラム中の名前の置き換えが必要な名前スコープを検出す
るために、一旦プログラム全体を見渡す必要があるため
である。したがって、衝突が発生する名前スコープに限
らず、全てのクラス名を変更する手法を取る場合は、名
前リスト２４を作成する処理を行う必要はなく、第１の
入力手段２１、名前リスト作成手段２２及び名前衝突回
避手段２３を省略することができる。
象であるプログラムを読み込む。そして、名前置き換え
手段２６が、名前リスト２４を参照して、入力されたプ
ログラム中の内部化可能な名前スコープをpackageスコ
ープに置き換える。また、当該プログラムを構成する各
クラスのパッケージ名を単一のパッケージ名に変更す
る。名前リスト２４に登録されているクラス名は、名前
衝突回避手段２３によりパッケージ名を統一しても重複
することがないように書き換えられているため、パッケ
ージ名を変更してもクラス名の衝突は起こらない。この
後、このようにしてシングルパッケージ化されたプログ
ラムを出力手段２７が出力する。出力されたプログラム
は、電子署名手段２８にて署名される。以上のように、
名前リスト２４を作成する処理と、プログラムの名前を
実際に置き換える処理とに分けて実行するのは、プログ
ラム中の名前の置き換えが必要な名前スコープを検出す
るために、一旦プログラム全体を見渡す必要があるため
である。したがって、衝突が発生する名前スコープに限
らず、全てのクラス名を変更する手法を取る場合は、名
前リスト２４を作成する処理を行う必要はなく、第１の
入力手段２１、名前リスト作成手段２２及び名前衝突回
避手段２３を省略することができる。
【００４４】次に、具体的なプログラムに対するシング
ルパッケージ化の例を示す。図３は、本実施の形態によ
りプログラムがシングルパッケージ化される様子を示す
図である。図４乃至図６は図３のシングルパッケージ化
される前のプログラムにおける各クラスの内容を示す
図、図７乃至図９はシングルパッケージ化された後の図
４乃至図６に対応する各クラスの内容を示す図である。
以下、これらの図を参照して説明する。
ルパッケージ化の例を示す。図３は、本実施の形態によ
りプログラムがシングルパッケージ化される様子を示す
図である。図４乃至図６は図３のシングルパッケージ化
される前のプログラムにおける各クラスの内容を示す
図、図７乃至図９はシングルパッケージ化された後の図
４乃至図６に対応する各クラスの内容を示す図である。
以下、これらの図を参照して説明する。
【００４５】図３に示す例では、三つのクラスＸ、Ｙ、
Ｘからなるアプリケーションプログラムをシングルパッ
ケージ化する。処理対象である三つのクラスは、それぞ
れ、独立したパッケージcom.ibm.p1、com.ibm.p2、com.
ibm.p3に属している。図４を参照すると、パッケージco
m.ibm.p1に属するクラスＸ（図４ではパッケージ名を付
してcom.ibm.p1.Ｘと表記）には、publicスコープのメ
ソッドが２個存在する。一つはパッケージcom.ibm.p2へ
の呼び出しメソッドであり、もう一つはシステムクラス
から呼ばれるメソッドである。このうち、パッケージco
m.ibm.p2への呼び出しメソッドは内部化可能である。同
様に、図５を参照すると、パッケージcom.ibm.p2に属す
るクラスＹ（図５ではパッケージ名を付してcom.ibm.p
2.Ｙと表記）には、パッケージcom.ibm.p3への呼び出し
メソッドが存在する。また、図６を参照すると、パッケ
ージcom.ibm.p3に属するクラスＸ（図６ではパッケージ
名を付してcom.ibm.p3.Ｘと表記）には、パッケージco
m.ibm.p1への呼び出しメソッドが存在する。これらのメ
ソッドは、いずれもpublicスコープであり、かつ内部化
可能である。また、パッケージcom.ibm.p1に属するクラ
スＸとパッケージcom.ibm.p3に属するクラスＸとは、パ
ッケージ名が共通となった場合にクラス名が重複するこ
ととなる。
Ｘからなるアプリケーションプログラムをシングルパッ
ケージ化する。処理対象である三つのクラスは、それぞ
れ、独立したパッケージcom.ibm.p1、com.ibm.p2、com.
ibm.p3に属している。図４を参照すると、パッケージco
m.ibm.p1に属するクラスＸ（図４ではパッケージ名を付
してcom.ibm.p1.Ｘと表記）には、publicスコープのメ
ソッドが２個存在する。一つはパッケージcom.ibm.p2へ
の呼び出しメソッドであり、もう一つはシステムクラス
から呼ばれるメソッドである。このうち、パッケージco
m.ibm.p2への呼び出しメソッドは内部化可能である。同
様に、図５を参照すると、パッケージcom.ibm.p2に属す
るクラスＹ（図５ではパッケージ名を付してcom.ibm.p
2.Ｙと表記）には、パッケージcom.ibm.p3への呼び出し
メソッドが存在する。また、図６を参照すると、パッケ
ージcom.ibm.p3に属するクラスＸ（図６ではパッケージ
名を付してcom.ibm.p3.Ｘと表記）には、パッケージco
m.ibm.p1への呼び出しメソッドが存在する。これらのメ
ソッドは、いずれもpublicスコープであり、かつ内部化
可能である。また、パッケージcom.ibm.p1に属するクラ
スＸとパッケージcom.ibm.p3に属するクラスＸとは、パ
ッケージ名が共通となった場合にクラス名が重複するこ
ととなる。
【００４６】以上のようなプログラムのシングルパッケ
ージ化を行う。新たなパッケージ名はcom.ibm.p0とす
る。まず、上述したように、パッケージcom.ibm.p1に属
するクラスＸとパッケージcom.ibm.p3に属するクラスＸ
のクラス名が衝突するので、衝突を回避するためにクラ
ス名を変更する。ここで、どのクラス名にも現れない文
字αとして、α＝"Foo"を用いる。これにより、パッケ
ージcom.ibm.p1のクラスＸのクラス名は、Foo_com_ibm_
p1_Ｘとなり、パッケージcom.ibm.p3のクラスＸのクラ
ス名は、Foo_com_ibm_p3_Ｘとなって、衝突が回避され
た。
ージ化を行う。新たなパッケージ名はcom.ibm.p0とす
る。まず、上述したように、パッケージcom.ibm.p1に属
するクラスＸとパッケージcom.ibm.p3に属するクラスＸ
のクラス名が衝突するので、衝突を回避するためにクラ
ス名を変更する。ここで、どのクラス名にも現れない文
字αとして、α＝"Foo"を用いる。これにより、パッケ
ージcom.ibm.p1のクラスＸのクラス名は、Foo_com_ibm_
p1_Ｘとなり、パッケージcom.ibm.p3のクラスＸのクラ
ス名は、Foo_com_ibm_p3_Ｘとなって、衝突が回避され
た。
【００４７】次に、内部化可能なpublicスコープをpack
ageスコープに変更する。図７を参照すると、図４にお
けるパッケージcom.ibm.p2への呼び出しメソッドを含む
publicスコープがpackageスコープに変更され、呼び出
しメソッドは同一パッケージのクラスＹへの呼び出しメ
ソッドに変更されている。システムクラスから呼ばれる
メソッドについては、内部化可能でないため、変更され
ていない。同様に、図８を参照すると、図５におけるパ
ッケージcom.ibm.p3への呼び出しメソッドを含むpublic
スコープがpackageスコープに変更されている。また、
図９を参照すると、図６におけるパッケージcom.ibm.p1
への呼び出しメソッドを含むpublicスコープがpackage
スコープに変更されている。
ageスコープに変更する。図７を参照すると、図４にお
けるパッケージcom.ibm.p2への呼び出しメソッドを含む
publicスコープがpackageスコープに変更され、呼び出
しメソッドは同一パッケージのクラスＹへの呼び出しメ
ソッドに変更されている。システムクラスから呼ばれる
メソッドについては、内部化可能でないため、変更され
ていない。同様に、図８を参照すると、図５におけるパ
ッケージcom.ibm.p3への呼び出しメソッドを含むpublic
スコープがpackageスコープに変更されている。また、
図９を参照すると、図６におけるパッケージcom.ibm.p1
への呼び出しメソッドを含むpublicスコープがpackage
スコープに変更されている。
【００４８】以上のようにして、内部化可能な名前スコ
ープが全てpackageスコープに変更され、クラス名の衝
突も回避されたので、当該プログラムのシングルパッケ
ージ化が完了する。上記の例では、シングルパッケージ
化がソースファイルに対して行われる場合を前提にして
説明した。上述のように、この処理は、クラス名、フィ
ールド名、メソッド名の書き換えだけによって行われ
る。したがって、同じ処理をコンパイル済みのclassフ
ァイルに適用しようとした場合、変更される部分は、Co
nstantPoolだけであり、Byte Codeの部分は変更の影響
を受けない。すなわち、再コンパイルは不要である。こ
のため、ソースコードを持たない他社製のライブラリを
含むアプリケーションプログラムに対しても、全く同様
にシングルパッケージ化を行なうことが可能であり、ほ
とんどの外部名を内部化することができることとなる。
ープが全てpackageスコープに変更され、クラス名の衝
突も回避されたので、当該プログラムのシングルパッケ
ージ化が完了する。上記の例では、シングルパッケージ
化がソースファイルに対して行われる場合を前提にして
説明した。上述のように、この処理は、クラス名、フィ
ールド名、メソッド名の書き換えだけによって行われ
る。したがって、同じ処理をコンパイル済みのclassフ
ァイルに適用しようとした場合、変更される部分は、Co
nstantPoolだけであり、Byte Codeの部分は変更の影響
を受けない。すなわち、再コンパイルは不要である。こ
のため、ソースコードを持たない他社製のライブラリを
含むアプリケーションプログラムに対しても、全く同様
にシングルパッケージ化を行なうことが可能であり、ほ
とんどの外部名を内部化することができることとなる。
【００４９】
【発明の効果】以上説明したように、本発明によれば、
名前スコープを用いたアクセス制限を有効に活用して、
保護されるべきリソースを持つプログラムが不正なプロ
グラムに呼ばれることを防止できるようにＪａｖａプロ
グラムを編集することができる。
名前スコープを用いたアクセス制限を有効に活用して、
保護されるべきリソースを持つプログラムが不正なプロ
グラムに呼ばれることを防止できるようにＪａｖａプロ
グラムを編集することができる。
【００５０】また、本発明によれば、Ｊａｖａにおける
packageスコープと同様の概念に基づくアクセス制御を
実現するプログラミング言語において、保護されるべき
リソースを持つプログラムが不正なプログラムに呼ばれ
ることを防止できるようにプログラムを編集することが
できる。
packageスコープと同様の概念に基づくアクセス制御を
実現するプログラミング言語において、保護されるべき
リソースを持つプログラムが不正なプログラムに呼ばれ
ることを防止できるようにプログラムを編集することが
できる。
【図１】 本実施の形態におけるプログラムのシングル
パッケージ化の方法を説明するフローチャートである。
パッケージ化の方法を説明するフローチャートである。
【図２】 本実施の形態におけるプログラムのシングル
パッケージ化の処理を実行するシステムの構成例を説明
する図である。
パッケージ化の処理を実行するシステムの構成例を説明
する図である。
【図３】 本実施の形態によりプログラムがシングルパ
ッケージ化される様子を示す図である。
ッケージ化される様子を示す図である。
【図４】 図３のシングルパッケージ化される前のプロ
グラムにおけるクラスの内容を示す図であり、クラスco
m.ibm.p1.Ｘの内容を示す図である。
グラムにおけるクラスの内容を示す図であり、クラスco
m.ibm.p1.Ｘの内容を示す図である。
【図５】 図３のシングルパッケージ化される前のプロ
グラムにおけるクラスの内容を示す図であり、クラスco
m.ibm.p2.Ｙの内容を示す図である。
グラムにおけるクラスの内容を示す図であり、クラスco
m.ibm.p2.Ｙの内容を示す図である。
【図６】 図３のシングルパッケージ化される前のプロ
グラムにおけるクラスの内容を示す図であり、クラスco
m.ibm.p3.Ｘの内容を示す図である。
グラムにおけるクラスの内容を示す図であり、クラスco
m.ibm.p3.Ｘの内容を示す図である。
【図７】 図３のシングルパッケージ化された後のプロ
グラムにおけるクラスの内容を示す図であり、クラスco
m.ibm.p0.Foo_com_ibm_p1_Ｘの内容を示す図である。
グラムにおけるクラスの内容を示す図であり、クラスco
m.ibm.p0.Foo_com_ibm_p1_Ｘの内容を示す図である。
【図８】 図３のシングルパッケージ化された後のプロ
グラムにおけるクラスの内容を示す図であり、クラスco
m.ibm.p0.Ｙの内容を示す図である。
グラムにおけるクラスの内容を示す図であり、クラスco
m.ibm.p0.Ｙの内容を示す図である。
【図９】 図３のシングルパッケージ化された後のプロ
グラムにおけるクラスの内容を示す図であり、クラスco
m.ibm.p0.Foo_com_ibm_p3_Ｘの内容を示す図である。
グラムにおけるクラスの内容を示す図であり、クラスco
m.ibm.p0.Foo_com_ibm_p3_Ｘの内容を示す図である。
２１…第１の入力手段、２２…名前リスト作成手段、２
３…名前衝突回避手段、２４…名前リスト、２５…第２
の入力手段、２６…名前置き換え手段、２７…出力手
段、２８…電子署名手段
３…名前衝突回避手段、２４…名前リスト、２５…第２
の入力手段、２６…名前置き換え手段、２７…出力手
段、２８…電子署名手段
フロントページの続き (72)発明者 丸山 宏 神奈川県大和市下鶴間1623番地14 日本ア イ・ビー・エム株式会社 東京基礎研究所 内 (72)発明者 兒島 尚 神奈川県大和市下鶴間1623番地14 日本ア イ・ビー・エム株式会社 東京基礎研究所 内 Ｆターム(参考） 5B076 FB05
Claims (17)
- 【請求項１】 オブジェクト指向プログラミング言語で
記述されたプログラムの編集方法において、 前記オブジェクト指向プログラミング言語は、一定の参
照範囲を設定した場合に当該参照範囲内のみでの相互参
照を認めるパッケージの概念を持っていること、及びア
クセス要求者の身元を特定する身元情報に基づいてアク
セス権限を取得するアクセス制御システムを持っている
こと、という二つの条件を満足する言語であり、 複数のクラスにて構成されたアプリケーションプログラ
ムに対し、各クラスに付されたパッケージ名を単一のパ
ッケージ名に置き換えるステップと、 前記クラス中の、前記アプリケーションプログラムの外
部から参照されない内部化可能なデータにおける属性
を、同一パッケージ内からの参照を受け付けるように変
更するステップと、 前記パッケージ名の置き換えステップと前記データ属性
の変更ステップとを経た前記アプリケーションプログラ
ムに対して、アクセス要求者の身元を特定する身元情報
に基づく前記アクセス権限を取得させるステップとを含
むことを特徴とするプログラムの編集方法。 - 【請求項２】 前記パッケージ名の置き換えステップに
よりパッケージ名を置き換えた結果、前記アプリケーシ
ョンプログラム中の所定のクラスにおけるクラス名が同
一となる場合に、当該クラスのクラス名を変更するステ
ップをさらに含むことを特徴とする請求項１に記載のプ
ログラムの編集方法。 - 【請求項３】 前記クラス名変更ステップは、前記パッ
ケージ名の置き換えステップによる変更前の当該クラス
が属するパッケージ名に用いられた文字列を用いて、変
更するための新たなクラス名を生成することを特徴とす
る請求項２に記載のプログラムの編集方法。 - 【請求項４】 前記アプリケーションプログラム中のク
ラスのクラス名を、相互に重複しない固有のクラス名に
変更するステップをさらに含むことを特徴とする請求項
１に記載のプログラムの編集方法。 - 【請求項５】 複数のクラスにて構成されたＪａｖａの
プログラムを入力する入力手段と、 前記入力手段にて入力された前記プログラム中の、各ク
ラスが属するパッケージのパッケージ名を単一のパッケ
ージ名に置き換えるパッケージ名置き換え手段と、 前記クラス中の、前記プログラムの外部から参照されな
い内部化可能なデータの名前スコープを、パッケージス
コープに変更する名前スコープ変更手段と、 前記パッケージ名の置き換えと前記名前スコープの変更
とが行われた前記プログラムを出力する出力手段とを備
えたことを特徴とするシングルパッケージ化システム。 - 【請求項６】 前記パッケージ名の置き換えと前記名前
スコープの変更とが行われた前記プログラムに対して、
電子署名を行う電子署名手段をさらに備えたことを特徴
とする請求項５に記載のシングルパッケージ化システ
ム。 - 【請求項７】 前記クラスのクラス名及び前記クラス中
の内部化可能な前記データにおける名前スコープの名前
リストを作成する名前リスト作成手段と、 前記名前リスト作成手段にて作成された名前リスト中に
おいて、前記パッケージ名置き換え手段によるパッケー
ジ名の置き換えによって、同一となるクラス名を検出
し、当該クラス名の重複を回避するように当該名前リス
トにおける当該クラス名を変更する名前衝突回避手段と
をさらに備え、 前記名前スコープ変更手段は、前記名前リストを参照し
て前記名前スコープを変更し、かつクラス名を衝突の回
避されたクラス名に変更することを特徴とする請求項５
に記載のシングルパッケージ化システム。 - 【請求項８】 Ｊａｖａのプログラムを開発するための
プログラム開発システムにおいて、 複数のクラスにて構成された前記プログラムに対し、各
クラスが属するパッケージのパッケージ名を単一のパッ
ケージ名に置き換えるパッケージ名置き換え手段と、 前記クラス中の、前記プログラムの外部から参照されな
い内部化可能なデータの名前スコープを、パッケージス
コープに変更する名前スコープ変更手段と、 前記パッケージ名の置き換えと前記名前スコープの変更
が行われた前記プログラムに対して、電子署名を行う電
子署名手段とを備えたことを特徴とするプログラム開発
システム。 - 【請求項９】 前記クラスのクラス名及び前記クラス中
の内部化可能な前記データにおける名前スコープの名前
リストを作成する名前リスト作成手段と、 前記名前リスト作成手段にて作成された名前リスト中に
おいて、前記パッケージ名置き換え手段によるパッケー
ジ名の置き換えによって、同一となるクラス名を検出
し、当該クラス名の重複を回避するように当該名前リス
トにおける当該クラス名を変更する名前衝突回避手段と
をさらに備え、 前記名前スコープ変更手段は、前記名前リストを参照し
て前記名前スコープを変更し、かつクラス名を衝突の回
避されたクラス名に変更することを特徴とする請求項８
に記載のプログラム開発システム。 - 【請求項１０】 一定の参照範囲を設定した場合に当該
参照範囲内のみでの相互参照を認めるパッケージの概念
を持ち、各々所定の当該パッケージに属する複数のクラ
スにて構成されたアプリケーションプログラムを入力す
る入力手段と、 前記入力手段にて入力された前記アプリケーションプロ
グラムにおける各クラスが属するパッケージのパッケー
ジ名を単一のパッケージ名に置き換えるパッケージ名置
き換え手段と、 前記クラス中の、前記アプリケーションプログラムの外
部から参照されない内部化可能なデータにおける属性
を、同一パッケージ内からの参照を受け付けるように変
更する属性変更手段と、 前記パッケージ名の置き換えと前記データ属性の変更と
が行われた前記アプリケーションプログラムに対して、
アクセス要求者の身元を特定する身元情報を付加して当
該身元情報に基づくアクセス権限を取得させる身元情報
付加手段と、 前記身元情報を付加されたアプリケーションプログラム
を出力する出力手段とを備えたことを特徴とするプログ
ラムの身元情報付加システム。 - 【請求項１１】 前記身元情報は、電子署名であること
を特徴とする請求項１０に記載のプログラムの身元情報
付加システム。 - 【請求項１２】 一定の参照範囲を設定した場合に当該
参照範囲内のみでの相互参照を認めるパッケージの概念
を持つオブジェクト指向プログラミング言語で記述され
たプログラムを対象として、コンピュータに当該プログ
ラムを編集させる編集プログラムにおいて、 各々所定の前記パッケージに属する複数のクラスにて構
成されたアプリケーションプログラムに対し、各クラス
が属するパッケージのパッケージ名を単一のパッケージ
名に置き換える処理と、 前記クラス中の、前記アプリケーションプログラムの外
部から参照されない内部化可能なデータにおける属性
を、同一パッケージ内からの参照を受け付けるように変
更する処理とを含むことを特徴とする編集プログラム。 - 【請求項１３】 前記パッケージ名の置き換え処理によ
り、パッケージ名を置き換えた結果、前記アプリケーシ
ョンプログラム中の所定のクラスにおけるクラス名が同
一となる場合に、当該クラスのクラス名を変更する処理
をさらに含むことを特徴とする請求項１２に記載の編集
プログラム。 - 【請求項１４】 コンピュータに実行させるプログラム
を当該コンピュータの入力手段が読取可能に記憶した記
憶媒体において、 前記プログラムは、 複数のクラスにて構成されたＪａｖａのアプリケーショ
ンプログラム中の、各クラスが属するパッケージのパッ
ケージ名を単一のパッケージ名に置き換える処理と、 前記クラス中の、前記アプリケーションプログラムの外
部から参照されない内部化可能なデータの名前スコープ
を、パッケージスコープに変更する処理とを前記コンピ
ュータに実行させることを特徴とする記憶媒体。 - 【請求項１５】 前記プログラムの前記パッケージ名の
置き換え処理により、パッケージ名を置き換えた結果、
前記アプリケーションプログラム中の所定のクラスにお
けるクラス名が同一となる場合に、当該クラスのクラス
名を変更する処理をさらに含むことを特徴とする請求項
１４に記載の記憶媒体。 - 【請求項１６】 コンピュータに、 複数のクラスにて構成されたＪａｖａのアプリケーショ
ンプログラム中の、各クラスが属するパッケージのパッ
ケージ名を単一のパッケージ名に置き換える処理と、前
記クラス中の、前記アプリケーションプログラムの外部
から参照されない内部化可能なデータの名前スコープ
を、パッケージスコープに変更する処理とを実行させる
プログラムを記憶する記憶手段と、 前記記憶手段から前記プログラムを読み出して当該プロ
グラムを送信する送信手段とを備えたことを特徴とする
プログラム伝送装置。 - 【請求項１７】 前記プログラムの前記パッケージ名の
置き換え処理により、パッケージ名を置き換えた結果、
前記アプリケーションプログラム中の所定のクラスにお
けるクラス名が同一となる場合に、当該クラスのクラス
名を変更する処理をさらに含むことを特徴とする請求項
１６に記載のプログラム伝送装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000082556A JP3555858B2 (ja) | 2000-03-23 | 2000-03-23 | プログラムの編集方法、シングルパッケージ化システム、プログラム開発システム、プログラムの身元情報付加システム及び記憶媒体 |
| US09/816,954 US6792596B2 (en) | 2000-03-23 | 2001-03-23 | Method and system for protecting resource central programs |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000082556A JP3555858B2 (ja) | 2000-03-23 | 2000-03-23 | プログラムの編集方法、シングルパッケージ化システム、プログラム開発システム、プログラムの身元情報付加システム及び記憶媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001273131A true JP2001273131A (ja) | 2001-10-05 |
| JP3555858B2 JP3555858B2 (ja) | 2004-08-18 |
Family
ID=18599345
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000082556A Expired - Fee Related JP3555858B2 (ja) | 2000-03-23 | 2000-03-23 | プログラムの編集方法、シングルパッケージ化システム、プログラム開発システム、プログラムの身元情報付加システム及び記憶媒体 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6792596B2 (ja) |
| JP (1) | JP3555858B2 (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103560883A (zh) * | 2013-10-30 | 2014-02-05 | 南京邮电大学 | 一种基于用户权限的安卓应用程序间的安全性鉴定方法 |
| JP2014063237A (ja) * | 2012-09-20 | 2014-04-10 | Nec Corp | モジュール管理装置、モジュール管理システム及びモジュール管理方法 |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7263722B1 (en) * | 1999-05-12 | 2007-08-28 | Fraunhofer Crcg, Inc. | Obfuscation of executable code |
| US7779039B2 (en) | 2004-04-02 | 2010-08-17 | Salesforce.Com, Inc. | Custom entities and fields in a multi-tenant database system |
| US8214799B2 (en) * | 2004-07-08 | 2012-07-03 | Microsoft Corporation | Providing information to an isolated hosted object via system-created variable objects |
| JP4669934B2 (ja) * | 2005-06-10 | 2011-04-13 | 国立大学法人 奈良先端科学技術大学院大学 | プログラム変換装置、実行支援装置、それらの方法およびそれらのコンピュータ・プログラム |
| US7949684B2 (en) | 2005-09-09 | 2011-05-24 | Salesforce.Com, Inc. | Systems and methods for exporting, publishing, browsing and installing on-demand applications in a multi-tenant database environment |
| US7818733B2 (en) * | 2005-09-27 | 2010-10-19 | International Business Machines Corporation | Improving bundle control in computing environment |
| US20070094637A1 (en) * | 2005-10-24 | 2007-04-26 | International Business Machines Corporation | System, method, and computer program product for enabling coexistence of related software |
| DE102009052457A1 (de) * | 2009-11-09 | 2011-05-26 | Siemens Aktiengesellschaft | Verfahren und System zum Auslösen eines Namenskonfliktes |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0546682A3 (en) * | 1991-12-12 | 1993-12-08 | Ibm | Parent class shadowing |
| US5581761A (en) | 1993-07-20 | 1996-12-03 | Sun Microsystems, Inc. | Methods and apparatus for providing an extensible set of auxiliary services for objects in an object-oriented system |
| JPH10187450A (ja) | 1996-11-07 | 1998-07-21 | Fujitsu Ltd | オブジェクト指向プログラム自動生成装置，自動生成方法およびそのプログラム記憶媒体 |
| US6339829B1 (en) * | 1998-07-30 | 2002-01-15 | International Business Machines Corporation | Method and apparatus to store extended security information in a data structure which shadows a java class object |
| US6260187B1 (en) * | 1998-08-20 | 2001-07-10 | Wily Technology, Inc. | System for modifying object oriented code |
| CA2255042C (en) * | 1998-11-30 | 2004-04-13 | Leonard W. Theivendra | Class loader |
| US6526571B1 (en) * | 1999-03-16 | 2003-02-25 | International Business Machines Corporation | Method for identifying calls in java packages whose targets are guaranteed to belong to the same package |
-
2000
- 2000-03-23 JP JP2000082556A patent/JP3555858B2/ja not_active Expired - Fee Related
-
2001
- 2001-03-23 US US09/816,954 patent/US6792596B2/en not_active Expired - Fee Related
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2014063237A (ja) * | 2012-09-20 | 2014-04-10 | Nec Corp | モジュール管理装置、モジュール管理システム及びモジュール管理方法 |
| CN103560883A (zh) * | 2013-10-30 | 2014-02-05 | 南京邮电大学 | 一种基于用户权限的安卓应用程序间的安全性鉴定方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20010025370A1 (en) | 2001-09-27 |
| US6792596B2 (en) | 2004-09-14 |
| JP3555858B2 (ja) | 2004-08-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Stefan et al. | Flexible dynamic information flow control in Haskell | |
| US6851108B1 (en) | Verifying intermediate language code | |
| Sabelfeld et al. | Declassification: Dimensions and principles | |
| JP3786722B2 (ja) | デジタル署名を用いた進行オブジェクト指向型プログラムの有効利用方法および装置 | |
| Bokowski et al. | Confined types | |
| US7822723B2 (en) | Method, system, program and data structure for controlling access to sensitive functions | |
| Skorstengaard et al. | StkTokens: Enforcing well-bracketed control flow and stack encapsulation using linear capabilities | |
| KR20000069948A (ko) | 분산 네트워크 시스템에서의 접근 제어 장치 및 자원 보호 방법 | |
| JPH1139157A (ja) | 機密保護を提供する方法およびシステム | |
| Heule et al. | IFC inside: Retrofitting languages with dynamic information flow control | |
| Bank | Java security | |
| Patrignani et al. | Robustly safe compilation | |
| Vitek et al. | Confined types | |
| Stefan et al. | Flexible dynamic information flow control in the presence of exceptions | |
| JP3555858B2 (ja) | プログラムの編集方法、シングルパッケージ化システム、プログラム開発システム、プログラムの身元情報付加システム及び記憶媒体 | |
| Bratus et al. | Implementing a vertically hardened DNP3 control stack for power applications | |
| Deng et al. | SecChisel framework for security verification of secure processor architectures | |
| Vassena et al. | On formalizing information-flow control libraries | |
| Skorstengaard et al. | StkTokens: Enforcing well-bracketed control flow and stack encapsulation using linear capabilities | |
| Beres et al. | Dynamic label binding at run-time | |
| De Win et al. | How secure is AOP and what can we do about it? | |
| JP2004005441A (ja) | スクリプト処理装置、インタプリタ、スクリプト処理方法、スクリプト処理プログラム、およびスクリプトプログラム | |
| Bauer et al. | Mechanisms for secure modular programming in Java | |
| Skorstengaard | Formal Reasoning about Capability Machines | |
| Bauer et al. | Mechanisms for secure modular programming in Java |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040115 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040210 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040401 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040423 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20040427 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040507 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |