CN100543679C - 执行设备和方法 - Google Patents

Abstract

一种执行计算机程序的执行设备和方法，该执行设备执行计算机程序，并加载当正在执行该计算机程序时所请求的类。所加载的类是响应于正在执行的计算机程序的类。

Description

执行设备和方法

技术领域

本发明涉及一种用于执行计算机程序的执行设备。

背景技术

关于执行计算机程序的设备，存在如下设备，该设备在未加载程序的情况下，从安装有该设备正试图执行的功能的外部源(external source)加载程序并执行该程序。

该设备的一个例子是装备有Java虚拟机即JavaVM(JavaVirtual Machine)(Java是Sun Microsystems Inc.在美国和其它国家的商标或注册商标)的设备。当装备有Java VM的设备执行Java应用程序时，其能够从存在于该设备内或该设备外的类库(class library)来加载所需的Java类(类加载)。与类加载有关的JavaVM组件被称为类加载器(ClassLoader)。通过类路径(classpath)设定以及类加载器本身的动作来决定类加载器从哪里加载类。

在未指定将要使用的类加载器的情况下，使用内置在JavaVM中的系统类加载器(SystemClassLoader)。系统类加载器根据类路径设定来加载类。类路径列举一个或多个路径、或者加载类的位置。系统类加载器按照优先级递减顺序通过路径列举序列执行类搜索。还可以指定将要使用的类加载器，在这种情况下，根据所指定的类加载器的定义来搜索和加载类。

当类加载器加载类时，首先进行检查以确定将要加载的类存在于JavaVM内还是存在于与JavaVM一同提供的库内(Java系统)。如果该类存在于Java系统内，则从Java系统加载该类。换句话说，即使已知所需的类与应用程序一起位于外部，也优先从Java系统内进行加载。这样做的首要原因是Java系统内的类确保提供Java功能，由此维持Java功能的互用性(interoperability)。第二个原因是Java系统内的类是考虑到Java系统内的类安全性的可靠的类(solid class)。

美国6260078号专利和美国6701335号专利中引述了关于类加载的相关技术。

在将与应用程序一起提供的类库存储在Java系统内之后，应用程序从Java系统内的类库加载类。因此，不需要将类库与应用程序绑定。然而，如果与应用程序绑定的类库的版本不同于位于Java系统内的类库的版本，则出现下类问题。

保证与应用程序绑定的类库与应用程序一起工作。然而，由于不保证位于Java系统内的类库与应用程序一起工作这一事实，而试图使用位于Java系统内的、版本与同应用程序绑定的类库不同的类库可能导致出错。例如，当将与旧类库绑定的老的应用程序(legacy application)安装到包含新类库的新Java系统中时，可能出现这样的情况。在这种情况下，改变老的应用程序使得可以避免该错误是件麻烦的事情。从安全性观点来看，总是使用与应用程序绑定的类的方法也是不可取的。

日本特开2002-014817号公报公开了一种使用计算机网络来分发程序文件的文件分发系统。该文件分发系统将加载到服务器的文件系统中的程序模块的版本与安装在客户端的文件系统上的程序模块的版本进行比较。仅在加载到服务器的文件系统中的程序模块的版本比安装在客户端的文件系统上的程序模块的版本新的情况下，才下载加载到服务器的文件系统中的程序模块。

发明内容

本发明的目的是确保程序的稳定运行。

本发明的另一目的是避免延长类加载时间。

根据本发明，提供一种执行计算机程序的执行设备，该执行设备包括：执行单元，用于执行计算机程序；以及加载单元，用于加载当正在执行该计算机程序时所请求的类，其中，该加载单元加载与正在执行的该计算机程序相对应的类。

根据本发明，提供一种执行应用程序的执行设备，该执行设备包括：执行部件，用于执行应用程序；以及搜索部件，用于在执行该应用程序时搜索该应用程序所请求的类，其中，在该执行设备的存储部件中存储了该应用程序所请求的类的类名称或包名称的至少一部分的情况下，该搜索部件以应用程序库优先而不是以系统程序库优先进行搜索。

根据本发明，提供一种执行计算机程序的执行设备，该执行设备包括：执行部件，用于执行计算机程序；以及搜索部件，用于在执行该计算机程序时搜索该计算机程序所请求的类，其中，在该执行设备的存储部件中存储了该计算机程序所请求的类的类名称或包名称的至少一部分的情况下，该搜索部件以导入库优先而不是以系统程序库优先进行搜索。

根据本发明，提供一种执行应用程序的执行设备，该执行设备包括：执行部件，用于执行应用程序；以及加载部件，用于加载当正在执行该应用程序时所请求的类，其中，在该执行设备的存储部件中存储了该应用程序所请求的类的类名称或包名称的至少一部分并且应用程序库版本不同于系统程序库版本的情况下，该加载部件从该应用程序库加载该类。

根据本发明，提供一种执行应用程序的执行设备，该执行设备包括：执行部件，用于执行应用程序；以及加载部件，用于加载当正在执行该应用程序时所请求的类，其中，在该执行设备的存储部件中存储了该应用程序所请求的类的类名称或包名称的至少一部分并且应用程序库版本不同于系统程序库版本时，在应用程序库内的该类的版本不同于系统程序库内的该类的版本的情况下，该加载部件从该应用程序库加载该类。

根据本发明，提供一种执行计算机程序的执行方法，该执行方法包括以下步骤：执行计算机程序；以及加载当正在执行该计算机程序时所请求的类，其中，加载与正在执行的该计算机程序相对应的类。

根据本发明，提供一种执行应用程序的执行方法，该执行方法包括以下步骤：执行应用程序；以及在执行该应用程序时搜索该应用程序所请求的类，其中，在执行该应用程序的执行设备的存储部件中存储了该应用程序所请求的类的类名称或包名称的至少一部分的情况下，以应用程序库优先而不是以系统程序库优先进行该搜索。

根据本发明，提供一种执行计算机程序的执行方法，该执行方法包括以下步骤：执行计算机程序；以及在执行该计算机程序时搜索该计算机程序所请求的类，其中，在执行该计算机程序的执行设备的存储部件中存储了该计算机程序所请求的类的类名称或包名称的至少一部分的情况下，该搜索将优先权给予导入库而不是系统程序库。

根据本发明，提供一种执行应用程序的执行方法，该执行方法包括以下步骤：执行应用程序；以及加载当正在执行该应用程序时该应用程序所请求的类，其中，在执行该应用程序的执行设备的存储部件中存储了该应用程序所请求的类的类名称或包名称的至少一部分并且应用程序库版本不同于系统程序库版本的情况下，从该应用程序库加载该类。

根据本发明，提供一种执行应用程序的执行方法，该执行方法包括以下步骤：执行应用程序；以及加载当正在执行该应用程序时该应用程序所请求的类，其中，在执行该应用程序的执行设备的存储部件中存储了该应用程序所请求的类的类名称或包名称的至少一部分并且应用程序库内的该类的版本不同于系统程序库内的该类的版本的情况下，从该应用程序库加载该类。

通过以下(参考附图)对典型实施例的说明，本发明的其它特点将是显而易见的。

附图说明

图1是示出根据本发明实施例的Java程序执行系统的构成的框图；

图2是说明根据本发明实施例的JavaVM执行设备的硬件构成的框图；

图3是用于解释关于根据本发明实施例的J avaVM执行设备的应用程序执行序列的流程图；

图4是用于解释根据第一实施例在步骤S306中执行的类加载序列(第一类加载序列)的流程图；

图5A和5B是用于解释根据第二实施例在图3的步骤S306中执行的类加载序列(第二类加载序列)的流程图；

图6是用于解释根据第三实施例在图3的步骤S306中执行的类加载序列(第三类加载序列)的流程图；

图7A和7B是用于解释根据第四实施例在图3的步骤S306中执行的类加载序列(第四类加载序列)的流程图；

图8是用于解释根据本发明第五实施例在图3的步骤S306中执行的类加载序列(第五类加载序列)的流程图；

图9示出根据第五实施例的库信息表的例子的图；

图10A和10B是用于解释根据本发明第六实施例在图3的步骤S306中执行的类加载序列(第六类加载序列)的流程图；

图11示出根据第六实施例的库信息表的例子的图。

具体实施方式

将参考附图详细说明本发明的优选实施例。对权利要求书的范围来说，这些实施例不限制本发明，实施例中所描述的特征的全部组合对于本发明的解决方案也不是必需的。

图1是示出根据本发明实施例的Java程序执行系统的构成的框图。

在图1中，Java VM 101包括解释程序102和类加载器103。解释程序102解释并执行Java字节代码。系统程序库(systemlibrary)104是与JavaVM 101一起提供的系统程序库(系统程序库)。所加载的类105是被加载到存储器中并使其可执行的类。

应用程序106是用Java语言写的应用程序。应用程序类107是应用程序106运行的主类(main class)。应用程序库108是与应用程序106一起提供的类库或应用程序库。导入库(importlibrary)109是指当保持在应用程序106的外部时在应用程序106的部分运行中使用的类库。附图标记110表示JavaVM执行设备。

在图1中，应用程序106包括应用程序类107和应用程序库108。JavaVM执行设备110包括JavaVM 101、系统程序库104和所加载的类105。可允许JavaVM 101和应用程序106共存于同一设备即JavaVM执行设备110内。还可允许如下形式：将应用程序106安装在外部设备中，并通过JavaVM 101使用网络单元加载和执行应用程序106。

图2是说明根据本实施例的JavaVM执行设备110的硬件构成的框图。

在该图中，附图标记201表示控制整个设备的中央处理单元即CPU。ROM 202以机器可读的格式存储由CPU 201执行的各种类型的程序或数据。RAM 203用作CPU 201临时保存各种类型数据的工作区。计时器204根据CPU 201的指令测量各种类型的时间间隔。显示单元205用于显示用户界面，并且可具有例如LCD、等离子体屏幕或其它显示面板。键盘206具有全范围的操作键以及鼠标和其它指示装置，并且用于通过用户操作输入执行应用程序的指示、以及所有其它命令或数据。闪速ROM 207提供对所有类型的设定数据或文件的非易失性存储。附图标记208表示用于通过网络连接到外部设备的网络接口。硬盘驱动器(HD)209存储操作系统、所有类型的应用程序、或其它预安装的软件，并且还保存所有类型的设定数据文件。

在该情况下，解释程序102和类加载器103以程序形式存储在例如ROM 202中，并由CPU 201读出并执行它们。还可允许将解释程序102和类加载器103存储在硬盘驱动器209上。系统程序库104被加载到闪速ROM 207或硬盘驱动器209中。将所加载的类105加载到RAM 203中。如果应用程序106和导入库109位于如JavaVM执行设备110的同一设备内，则可以将它们加载到闪速ROM 207或硬盘驱动器209中。如果应用程序106和导入库109位于其它外部设备内，则它们位于适合该外部设备的存储介质内。

根据以上所述，在大多数情况下，构成运行主体的硬件是控制该设备的CPU 201，因此，除异常情况下以外，不详细说明每一情况下的该运行主体。

以下是使用图3中的流程图对应用程序106中的执行序列的说明。

图3是用于解释关于根据本实施例的JavaVM执行设备110的应用程序执行序列的流程图。

在步骤S301，类加载器103从应用程序类107加载将作为应用程序106的主类的类，即最初调用的类。将如此加载的类加载到RAM 203中作为所加载的类105之一。在步骤S302，由解释程序102读出、解释并执行作为所加载的类105之一的主类，其中解释程序102执行解释和执行处理直到应用程序106终止为止。因此，在步骤S303持续监控应用程序106以判断应用程序106是否已经终止。

如果在步骤S303中应用程序106终止，则执行序列结束。如果应用程序106没有终止，则处理进入步骤S304，在步骤S304，解释程序102判断是否已将执行下一个字节代码块所需的类加载到所加载的类105中。如果已加载该类，则处理进入步骤S302，返回到应用程序106的解释和执行步骤。

另一方面，如果在步骤S304中未加载所需的类，则处理进入步骤S305，在步骤S305，解释程序102请求类加载器103加载所需的类。一旦接受该请求，类加载器103就在步骤S306中加载所请求的类。当完成该类的加载时，处理返回到解释和执行步骤S302。

以下是对在图3的步骤S306中执行的类加载处理的各实施例的说明。

第一实施例

图4是用于解释根据第一实施例在步骤S306中执行的类加载序列(第一类加载序列)的流程图。

在步骤S401中，类加载器103判断解释程序102所请求的类是否满足预定的条件。具体而言，第一判断方法包括检查类名称是否满足以下条件(注意，Java中的类名称采用通过句点连结的一个或多个文本字符串的形式)。

第一判断方法：

1.所请求的类的类名称与已存储在RAM 203或其它存储介质中的一个或多个文本字符串完全匹配；

2.所请求的类的类名称的头与已存储的一个或多个文本字符串相匹配；

3.所请求的类的类名称的一部分包含已存储的一个或多个文本字符串。

从前述的1～3中选择解释程序102所请求的类要满足的预定条件，即与所请求的类的类名称相比较的一个或多个文本字符串，作为关于JavaVM执行设备110运行的期望条件。这些条件示出希望从应用程序库108加载的类的名称要满足的条件。因此，以下步骤将试图从应用程序库108加载满足任一条件的类。将应用程序库108与应用程序106绑定，并且典型地已完成了运行评价。换句话说，保证稳定运行。即使是存在于应用程序库108内的类，在给定情况下可能使用已在系统程序库内更新的类比较好，而在另一情况下可能使用在应用程序库内保证稳定运行的类比较好。因此，可以仅对指定的类赋予从应用程序类107进行加载的优先权。

可以利用上述三个条件中的任何一个；例如，可允许将给定类与条件1组合，将另一类与条件2组合。

第二判断方法包括检查包名称是否满足以下条件。Java中的包名称是指类名称中最后句点前的部分。例如，如果类名称是“com.xxx.project1.module1.type1.class1”，那么包名称就是“com.xxx.project1.module1.type1”。然而对类来说不是绝对需要具有包名称，在将名称赋予类的情况下，为了避免类名称冲突，或者换句话说，为了保护名称空间(namespace)，而附上包名称。基于这种一致思想赋予包名称便于识别类的创建者(企业)或类的种类：

第二判断方法：

1.包名称与已存储在RAM 203或其它存储介质中的一个或多个文本字符串完全匹配；

2.包名称的头与已存储的一个或多个文本字符串相匹配；

3.包名称的一部分包含已存储的一个或多个文本字符串。

从前述条件1～3中选择解释程序102所请求的类要满足的预定条件，即与所请求的类的包名称相比较的一个或多个文本字符串，作为关于JavaVM执行设备110运行的期望条件。这些条件示出希望从应用程序库108加载的类的包名称所要满足的条件。因此，以下步骤试图从应用程序库108加载满足任一条件的类。将应用程序库108与应用程序106绑定，并且典型地已完成了运行评价。换句话说，保证稳定运行。即使是存在于应用程序库108内的类，在给定情况下可能使用已在系统程序库内更新的类比较好，而在另一情况下可能使用在应用程序库内保证稳定运行的类比较好。

在选择情况下，当出于安全目的不希望从应用程序库108加载类或包时，必须注意。例如，在Java中，以“java”或“javax”开始的包是由系统提供的库，这形成了系统安全的基础。因为从应用程序库108加载这种包构成了安全违反，所以禁止从应用程序库108加载这种包。即使设定了前述条件，也使这样的类或包无效。特别地，防止试图向RAM 203设定这样的包，即不显示该设定序列。

通过这种方式，可以将优先权赋予从应用程序库108仅加载选择的授权包。可以利用三个条件中的任何一个；例如，可允许将给定包与条件1组合，将另一包与条件2组合。还可以使用类名称条件和包名称条件的混合。

如果由此在步骤S401中判断出所请求的类满足预定条件，则处理进入步骤S402，在步骤S402，类加载器103进行检查以判断该类是否存在于应用程序库108内。如果该类存在于应用程序库108内，则处理进入步骤S403，在步骤S403，类加载器103从应用程序库108加载该类。

另一方面，如果在步骤S402中该类不存在于应用程序库108内，则处理进入步骤S404，在步骤S404，类加载器103进行检查以判断该类是否存在于导入库109内。如果判断出该类存在于导入库109内，则处理进入步骤S405，在步骤S405，从导入库109加载该类。

如果在步骤S404判断出该类不存在于导入库109内，或者在步骤S401中判断出所请求的类不满足预定条件，则处理进入步骤S406，在步骤S406，类加载器103根据类路径优先序列搜索该类。在步骤S407中对最终是否发现该类做出判断，如果最终发现了该类，则处理进入步骤S408，在步骤S408，类加载器103从发现该类的路径加载该类，并且处理终止。另一方面，如果在步骤S407中最终未发现该类，则处理进入步骤S409，在步骤S409，类加载器103生成表示未能发现该类的异常，并且处理终止。

步骤S406～S409中的处理通常使从系统程序库104加载优先于从应用程序库108或导入库109加载。

根据第一类加载序列，关于第一实施例，如果类存在于应用程序库108或导入库109内，则从应用程序库108或导入库109加载该类，无论该类存在于哪一个库中，都无需搜索系统程序库104。因此，由于可以将优先权赋予假定已确认了其运行的类并且可以使用该类，因而可表现为稳定运行。

第二实施例

以下是根据第二实施例使用图5A和5B中的流程图对第二类加载序列的说明。

图5A和5B是用于解释根据第二实施例在图3的步骤S306中执行的类加载序列(第二类加载序列)的流程图。按照图3，根据第二实施例的JavaVM执行设备110的构成和应用程序执行序列的基本流程与根据第一实施例的JavaVM执行设备110的构成和应用程序执行序列的基本流程类似。

在步骤S501中，类加载器103判断解释程序102所请求的类是否满足预定的条件。省略对该判断处理的说明，因为该处理与图4的步骤S401中所示的处理相同。

如果在步骤S501中判断出所请求的类满足预定条件，则处理进入步骤S502，在步骤S502，类加载器103进行检查以判断该类是否存在于应用程序库108内。如果该类存在于应用程序库108内，则处理进入步骤S503，在步骤S503，类加载器103从应用程序库108获得版本信息。接着，在步骤S504(图5B)中，类加载器103进行检查以判断该类是否存在于系统程序库104内。如果该类存在，则处理进入步骤S505，在步骤S505，类加载器103从系统程序库104获得版本信息。然后处理进入步骤S506，在步骤S506，类加载器103进行检查以判断在步骤S503从应用程序库108获得的版本信息与在步骤S505从系统程序库104获得的版本信息是否相同。如果在此判断出各版本相互不同，则处理进入步骤S507，在步骤S507，类加载器103从应用程序库108加载该类。另一方面，如果在步骤S506判断出各版本相同，则处理进入步骤S514，在步骤S514，类加载器103从系统程序库104加载该类。

如果在步骤S504中所请求的类不存在于系统程序库104中，则处理进入步骤S507，在步骤S507，从应用程序库108加载该类。

如果在步骤S502中该类不存在于应用程序库108中，则处理进入步骤S508，在步骤S508，类加载器103进行检查以判断该类是否存在于导入库109内。如果判断出该类存在于导入库109内，则处理进入步骤S509，在步骤S509，获得导入库109的版本，然后，处理进入步骤S504。在这样的情况下，在步骤S504中，类加载器103进行检查以判断所请求的类是否存在于系统程序库104内。如果该类存在，则处理进入步骤S505，在步骤S505，类加载器103获得系统程序库104版本信息。然后处理进入步骤S506，在步骤S506，类加载器103进行检查以判断在步骤S509中从导入库109获得的版本信息与在步骤S505中从系统程序库104获得的版本信息是否相同。如果在此判断出各版本相互不同，则处理进入步骤S507，在步骤S507，类加载器103从导入库109加载该类。另一方面，如果在步骤S506中判断出各版本相同，则处理进入步骤S514，在步骤S514，类加载器103从系统程序库104加载该类。

如果在步骤S508中判断出该类不存在于导入库109内，或者在步骤S501中判断出所请求的类不满足预定条件，则处理进入步骤S510，在步骤S510，类加载器103根据类路径优先序列搜索该类(图5B)。在步骤S511中对最终是否发现该类做出判断，如果最终发现了该类，则处理进入步骤S512，在步骤S512，类加载器103从发现该类的路径加载该类。另一方面，如果最终未发现该类，则处理进入步骤S513，在步骤S513，类加载器103生成表示未能发现该类的异常，与图4的步骤S406～S409类似。

可允许对系统程序库104、应用程序库108和导入库109分别分配其各自的版本信息。然而，可由多个库文件构成各库；在这样的情况下，可允许获得关于包含正被搜索的类的库文件的版本信息。

典型地，在Java环境中，使用jar文件格式作为库。除了类文件以外，jar文件可以包含存储多种库信息的清单文件(manifestfile)。如果将版本信息写入该清单文件，则可以使用这样所写的版本信息作为库的版本信息。

尽管该说明使用库的版本信息，但是如果已基于每个类分配了版本信息并可以获得该版本信息，则可允许基于每个类来改变和加载库；还可以将每个类的版本信息写入清单文件。

根据第二类加载序列，关于第二实施例，比较加载类的库的版本，并且如果版本相同，则从系统程序库104加载该类，从而可以减少加载类所需的时间。当应用程序库108在JavaVM执行设备110的外部时，第二类加载序列尤其有效。

即使当应用程序库108位于JavaVM执行设备110内时，第二类加载序列也可以加速类的加载或执行。

第一个原因是：由于系统程序库104在系统内被共享而具有高度重要性，因此系统程序库104可以位于与应用程序库108相比具有更快的存取速度的存储介质内。

第二个原因是：为了提高CPU 201部分的执行速度，可以在执行前，将具有高度重要性的系统程序库104转换成优化的中间代码，或者转换成可以由CPU 201直接执行的本机代码。

第三实施例

以下是根据第三实施例使用图6中的流程图对第三类加载序列的说明。

图6是说明根据第三实施例在图3的步骤S306中执行的类加载序列(第三类加载序列)的流程图。按照图3，根据第三实施例的JavaVM执行设备110的构成和应用程序执行序列的基本流程与根据第一实施例的JavaVM执行设备110的构成和应用程序执行序列的基本流程类似。

在步骤S601中，类加载器103判断正在执行的应用程序是否将类加载的优先权赋予类路径搜索。为了进行该判断，假定基于每个应用程序将表示是否将优先权赋予类路径搜索的标志存储在RAM 203中(未示出)。

如果在步骤S601中判断出未将优先权赋予类路径搜索，则处理进入步骤S401，在步骤S401，类加载器103判断解释程序102所请求的类是否满足预定的条件。如果在步骤S401中所请求的类不满足该预定条件，或者如果在步骤S601中判断出已将优先权赋予类路径搜索，则处理进入步骤S406，在步骤S406，类加载器103根据类路径优先序列搜索该类。省略对步骤S401中判断为“是”以后的处理、以及对步骤S406以后的处理的说明，因为它们与图4的步骤S402～S405和步骤S407～S409所示的处理相同。

关于第三实施例，第三类加载序列将优先权赋予给定应用程序的类路径搜索，从而允许其它应用程序从应用程序库108加载类。例如，考虑将新版本的类作为系统程序库104的一部分提供的情况。在这种情况下，应用程序将使用存在于系统程序库104内的该版本的类。然而，可以设定其它应用程序以使用存在于应用程序库108内的以前版本的类。由此可以运行JavaVM执行设备110。

作为另一例子，考虑从应用程序库108加载类的应用程序。可以想到：在漏洞修补(bug fix)之后，可能将新版本的类安装到系统程序库104中，并且可能改变为从系统程序库104加载该类。尽管既不能容易地改变应用程序106也不能容易地改变其中所绑定的应用程序库108，但是考虑到JavaVM执行设备110内软件的可替换性，则很可能出现这种情况。在这种情况下，如果在进行包含系统程序库104的软件的替换的同时改变表示是否将优先权赋予类路径搜索的应用程序106的标志，则可以根据用户的意图改变运行。

第四实施例

以下是使用图7A和7B中的流程图对第四类加载序列的说明。

图7A和7B是用于解释根据第四实施例在图3的步骤S306中执行的类加载序列(第四类加载序列)的流程图。从图7A和7B可明显看到，第四类加载序列形成了图5B的第二类加载序列的步骤S506与步骤S507之间的步骤S707、以及在步骤S707中判断为“是”之后的步骤S716。省略对第四类加载序列与第二类加载序列相同的处理的说明。按照图3，根据第四实施例的JavaVM执行设备110的构成和应用程序执行序列的基本流程与根据第一实施例的JavaVM执行设备110的构成和应用程序执行序列的基本流程类似。

在步骤S506，类加载器103进行检查以判断在步骤S503从应用程序库108获得的版本信息与在步骤S505从系统程序库104获得的版本信息是否相同。如果在此判断出各版本相互不同，则处理进入步骤S707(图7B)，在步骤S707，类加载器103进行检查以判断是否从新版本库加载。为了进行该判断，在RAM203中存在表示是否从新版本库加载的标志(未示出)。一种情况可允许该标志存在于JavaVM执行设备110内，也可允许该标志基于每个应用程序或每个库而存在。如果在步骤S707判断出不会发生从新版本库的加载，则处理进入步骤S507，在步骤S507，类加载器103从应用程序库108或从导入库109加载该类。另一方面，如果在步骤S707判断出会发生加载，则处理进入步骤S716，在步骤S716，从新版本的库加载该类。

如果在步骤S506中判断出各版本相同，则处理进入步骤S514，在步骤S514，类加载器103从系统程序库104加载该类。

第五实施例

以下是使用图8中的流程图对第五类加载序列的说明。

图8是用于解释根据第五实施例在图3的步骤S306中执行的类加载序列(第五类加载序列)的流程图。按照图3，根据第五实施例的JavaVM执行设备110的构成和应用程序执行序列的基本流程与根据第一实施例的JavaVM执行设备110的构成和应用程序执行序列的基本流程类似。

当解释程序102请求类加载器103加载类时开始该处理，于是，在步骤S801，类加载器103获得关于在当前时间正在执行的应用程序106的信息。为了判断应用程序上下文(applicationcontext)，即正在执行哪个应用程序，处理追踪关于正由CPU 201执行的线程的调用栈。对从哪个应用程序加载存储在该栈中的且正被调用的方法类进行判断。在步骤S802，类加载器103根据类路径搜索所请求的类所在的库。在步骤S803，对是否发现包含该类的库进行判断，如果发现了该库，则处理进入步骤S804，在步骤S804，存储所发现的库的路径。接着，在步骤S805，获得该库的版本。在步骤S806，类加载器103根据在步骤S801获得的应用程序信息和在步骤S804和S805获得的库信息和版本信息来判断是否应该从该库加载该类。如果判断出不从该库加载该类，则处理返回到步骤S802。

根据图9中的库表901进行步骤S806中的判断。该表被存储在RAM 203、闪速ROM 207、或硬盘驱动器209中。

图9示出根据第五实施例的库信息表的例子的图。

其中存储有库、版本、以及加载该类的优先库的位置。

通过使用该库信息表901，可以根据应用程序106信息、库信息、以及如果必要的话甚至还有版本信息来确定加载该类的库的位置。

例如，当正在执行应用程序AAA时，接受加载类YYY的请求。假定类YYY包含在库aaa.jar内。在这种情况下，参照库信息表901显示出与“应用程序＝AAA”和“库＝aaa.jar”相对应的用于类加载的优先库的位置是应用程序库。

如果在步骤S802的搜索中所发现的库是系统程序库104，则该库与由库信息表901指示的应用程序库不匹配。因此，在步骤S806，类加载器103判断出不应该从系统程序库104加载该类，返回到步骤S802，并从由类路径表示的下一个搜索位置开始搜索该类。

如果通过第二搜索发现的库是应用程序库108，则该库与由库信息表901指示的应用程序库匹配。因此，在步骤S806，类加载器103判断出应该从应用程序库108加载该类，并进入步骤S807，在步骤S807，类加载器103从该库加载该类。

作为另一例子，当正在执行应用程序BBB时，生成加载类YYY的请求。按照前述例子，假定类YYY包含在库aaa.jar内。假定在图8的步骤S802中在系统程序库104内发现类YYY。在这样的情况下，库信息表901中用于类加载的优先库的位置为系统程序库，在步骤S806中，类加载器103判断出应该从系统程序库104加载该类，并且处理进入步骤S807。

可允许存在于库信息表901中的关于用于类加载的优先库的位置的信息示出应该进行加载的位置。因此，例如，可允许呈现应用程序库或系统程序库等位置类别，还可允许存储直接指向库的真实库路径。根据该例子，在判断是否应该加载类时，不使用在步骤S805中获得的版本信息。原因是：与图9的库信息表901中的应用程序AAA、库aaa.jar相对应的版本字段是空的。

下面的例子是使用版本信息的说明。

当正在执行应用程序CCC时，生成加载类YYY的请求。按照前述例子，类YYY包含在库aaa.jar内。假定在步骤S804中发现的库为系统程序库104。在步骤S805，获得系统程序库104的版本。在这样的情况下，在步骤S806，类加载器103获得库信息表910中的与“应用程序＝CCC”、“库＝aaa.jar”和“用于类加载的优先库的位置＝系统程序库”相对应的版本信息。

在图9中，与“应用程序＝CCC”和“库＝aaa.jar”相对应的系统程序库版本信息为“2.0以上”。

因此，在步骤S806，对在步骤S805中获得的版本信息是否满足该版本信息条件进行判断。如果满足该条件，则做出应该从该库加载该类的判断。

在步骤S802根据类路径进行搜索，其间，如果在步骤S803中最终没有满足步骤S806中的条件的库，则处理进入步骤S808，在步骤S808，类加载器103检查是否已发现包含所请求的类的库，或换句话说，检查是否存在在步骤S804中存储的库。尽管发现在此存储的库包含该类，但是该库是由于步骤S806中的条件判断而被拒绝的库。然而，如果已发现了库，那么该库包含所请求的类，由此处理进入步骤S807，在步骤S807加载该类。另一方面，如果在步骤S808未发现库，则处理进入步骤S809，在步骤S809，类加载器103使得显示大意为未能发现该类的异常，并且终止处理。

除上述实施例以外，可以想到存在多个发现的库的各种实施例。在这种情况下，可以想到：可应用如第一到第四类加载序列中所述的多种库选择方法，这些方法可以包括但不局限于以下方法：

1.将优先权赋予首先发现的库；

2.将优先权赋予应用程序库108；或

3.将优先权赋予新的库版本。

当根据图8流程图的步骤S802中的类路径进行库搜索时，可以想到：关于在此的搜索方法可以有多种变化。在这样的情况下，可以想到：可应用如第一到第四类加载序列中所述的多种库选择方法，这些方法可以包括但不局限于以下方法：

1.将优先权赋予首先发现的库；

2.将优先权赋予应用程序库108；或

3.将优先权赋予新的库版本。

第六实施例

以下是使用图10A和10B中的流程图对第六类加载序列的说明。

图10A和10B是说明根据第六实施例在图3的步骤S306中执行的类加载序列(第六类加载序列)的流程图。按照图3，根据第六实施例的JavaVM执行设备110的构成和应用程序执行序列的基本流程与根据第一实施例的JavaVM执行设备110的构成和应用程序执行序列的基本流程类似。

在步骤S1001，按照图8的步骤S801，类加载器103获得关于在当前时间正执行的应用程序106的信息。在步骤S1002，类加载器103根据类路径搜索所请求的类。因此，在步骤S1003对是否发现包含该类的库进行判断。如果发现了包含该类的库，则处理进入步骤S1004，在步骤S1004获得库名称。然后处理进入步骤S1005，在步骤S1005，类加载器检查是否存在下一个优先库。通过参照图11中的库信息表1101进行该判断，库信息表1101是库信息表901的改写。

图11示出根据第六实施例的库信息表的例子的图。

以下是对图9所示的库信息表901与图11所示的表1101之间的不同的说明。在图9的表901中，存在仅关于加载类的优先库的一个位置的信息。另一方面，在图11中，存在包含从第一优先库到第三优先库的一列优先库信息。尽管图11中的列表示出到第三优先库，但是优先库的数量不局限于此。

在步骤S1005，类加载器103基于在步骤S1001中获得的应用程序信息和在步骤S1004中获得的库名称来参照库信息表1101，并检查是否存在下一个优先库的位置。当执行该步骤时，类加载器103自然检查是否存在第一优先库的位置。该检查方法与使用库信息表901所述的方法类似。

如果在步骤S1005中存在优先库的位置，则处理进入步骤S1006，在步骤S1006，获得优先库的位置。在步骤S1007，类加载器103检查在该库位置处是否实际存在具有在步骤S1004中获得的库名称的库。如果该库实际存在于该位置，则处理进入步骤S1008，在步骤S1008，类加载器103检查所请求的类是否存在于该库内。如果该类存在于该库内，则处理进入步骤S1009(图10B)，在步骤S1009，类加载器103将该库存储在RAM 203中或其它位置，进入步骤S1010，在步骤S1010，类加载器103获得库版本。在步骤S1011，类加载器103检查该版本是否符合库信息表1101的版本条件。该检查方法与使用库信息表901所述的方法相同。如果该版本符合该版本条件，则处理进入步骤S1012，在步骤S1012，类加载器103从该库加载该类。

另一方面，如果在步骤S1007中实际不存在该库，或者如果在步骤S1008中该类不存在于该库内，或者如果在步骤S1011中该版本不符合该版本条件，则处理返回步骤S1005，在步骤S1005，搜索下一个优先库的位置。利用在此所述的循环处理如此进行对优先库的搜索，该循环处理从第一优先库开始并依次进行。

如果在步骤S1005中不存在下一个优先库，则处理进入步骤S1013(图10B)，在步骤S1013，类加载器103检查是否存在在步骤S1009中存储的库。在此所存储的库是已知包含所请求的类的库。如果在步骤S1013中存在所存储的库，则处理进入步骤S1012，在步骤S1012，从该库加载该类。另一方面，如果在步骤S1013中不存在所存储的库，或者在步骤S1003中未能发现包含该类的库，则处理进入步骤S1014(图10B)，在步骤S1014，类加载器103生成表示未能发现该类的异常。

尽管说明了根据各实施例的类加载序列，但是可以基于每个应用程序改变类加载序列。可以使存在于JavaVM 101内的类加载器103识别在给定时间正在执行的应用程序，并替换类加载序列。为了判断应用程序上下文，即正在执行哪个应用程序，处理追踪关于正由CPU 201执行的线程的调用栈。对从哪个应用程序加载存储在该栈中的且正被调用的方法类进行判断。

尽管附图中未示出，但是本领域的技术人员应该明白，还可以通过给各应用程序安装类加载器或应用程序类加载器，基于每个应用程序改变类加载序列。在这样的情况下，应用程序类加载器间的差异标识各应用程序。

根据本实施例，在本说明中使用Java编程语言、以及使用Java编程语言的程序和类作为例子。然而，本领域的技术人员应该理解，本发明的本质通常适用于面向对象的程序执行设备，而不是专用于Java系统。

其它实施例

尽管已说明了本发明的实施例，但是可允许将本发明应用于由多个装置构成的系统，并且还可将本发明应用于由单个装置构成的设备。

本发明还可这样来实现：直接或远程向系统或设备提供实现这些实施例的功能的软件程序，通过系统或设备内的计算机读出并执行所提供的程序。在这种情况下，只要具有程序的功能，格式无需是程序格式。

为了利用计算机实现本发明的功能处理，本身安装在该计算机中的程序代码也可以实现本发明。换句话说，本发明的权利要求还包括本身实现本发明的功能处理的计算机程序。在这种情况下，只要具有程序的功能，该程序的格式可以是目标代码、由解释程序执行的程序、向操作系统提供的脚本数据或其它格式。

可使用各种记录介质来提供该程序。例子包括但不局限于：硬盘驱动器、光盘、磁光盘、MO、CD-ROM、CD-R、CD-RW、磁带、非易失性存储卡、ROM、或DVD，其中DVD包括但不局限于DVD-ROM或DVD-R。

作为另一种程序提供方法，还可以这样来提供程序：使用客户计算机上的浏览器连接到因特网上的网页，从该网页将该程序下载到硬盘驱动器或其它记录介质。在这种情况下，可允许所下载的是本发明的计算机程序本身，或者是包含自动安装功能的压缩文件。还可以通过将构成本发明的程序的程序代码分成多个文件，并从不同的网页分别下载各文件来实现。换句话说，本发明的权利要求也包括允许多个用户下载实现本发明的功能处理的程序文件的万维网(World Wide Web)服务器。

还可以对本发明的程序进行加密，将该程序存储在CD-ROM或其它记录介质上，并将该程序分发给用户。在这种情况下，允许满足预定条件的用户通过因特网从网页下载解密该加密的密钥信息，并以可执行格式将加密程序安装在计算机上。

还可以通过使计算机执行所读出的程序，以实现实施例功能的格式以外的格式来实现。例如，使运行在计算机上的操作系统或其它软件进行全部或部分实际处理，该处理也可以实现实施例的功能。

还可允许将从记录介质读出的程序写入到安装在计算机内的功能扩展板、或与计算机连接的功能扩展单元中所内置的存储器中。在这种情况下，内置在功能扩展板或功能扩展单元中的CPU或其它硬件根据程序指令进行全部或部分实际处理，该处理实现实施例的功能。

尽管参考典型实施例说明了本发明，但应当理解，本发明不局限于所公开的典型实施例。以下权利要求书的范围符合最宽的解释，以包含所有这类修改和等同结构和功能。

Claims (13)

1.一种执行应用程序的执行设备，该执行设备包括：

执行部件，用于执行应用程序；以及

搜索部件，用于在执行该应用程序时搜索该应用程序所请求的类，

其中，在所述执行设备的存储部件中存储了该应用程序所请求的类的类名称或包名称的至少一部分的情况下，所述搜索部件以应用程序库优先而不是以系统程序库优先进行搜索。

2.根据权利要求1所述的执行设备，其特征在于，在所述执行设备的存储部件中未存储该应用程序所请求的类的类名称或包名称的至少一部分的情况下，所述搜索部件搜索类路径中设定的库。

3.一种执行计算机程序的执行设备，该执行设备包括：

执行部件，用于执行计算机程序；以及

搜索部件，用于在执行该计算机程序时搜索该计算机程序所请求的类，

其中，在所述执行设备的存储部件中存储了该计算机程序所请求的类的类名称或包名称的至少一部分的情况下，所述搜索部件以导入库优先而不是以系统程序库优先进行搜索。

4.一种执行应用程序的执行设备，该执行设备包括：

执行部件，用于执行应用程序；以及

加载部件，用于加载当正在执行该应用程序时所请求的类，

其中，在所述执行设备的存储部件中存储了该应用程序所请求的类的类名称或包名称的至少一部分并且应用程序库版本不同于系统程序库版本的情况下，所述加载部件从该应用程序库加载该类。

5.根据权利要求4所述的执行设备，其特征在于，在所述执行设备的存储部件中存储了该应用程序所请求的类的类名称或包名称的至少一部分并且应用程序库版本和系统程序库版本相同的情况下，所述加载部件从该系统程序库加载该类。

6.一种执行应用程序的执行设备，该执行设备包括：

执行部件，用于执行应用程序；以及

加载部件，用于加载当正在执行该应用程序时所请求的类，

其中，在所述执行设备的存储部件中存储了该应用程序所请求的类的类名称或包名称的至少一部分并且应用程序库版本不同于系统程序库版本时，在应用程序库内的该类的版本不同于系统程序库内的该类的版本的情况下，所述加载部件从该应用程序库加载该类。

7.根据权利要求6所述的执行设备，其特征在于，在所述执行设备的存储部件中存储了该应用程序所请求的类的类名称或包名称的至少一部分并且应用程序库版本和系统程序库版本相同的情况下，所述加载部件从该系统程序库加载该类。

8.一种执行应用程序的执行方法，该执行方法包括以下步骤：

执行应用程序；以及

在执行该应用程序时搜索该应用程序所请求的类，

其中，在执行该应用程序的执行设备的存储部件中存储了该应用程序所请求的类的类名称或包名称的至少一部分的情况下，以应用程序库优先而不是以系统程序库优先进行该搜索。

9.一种执行计算机程序的执行方法，该执行方法包括以下步骤：

执行计算机程序；以及

在执行该计算机程序时搜索该计算机程序所请求的类，

其中，在执行该计算机程序的执行设备的存储部件中存储了该计算机程序所请求的类的类名称或包名称的至少一部分的情况下，该搜索将优先权给予导入库而不是系统程序库。

10.一种执行应用程序的执行方法，该执行方法包括以下步骤：

执行应用程序；以及

加载当正在执行该应用程序时该应用程序所请求的类，

其中，在执行该应用程序的执行设备的存储部件中存储了该应用程序所请求的类的类名称或包名称的至少一部分并且应用程序库版本不同于系统程序库版本的情况下，从该应用程序库加载该类。

11.根据权利要求10所述的执行方法，其特征在于，在该存储部件中存储了该应用程序所请求的类的类名称或包名称的至少一部分并且在应用程序库版本和系统程序库版本相同的情况下，从该系统程序库加载该类。

12.一种执行应用程序的执行方法，该执行方法包括以下步骤：

执行应用程序；以及

加载当正在执行该应用程序时该应用程序所请求的类，

其中，在执行该应用程序的执行设备的存储部件中存储了该应用程序所请求的类的类名称或包名称的至少一部分并且应用程序库内的该类的版本不同于系统程序库内的该类的版本的情况下，从该应用程序库加载该类。

13.根据权利要求12所述的执行方法，其特征在于，在该存储部件中存储了该应用程序所请求的类的类名称或包名称的至少一部分并且应用程序库版本和系统程序库版本相同的情况下，从该系统程序库加载该类。

Images