信息处理装置和库管理方法与流程

本发明涉及用于管理在类路径中设置的库的信息处理装置和库管理方法。

背景技术：

在java(注册商标)执行环境中，通过类加载器进行类(执行中需要的代码)的加载。通过在具有jar(java归档)格式的库中的类文件来定义类。通过多个类的类文件来构成库，并且通常按特定功能来划分库。注意，需要预先在java(注册商标)执行环境中设置指示库存在的位置的路径作为类路径。这允许在加载类时，类加载器从设置在类路径中的库中搜索类以加载。在此，类加载器消耗文件描述符以通过参照库来搜索类。在java(注册商标)执行环境中，为了提高性能或者为了防止破坏对库的参照和运行变得不稳定，参照曾经被参照过的库直到在执行环境中运行的程序结束。因此，通过类加载器参照库而消耗的文件描述符被持续消耗直到程序结束。

在嵌入式设备中，在作为应用执行环境的信息处理装置中可用的资源是有限的。文件描述符是一种类型的资源，并且可用的文件描述符的数量存在限制。因此，执行以下操作。首先，开发者确定针对应用使用的资源量的上限值。当用户管理员启动应用时，应用管理框架基于该上限值来确认未超出信息处理装置可用的资源量。

作为传统技术，存在如下技术：检测根本未被使用的类，并从类路径中删除具有未被使用的类的库(例如，日本特开2005-293084号公报)。

日本特开2005-293084号公报留下具有在类路径中被使用的类的库。换言之，如果存在大量的、在类路径中被使用的类的库，则会消耗大量的文件描述符。因此，如果超出可用的文件描述符的数量，则结果使启动处理受影响。尤其是，如果库的数量由于功能扩展或软件更新而持续增加，被消耗的文件描述符的数量将会增加。

技术实现要素：

鉴于以上内容，即使使用的库的数量增加，本发明也能够抑制文件描述符的消耗。

本发明具有如下配置。

本发明的一个方面提供了一种信息处理装置，包括：加载单元，用于当执行已安装的程序时，打开包含通过所述程序使用的类的库并加载所述类，所述加载单元根据被打开的库的数量来消耗量的资源；确定单元，用于确定包括针对所述已安装的程序而设置的类的库的数量是否为多个；整合单元，用于如果确定库的数量为多个，则将库中包括的类整合为数量小于库的数量的整合库；以及删除单元，用于删除除了不通过加载单元访问的库以外的、包含所述整合库中所包括的类的整合前的库。

本发明的另一个方面提供了一种信息处理装置的库管理方法。所述信息处理装置具有加载单元，用于当执行已安装的程序时，打开包含通过所述程序使用的类的库并加载所述类，所述加载单元根据被打开的库的数量来消耗量的资源，所述方法包括：确定包括针对安装程序而设置的类的库的数量是否为多个；如果确定库的数量为多个，则将库中包括的类整合为数量小于库的数量的整合库；以及删除除了不通过加载单元访问的库以外的、包含所述整合库中所包括的类的整合前的库。

凭借本发明，能够降低在加载类的时候消耗的文件描述符的数量，并且能够减轻伴随库文件的增加而引起的文件描述符的问题。此外，即使当存在用于直接访问库文件的模型时，能够执行操作而没有问题，并且能够实现存储的使用量的降低。

通过下面参照附图对示例性实施例的描述，本发明的其他特征将变得清楚。

附图说明

图1是在第一实施例的图像形成装置的构造图。

图2是在第一实施例的图像形成装置的硬件构造图。

图3是在第一实施例的图像形成装置中的应用执行环境的构造图。

图4a和图4b是第一实施例中的启动选项配置文件的构造图。

图5a、图5b和图5c是第一实施例中的应用配置文件的构造图。

图6a和图6b是第一实施例中的库配置文件的构造图。

图7是在第一实施例中访问文件列表的示例。

图8表示在第一实施例中图像形成装置100中的库布置。

图9a和图9b是表示在第一实施例的库中的类文件的布置的图。

图10a是表示在第一实施例中图像形成装置的处理的流程的流程图。

图10b是表示在第一实施例中图像形成装置的处理的流程的流程图。

图10c是表示在第一实施例中图像形成装置的处理的流程的流程图。

图10d是表示在第一实施例中图像形成装置的处理的流程的流程图。

图11是在第二实施例中启动选项配置文件的构造图。

图12是在第二实施例中应用配置文件的构造图。

图13a和图13b是表示在第二实施例的库中类文件的布置的图。

图14是表示在第二实施例中图像形成装置的处理流程的流程图。

图15a和图15b表示在第三实施例中的图像形成装置的处理流程的流程图。

具体实施方式

下面，将使用附图描述用于执行本发明的实施例。

[第一实施例]

图1中描述的是示出本发明的第一实施例的整体系统的构造的图。

图像形成装置100是实施本实施例的信息处理装置的示例，并且，例如是多功能外围设备(mfp)。信息处理装置101管理图像形成装置100。网络120将图像形成装置100和信息处理装置101相连。通过经由网络120使用图像形成装置100而使用信息处理装置101。应用a110是在图像形成装置100上运行的应用的一个示例。应用b111是类似地在图像形成装置100上运行的应用的另一个示例。此外，应用c112是类似地在图像形成装置100上运行的应用的其他示例。可以在图像形成装置100上运行一个或更多个应用。在此，示出三个应用。此后，表达方式“应用11n”表示由应用a110、应用b111和应用c112代表的一个或更多个应用。一般用户和管理员可以使用图像形成装置100、应用11n和用于管理图像形成装置100和应用11n的资源管理装置的基本功能。关于使用，可以直接地操作图像形成装置100以及经由网络120通过信息处理装置101来操作图像形成装置100。

<图像形成装置的硬件构造>

图2是图像形成装置100的硬件构造的模块化图。

核单元200是包括处理器、存储器等的控制单元，并且通过处理器和存储器共同工作以执行程序来控制与核单元200连接的各种设备。此外，核单元200实现应用执行环境并执行已安装的应用。用户接口单元201、存储设备202、用于连接到网络120的网络接口单元203、扫描器单元204、打印机单元205、整理器单元206等连接到核单元200作为外围设备。核单元200控制这些设备并且经由用户接口单元201或者网络120向用户以及应用提供其功能。

<应用执行环境>

图3是用于在本实施例的图像形成装置100上执行应用11n的应用执行环境。

启动模块300是用于启动应用执行环境的模块。当用户开启图像形成装置100的供电时，系统开始运行，并且启动模块300命令lib管理模块304进行用于生成整合库的处理作为用于本实施例的处理。lib管理模块304是用于实施本实施例的模块，并且是用于将在类路径中设置的库重新生成为一个整合库的模块。在生成整合库的处理结束之后，启动模块300启动应用执行平台301。应用执行平台301是java(注册商标)执行环境，并且例如是java(注册商标)vm(虚拟机)。类加载器302是用于加载类的模块。通过系统程序执行应用，并且当在其中使用类时，通过类加载器302从包含由类路径指定的类的库中动态地加载类。

如果命令没有被加载的类的执行处理，则类加载器302从设置在类路径中的库中搜索被命令的执行处理的类。类是用于应用执行平台301执行命令的可执行代码，并且类路径是指示包含类的库的位置的路径信息。类路径包括第一类路径和第二类路径，第一类路径中包括系统所需的类，第二类路径中包括用于各个应用11n的类。尽管，系统被狭义地定义为操作系统，但是在该示例中，还可以表示除应用之外的并且包括操作系统的软件模块。第一类路径是加载系统的类所需的路径，并且包括引导(boot)类路径和系统类路径中的各个或者包括至少其中之一。引导类路径是指示包含用于启动java(注册商标)执行环境所需的类的库的位置的路径。系统类路径是指示包含用于启动应用执行平台301和应用管理框架303所需的类的库的位置的路径。第二类路径是指示包含应用的类的库的位置的应用类路径(或者app类路径)。当启动模块300启动应用执行平台301时，将第一类路径传递到应用执行平台301作为启动选项。应用执行平台301注册被传递的第一类路径。第二类路径是应用管理框架303从应用中包括的应用配置文件(例如图5a中所示的应用配置文件502)读取的类路径(图5b中所示的应用类路径514)，并且，应用管理框架303仅针对要被启动的应用将读取的类路径设置为第二类路径。因此，即使将其称为第二类路径，用于各个不同的应用11n的第二类路径是完全不同的类路径。在本实施例中，例如应用配置文件是java(注册商标)清单文件。

在类加载器302在类路径中设置的库中搜索类，并且如果在库中找到搜索的目标类，则类加载器302从该库中加载类。然后，应用执行平台301执行已加载的类。如果没有找到目标类，则通过诸如控制台画面或浏览器画面等的用户接口单元201提醒用户没有找到该类。当从图像形成装置100的系统开始运行直到图像形成装置100的供电被用户关闭时，如果执行未被加载的类，则由类加载器302进行这种类加载处理。此外，开发者预先给类提供命名空间，使具有相同名称的类不会冲突。库是将一个或更多个类压缩的jar(java存档)文件。为了防止库中的类冲突，典型的，在jar文件中配置与命名空间对应的目录层次(directoryhierarchy)，并在其中布置类文件。在本实施例中，将描述在库中通过命名空间目录层次进行配置的示例。

应用管理框架303是管理应用11n的安装、卸载、执行和终止的框架，并且例如是osgi。使用应用管理框架303以在应用执行环境内安装并执行应用11n。通过管理员向应用管理框架303请求安装和启动应用11n，应用管理框架303进行应用安装处理和应用启动处理。此时，应用管理框架303参照该应用的应用配置文件(例如，图5a中所示的应用配置文件502)，并确定其声明的资源上限值(例如，图5b中的资源上限值513)是否适合当前应用执行环境中资源的可用空间。如果不适合，则导致应用的启动失败。

下面是对用于执行本实施例的特殊构成元件的描述。

lib管理模块304是用于生成整合库305的模块。从启动模块300命令lib管理模块304进行整合库生成处理。lib管理模块304扩展(或解压缩)在启动选项配置文件(例如，图4a中的启动选项配置文件400)的第一类路径(例如，图4a中的类路径402)中设置的所有库，和在应用配置文件(例如，图5a中的应用配置文件502)的第二类路径(例如，图5b中的类路径514)中设置的所有库。扩展的类被再次压缩为jar文件格式作为新的整合库。在创建整合库之后，lib管理模块304将启动选项配置文件(例如，图4a中的启动选项配置文件400)中的第一类路径(例如，图4a中的类路径402)的配置改变为仅新生成的整合库。此外，lib管理模块304删除在应用配置文件(例如，图5a中的应用配置文件502)的第二类路径(例如，图5b中的类路径514)中设置的所有库的描述。只有收集了设置为第一类路径或第二类路径的多个库中的类组的整合库被设置在第一类路径，并且类加载器302能够通过仅查找整合库而搜索需要的类。

此外，lib管理模块304从整合前的库中存在的应用配置文件502或库配置文件601中，针对各个库指定用于直接访问而无需通过类加载器302的文件。指定的文件被注册在访问文件列表306中。此外，在生成整合库之后，lib管理模块304删除未被注册在访问文件列表306中的库文件。由此，因为删除了不必要的文件，所以节约了磁盘空间，并且即使不通过类加载器302来执行文件访问，也能够实现正确的操作。注意，在直接访问库而不使用类加载器302的情况下，不消耗文件描述符。

整合库305是由类加载器302加载的库，并且包括由lib管理模块304创建的整合库。如前面所述，整合库是压缩被设置在第一类路径或第二类路径中的多个库的类组的库，jar文件格式。当包含在整合库中的类被类加载器加载一次时，能够由应用执行平台301、应用管理框架303和应用11n执行。

访问文件列表306是用于管理无需经过类加载器302而直接访问的文件的表格，并且由lib管理模块304执行其细节的更新。

<启动选项配置文件的示例>

图4a和图4b是说明描述本实施例的启动选项配置的典型文件细节的图。

图4a是示出在被本实施例中的lib管理模块304改变之前的启动选项配置文件400的图。启动选项配置文件400是lib管理模块304生成整合库并改变文件细节之前的启动选项配置文件。路径401是指示用于启动应用执行平台301的可执行文件位置的位置信息。路径402是指示库的位置的位置信息并且对应于第一类路径。库403是被设置在第一类路径的各个库的位置信息。设置在第一类路径402中的库403包括应用执行平台301和应用管理框架303执行处理所需的类组。主程序404是应用执行平台301启动应用管理框架303所需的主程序的位置信息。

图4b是示出被本实施例中的lib管理模块304改变后的启动选项配置文件410的图。启动选项配置文件410是在lib管理模块304生成整合库并改变了文件细节之后的启动选项配置文件。例如，启动选项配置文件410是通过改变启动选项配置文件400获得的。启动模块300读取启动选项配置文件410的细节，并将读取的细节用作应用执行平台301的启动选项。整合库411是设置在第一类路径中的整合库的位置信息。在生成整合库之后，lib管理模块304将整合库的路径添加到启动选项配置文件400的类路径设置中，并且从第一类路径402中删除除整合库之外的库的路径。

<应用文件示例>

图5a是说明构成本实施例中的应用11n的典型文件细节的图。应用11n具有多种类型的文件。应用可执行代码文件500是包括诸如应用的可执行代码的文件。应用包含库501是执行应用的处理所需的库。在执行应用11n的处理中，如果在第一类路径402中设置的库403中的特定类不足且无法实现功能，则开发者为应用准备了库作为应用包含库501。应用配置文件502是描述诸如应用id的基本信息、应用使用的资源上限值以及第二类路径的文件。应用配置文件502是由开发者预先定义的，并且与应用可执行代码文件500和应用包含库501一起包括在应用11n中。

图5b是示出在设置在第二类路径514中的库的描述被lib管理模块304删除之前，应用配置文件502中描述的项目示例的图。应用名称511是应用11n的名称。在图像形成装置100的用户接口单元201等上显示应用名称511。应用id512是为使应用管理框架303唯一地识别各个应用11n而添加的识别信息。资源上限值513是应用11n利用的资源的上限值。为每个资源定义资源上限值513。开发者预先测量应用11n可以利用的资源的上限值，并且在应用配置文件502中将测量的上限值声明为资源上限值513。当安装和启动应用11n时，应用管理框架303参照该资源上限值513。然后，确定应用是否适合当前应用执行环境内的资源的可用空间，如果适合则启动该应用，并且如果不适合，则使应用11n的启动失败。第二类路径514是指示当执行应用11n的处理时所需的应用可执行代码文件500或应用包含库501的位置的信息。路径515是在第二类路径中设置的应用可执行代码文件500或应用包含库501的位置的信息。

直接访问文件设置516是应用执行直接访问的库文件的位置的信息，并且lib管理模块304用于管理不经过类加载器302而被直接访问的库文件。当通过类加载器302处理库中的文件时，因为被读出的文件取决于类路径搜索顺序，所以如果在多个库中包括相同名称的文件，则存在读出非本意的文件的可能性。因此，在期待读出确实是本意的文件的情况下，应用可以不经过类加载器302而直接访问文件。直接访问文件设置516准备管理上述文件。

在图5b中，为了描述简单，尽管应用可执行代码文件500的路径通过相对路径设置，但是也可以通过绝对路径来描述。此外，代表性的应用包含库501是未设置在第一类路径402中的库，所以需要将它们的位置指示为第二类路径514。

图5c是示出lib管理模块304将在第二类路径514中设置的库的描述删除之后，在应用配置文件502中描述的项目示例的图。当启动模块300命令lib管理模块304用于整合库的生成处理时，lib管理模块304参照应用配置文件502的第二类路径514。设置在那里的应用包含库501被扩展，并且将在第一类路径402中设置的库和应用包含库内的类再次压缩成jar文件格式作为整合库。之后，lib管理模块304将第一类路径402仅改变为新生成的整合库。通过该改变而获得第一类路径411。lib管理模块304将在应用配置文件502的第二类路径514中设置的库的描述删除。应用配置文件520是将第二类路径514中设置的库的描述删除之后的应用配置文件。第二类路径521仅被设置在应用可执行代码文件500的路径。路径522是在第二类路径中设置的应用可执行代码文件500的位置信息。由于通过路径515设置的库被lib管理模块304作为整合库305而设置在启动选项配置文件的第一类路径411，所以lib管理模块304将库的设置从应用配置文件中删除。注意，在本实施例中，启动选项配置文件和应用配置文件可以被统称为配置文件。

<库布置的示例>

图6a是用于说明配置本实施例中整合之前的库的代表性文件的细节的图。库具有多种类型的文件。库可执行代码文件600是包括例如库的可执行代码的文件。库配置文件601是描述文件名称和可被直接访问的文件信息的文件。库配置文件601由开发者预先定义(生成)，并与库可执行代码文件600一起包括在库中。

图6b是库配置文件601的示例。库名称611是库的名称。库版本612是库的版本。当在操作单元上显示版本时，使用例如库名称611和库版本612。直接访问文件设置613是库直接访问的库的位置的信息。直接访问文件设置613由lib管理模块304参考，并作为用于管理被直接访问的库的信息使用。在这个配置文件的示例中，例示了copy库的版本1.0直接访问两个文件，libsystem001.jar和libsystem002.jar。

<访问文件列表的示例>

图7是示例了由lib管理模块304管理的访问文件列表306的示例的图。从被直接访问的文件的路径配置访问文件列表306。当执行库整合处理时，lib管理模块304从在应用配置文件502或库配置文件中描述的、执行直接访问的文件的位置信息中获取信息，以生成访问文件列表306。位置信息包括根据应用表示直接访问文件的位置的直接访问文件设置516，并且包括根据库表示直接访问文件的位置的直接访问文件设置613。此外，当在库整合之后删除库文件时，lib管理模块304控制从而不删除在访问文件列表306中注册的文件。

<库布置的示例>

图8是以树形表示的在图像形成装置100中库布置的示例的结构图。文件夹801是用于布置在第一类路径402中设置的库的文件夹。在文件夹801中布置由lib管理模块304生成的整合库802和被直接访问的库804。可以被直接访问的库804由访问文件列表306管理。在库整合以节约存储容量之后，删除不被直接访问的库(但是整合库除外)。整合库802是由lib管理模块304生成的库。在生成整合库802之后，lib管理模块304将该库802设置在第一类路径411。文件夹803是用于布置在图像形成装置100安装的应用11n的文件夹。当应用11n被安装时，应用管理框架303从应用11n中提取应用包含库501，并将其布置在用于应用存储的文件夹803中。然后，当图像形成装置启动时，由lib管理模型304整合库。此时，除了被直接访问的库以外的库均被删除。在图5a所示的应用配置文件502的情况下，仅布置被直接访问的文件libpa1.jar。

<类文件的布置的示例>

图9a和图9b是由树形表示的本实施例的库中的类文件的布置的示例的结构图。

图9a是示例针对lib管理模块304扩展以收集并压缩类文件的库的内部的图。库901到904是被设置在第一类路径402的库，并示出了包含在库中的类文件及其布置。库905到906是被设置在第二类路径514中的库，并示出了包含在库中的类文件及其布置。

图9b是示例在lib管理模块304扩展库并压缩所有类文件之后生成的整合库的内部结构的图。库910是被设置在第一类路径411中的整合库，并示出了包含在库中的类文件及其布置。因为图9a描述的类文件被全部布置在整合库中，所以类加载器301能够仅通过从该整合库中搜索类，找到执行处理所需的类。由此，能够减低打开库的数量，并且能够抑制所使用的文件描述符的数量。

<图像形成装置的应用相关处理>

图10a是示意性的表示本实施例的从用户开启图像形成装置100电源到关闭电源的处理流程的流程图。通过核单元200(特别是核单元200中包括的处理器)执行图10a中的流程。该流程例如由操作系统启动，并且通过软件模块执行各步骤来运行。尽管在下面的描述中软件被描述为代理，但是软件是虚拟处理代理，实际实体是执行软件的处理器或处理器核。

当用户开启图像形成装置100的电源时，操作系统开始运行，首先启动启动模块300，并且，在步骤s10101中，启动模块300命令lib管理模块304进行整合库生成处理。将参照图10b描述该处理。当lib管理模块304完成整合库生成处理时，在步骤s10102，启动模块300利用启动选项配置文件410的细节作为启动选项来启动应用执行平台301。当应用执行平台301启动时，主程序404的处理被执行并进行处理。类加载器302作为应用执行平台301的一部分监督类加载。在步骤s10103，类加载器302在类生成时确定类是否已被加载。在步骤s10103，当类加载器302确定应用执行平台301、应用管理框架303或应用11n在主程序执行期间执行类生成处理时，处理进行到步骤s10104，并且如果未执行处理，则处理进行到步骤s10106。在步骤s10104，类加载器302进行类加载处理。当类加载处理结束时，应用执行平台301、应用管理框架303或应用11n在步骤s10105生成类，并且处理进行到步骤s10106。在步骤s10106中，在启动主程序之后，应用执行平台301基于例如来自操作系统等的通知而确定用户是否已经关闭图像形成装置100的电源。如果确定电源已被关闭，则应用执行平台301进行用于关断图像形成装置100的电源的处理并且图像形成装置100的系统结束。如果电源未被关闭，则返回步骤s10103，应用执行平台301继续执行主程序。

以这种方式，应用执行平台301一旦被启动就在步骤s10103至s10106的环中监督类的生成和电源关闭。当类被生成时，类被加载，并且，在电源被关闭时，进行电源关闭处理。

<整合库的生成以及用于删除个别文件的处理>

图10b是步骤s10101的详细流程图，并且是表示在向启动模块300发出针对整合库生成处理的命令时，lib管理模块304的处理流程的流程图。

在步骤s10201，lib管理模块304确定多个库是否被设置在第一类路径402和第二类路径514中。如果确定一个库被设置，则lib管理模块304终止处理而无需执行整合库生成处理。然而，如果确定多个库被设置，则处理进行到步骤s10202。

在步骤s10202，lib管理模块304存储被设置在第一类路径402和第二类路径514中的所有库。因为这具有在改变第一类路径402和第二类路径514之后参考改变前的类路径设置信息的目的，所以如果能够实现该目的，则可以采用如下配置：存储在存储器中或存储在独立的文件中。当设置在类路径中的库信息被存储时，处理进行到步骤s10203。

在步骤s10203，lib管理模块304清除在访问文件列表306中注册的信息以重新生成访问文件列表306的信息。

下面，在步骤s10204，lib管理模块304针对第一类路径402中描述的库和已安装应用，开始循环处理直到步骤s10207。

下面，在步骤s10205，lib管理模块304读取配置文件601或配置文件502，并确定直接访问文件设置613或516是否分别存在于该配置文件中。如果确定直接访问文件设置存在，则处理进行到步骤s10206，以及如果确定不存在，则处理进行到步骤s10207。

在步骤s10206，lib管理模块304向访问文件列表306添加直接访问文件设置613的信息，并且处理进行到步骤s10207。

在步骤s10207，lib管理模块304确定是否已针对所有库和应用执行了循环处理。如果没有针对所有库和应用执行循环处理，则处理返回至步骤s10204，以及如果已针对所有库和应用执行了循环处理，则处理进行到步骤s10208。

在步骤s10208，lib管理模块304执行库整合处理和类路径改变处理。稍后将通过图10c描述该处理的细节。当lib管理模块304结束该处理，处理进行到步骤s10209。

在步骤s10209，lib管理模块304针对步骤s10202中存储的库开始用于该处理的循环处理，直到步骤s10212。

在步骤s10210，lib管理模块304确定与访问文件列表306对应的库是否被注册。如果确定已被注册，则处理进行到步骤s10212，以及如果确定未被注册，则处理进行到步骤s10211。

在步骤s10211，lib管理模块304删除对应的库文件，并且处理进行到步骤s10212。

在步骤s10212，lib管理模块304确定是否已针对步骤s10202中存储的所有库执行了处理。如果没有针对所有库执行处理，则处理返回至步骤s10209，以及如果已针对所有库执行了处理，则离开循环，并且lib管理模块的处理终止。

根据上述处理，在启动选项配置文件400和应用配置文件502中描述的、在启动时以及通过应用所使用的库进行整合，能够降低库的数量并且降低诸如消耗的文件描述符的资源。此外，关于通过应用或库而不是通过lib管理模块304访问的类文件，通过保留且不删除它们，而是通过删除不对应的类文件，能够抑制诸如存储器或内存的资源的消耗。

<库整合处理和库路径改变处理>

图10c是步骤s10208的详细流程图，并且是示例lib管理模块304整合库文件并重写类路径402和514的处理的流程的流程图。

在步骤s10301，lib管理模块304读出启动选项配置文件400，并且扩展在第一类路径402中设置的所有的库403。此时，lib管理模块304从在描述顺序中最后描述的库开始，按顺序扩展库。例如，在图4a中描述的细节的情况下，lib管理模块304以如下的顺序扩展库：libsystem004.jar(未示出)，libsystem003.jar，libsystem002.jar以及libsystem001.jar。这样，通过从较晚描述的库开始按顺序扩展，如果相同的类名称恰巧存在于相同的命名空间并冲突，则能够通过较晚扩展的类文件(换句话说通过较早描述的类文件)覆写较早扩展的类文件。典型的，如果存在与相同命名空间和相同类名称的冲突，则加载首先在类路径中设置的类文件。因此，如果发生类之间的冲突，则通过利用较早描述的库的类文件覆写(换句话说通过较晚扩展的类文件覆写)，能够保留在典型环境下应该确实被加载的类。

下面处理进行到步骤s10302，lib管理模块304针对已安装的应用扩展在第二类路径514中设置的所有应用包含库501。此时，lib管理模块304从在描述顺序中最后描述的库开始按顺序扩展库。当用于应用包含库504的扩展处理结束时，处理进行到步骤s10303。在步骤s10303，lib管理模块304将在步骤s10301和步骤s10302中扩展的所有类文件压缩为一个jar文件格式作为整合库(这里是libinteg.jar)。例如，整合库具有将整合前的库整合到如图9b所示的树形结构的结构。换句话说，库被整合以使整合之前的库中相关的类结构维持在整合之后的库中。类文件可以被存储在相同的文件夹中作为整合目标的类文件。

在步骤s10304，lib管理模块304将在步骤s10303中压缩并生成的整合库添加到第一类路径402的设置中，并删除除了整合库之外的库的描述。由此，启动选项配置文件400具有像启动选项配置文件410那样的描述细节。

下面，处理进行到步骤s10305，lib管理模块304从第二类路径514的设置中删除库文件的设置。由此，应用配置文件502具有像应用配置文件520那样的描述细节。当用于删除第二类路径514的设置的处理完成时，处理进行到步骤s10306。在步骤s10306，lib管理模块304删除在步骤s10301和s10302中扩展的文件，并终止库整合处理和类路径改变处理。

通过上述处理，在启动选项配置文件400和应用配置文件中描述的库被整合。

<在类生成时通过类加载器302的处理>

图10d是步骤s10104的详细流程图，并且是示例当主程序的执行期间生成类时类加载器302的处理的流程的流程图。

在步骤s10401，类加载器302确定是否已执行未被当前执行的主程序加载的类。如果类已完成加载，则终止用于类加载的处理，并且处理继续主程序的处理。如果类没有被加载，则处理进行到步骤s10402。在步骤s10402，类加载器确定类路径中描述的库是否被打开。如果库被打开，则处理进行到步骤s10404，如果没有被打开，则处理进行到步骤s10403。在步骤s10403，类加载器302打开被设置在第一类路径411中的库。此时，因为一个文件被打开，所以类加载器302消耗一个文件描述符。处理进行到步骤s10404。在步骤s10404，类加载器302确定要被加载的类是否在库中。如果找到了要被加载的类，则在步骤s10405中，类加载器302从库中加载类，并且类加载处理结束。如果没有找到期望被加载的类，则在步骤s10406中，类加载器302确定是否已搜索了在类路径中描述的所有库。如果确定没有搜索所有库，则处理返回至步骤s10402，针对下一个库执行用于确定的处理。然而，在本实施例中，因为将所有库文件整合为一个，并且在第一类路径中仅存在该整合库，所以处理不返回至步骤s10402。因此，由于在步骤s10403中的文件打开处理针对整合库仅被执行一次，所以对于类加载使用的文件描述符的数量只有一个。换句话说，即使库文件由于功能增加等而增加，使用的文件描述符的数量也不会增加。

与此同时，如果在步骤s10406确定已搜索了所有库，则处理进行到步骤s10407。在步骤s10407，类加载器302返回表示类未找到的错误，并且类加载处理终止。

注意，因为期望在本实施例中使用典型的类加载器，所以步骤s10406的确定总是具有相同的结果(已搜索所有库的确定)，并且执行不必要的确定处理。然而，本发明不限于该配置，可以配置为使用省略步骤s10406的确定处理的特殊的类加载器(换句话说处理直接从步骤s10404进行到步骤s10407)。

如上所述，在本发明的第一实施例中，在应用执行平台301的启动之前，例如在图像形成装置的启动时，lib管理模块304生成整合库，并且仅将该整合库设置在第一类路径411。结果，因为在该整合库中包括了所有的类文件，在启动应用执行平台301之后，如果类加载器搜索类，则类加载器302能够通过仅搜索该整合库而找到该类。换句话说，因为类加载器302只打开一个库，能够将使用的文件描述符的数量设置为1。因此，无需考虑设置在第一类路径402中的库的数量和设置在第二类路径514中的库的数量，都能够将类加载器用来打开库的文件描述符的数量设置为1。

此外，能够通过在生成整合库之后删除整合之前的库文件的配置，来抑制存储的使用量。此外，此时，该配置使得直接访问而不经过类加载器访问的库文件被保留而不被删除。因此，即使存在直接访问库文件内部的处理，也能够操作而不会引起错误发生。

注意，尽管在本实施例中存在如下的配置，即在图像形成装置的启动时lib管理模块执行整合库生成处理等，但是并不限于该配置，也可以配置为在固件更新时执行。

[第二实施例]

下面，利用图来给出本发明第二实施例的说明。

在第一实施例中，在第一类路径402和第二类路径514中设置的库中的所有类被压缩为一个整合库。在该配置中，能够显著降低文件描述符的使用数量，但是如果直接访问的库文件的数量增加则存储的使用量变得更大。所以，这在具有小存储容量的设备中可能是一个问题。在第二实施例中，针对如下配置给出说明，即当lib管理模块304整合库时，只整合不被直接访问的库，并且从个别库文件执行针对直接访问的库文件的类加载。

在第二实施例中，省略了针对图1、图2、图6a、图6b、图7和图8的说明，因为上述附图与第一实施例通用，并且以下仅描述区别部分。

在图像形成装置100上执行应用的应用执行环境的配置与图3类似。然而，lib管理模块304整合库并改变类路径设置的处理是不同的。特别的，当lib管理模块304整合库时，执行不整合被直接访问的库文件的控制。所以，类似于第一实施例，当除了被直接访问的库以外的文件被删除时，在lib管理模块304执行处理之后的全部存储使用量不从库整合处理之前改变。正因如此，能够避免在具有小存储容量的设备中存储变得不足的状态。

<启动选项配置文件的示例>

图11是示例在本实施例中由lib管理模块304改变启动选项配置文件1100之后，启动选项配置文件1100的图。注意，改变之前的启动选项配置文件与第一实施例的图4a类似。在图11中，启动选项配置文件1100是在lib管理模块304生成整合库并改变文件的细节之后的启动选项配置文件。启动模块300读取启动选项配置文件400的细节，并将读取的细节用作为应用执行执行平台301的启动选项。库1101是设置在第一类路径中的库的位置信息。在生成整合库之后，lib管理模块304将整合库的路径添加到启动选项配置文件400的类路径设置中，并且删除在访问文件列表中不存在的库。这里，因为整合库是整合在访问文件列表中不存在的库，所以变成能够根据这些设置细节使用与整合前相同的类。

<应用配置文件的示例>

图12是第二实施例中在lib管理模块304删除在第二类路径514中设置的库的描述之后，在应用配置文件中描述的项目的示例的图。因为应用配置和被lib管理模块304删除之前的应用配置文件502与第一实施例相似，因此省略对其的描述。

当启动模块300向lib管理模块304发出命令用以整合库的生成处理时，lib管理模块304参照应用配置文件502的第二类路径514和访问文件列表。在第二类路径中存在而不在访问文件列表中存在的应用包含库被扩展。然后，lib管理模块304从设置在第一类路径402中的库整合不在访问文件列表中存在的类，并且将它们再次压缩为jar文件格式下的整合库。然后，lib管理模块304将新生成的整合库添加到第一类路径402中，并删除不在访问文件列表中存在的库的描述。lib管理模块304然后从应用配置文件502的第二类路径514中设置的库中删除不在访问文件列表中存在的库的描述。附图标记1200表示在删除了第二类路径514中设置的库的描述之后的应用配置文件。附图标记1201表示第二类路径，应用可执行代码文件500的路径的设置和访问文件列表中存在的库被描述。

<类文件布置的示例>

图13a和图13b是通过树形描述的第二实施例的库中类文件的布置的示例的构成图。

图13a是示例针对lib管理模块304扩展以收集并压缩类文件的库的内部图。树1301到1302在第一类路径402中设置的库中且不在访问文件列表中存在的库中布置类文件。树1303到1304在第二类路径514中设置的库中且不在访问文件列表中存在的库中布置类文件。

图13b是示例lib管理模块304扩展库并压缩所有扩展的类文件之后生成的整合库的内部图。树1310是在第一类路径411中设置的整合库中类文件的布置。在与图9b的比较中，不整合作为在访问文件列表中记录的文件的libsystem001.jar和libsystem002.jar的类文件。如果只关注库布置，在图8中，本实施例与第一实施例通用。然而，与第一实施例的不同点在于在访问文件列表中描述的类文件不包括在整合库中。

通过这种方式，因为在第二实施例中的整合库具有只整合不被直接访问的库的配置，所以整合库的文件尺寸比第一实施例中的小。此外，关于不包括在整合库中的库，因为这是如下的配置，即没有被整合的库的设置被保留在第一类路径和第二类路径中，所以不缺少执行处理所需的类。

<库整合处理>

图14是第二实施例中步骤s10208的详细流程图，并且是示例lib管理模块304整合库文件并重写类路径402和514的处理的流程的流程图。注意，在步骤s10208，由于步骤s10204至步骤s10207的循环而已经生成访问文件列表。

在步骤s14101，lib管理模块304读取启动选项配置文件400，并扩展在第一类路径402中设置的库403中且没有被注册到访问文件列表306中的库。此时，lib管理模块304从在描述顺序中被最后描述的库开始按照顺序扩展库。例如，如果第一类路径是图4a的细节，并且访问文件列表是图7的细节，lib管理模块304以libsystem004.jar和libsystem003.jar的顺序扩展库。此外，libsystem001.jar和libsystem002.jar因为注册在访问文件列表而不被扩展。接下来，处理进行到步骤s14102。

在步骤s14102，lib管理模块304读取已安装应用的应用配置文件502，并且在第二类路径514中设置的应用包含库501中扩展未注册在访问文件列表306中的库。此时，lib管理模块304从在描述顺序中最后被描述的库开始按照顺序扩展库。当用于应用包含库501的扩展处理结束时，处理进行到步骤s14103。在步骤s14103，lib管理模块304将步骤s14101和步骤s14102中扩展的所有类文件压缩为jar文件格式作为整合库。结果，生成了例如图13b中所示的整合库1310。

在步骤s14104，lib管理模块304将在步骤s14103中压缩并生成的整合库添加到启动选项配置文件400的第一类路径402的设置中，并删除在访问文件列表中未注册的库文件的设置。由此，例如使启动选项配置文件400具有图11所示的如启动选项配置文件1100那样的描述细节。

下面处理进行到步骤s14105，并且lib管理模块304从应用配置文件502的第二类路径514的设置中删除访问文件列表中未注册的库文件的设置。据此，例如使应用配置文件502具有如图12所示的应用配置文件1200中的描述细节。当用于删除第二类路径514的设置的处理完成时，处理进行到步骤s14106。

在步骤s14106，lib管理模块304删除在步骤s14101和步骤s14102中扩展的文件，并且终止库整合处理和类路径改变处理。

如上所述，在本发明的第二实施例中，当在类路径中设置整合库时，lib管理模块304通过仅以不被直接访问的库为目标来执行整合。所以，整合库的文件尺寸比第一实施例中的小被直接访问的文件没有与整合库重叠的部分。正因如此，能够将lib管理模块的处理完成之后的存储使用量抑制到与处理之前类似的使用量。

此外，针对被直接访问的库，配置为在类路径中保留其设置并且从个别库中加载其类。所以，当类加载器302从这些库中打开一个库时消耗文件描述符，并且使用的文件描述符的数量比第一实施例大。然而，因为仅通过在整合库中收集的库的数量，能够降低使用的文件描述符的数量，所以能够实现文件描述符数量的降低，即使在具有小存储容量的设备中也不会发生存储不足。

[第三实施例]

下面，利用附图来给出本发明第三实施例的解释。尽管第一实施例能够显著地降低使用的文件描述符，如果具有大文件尺寸的库被直接访问，则存储的使用量会变大。相反，尽管第二实施例能够抑制存储的使用量，如果具有小文件尺寸的大量库被直接访问，则不能降低消耗的文件描述符的数量。在第三实施例中，根据这个情况描述如下示例：在第一实施例的方法和第二实施例的方法之间分开的处理。

在第三实施例中，因为除了图10b以外的其他附图在第一实施例和第二实施例中描述的细节是通用的，所以省略对其的描述，仅描述不同之处。图15a和15b是在本实施例中图10a的步骤s10101的处理的细节，并且是例示当向启动模块300给出用于整合库生成处理的命令时lib管理模块304的处理流程的流程图。换句话说，在本实施例中，执行图15a和图15b取代第一实施例中的图10b。

在步骤s15101，lib管理模块304确定多个库是否被设置在第一类路径402和第二类路径514中。如果确定一个库被设置，则lib管理模块304终止处理，而不执行整合库生成处理。然而，如果确定多个库被设置，则处理进行到步骤s15102。

在步骤s15102，lib管理模块304存储在第一类路径402和第二类路径514中设置的所有库。目的是在改变第一类路径402和第二类路径514之后，参照改变之前的类路径的设置信息，所以如果该目的能够实现，则可以采用存储在其他文件中或存储在内存中的配置。当设置在类路径中的库信息被存储时，处理进行到步骤s15103。

在步骤s15103，lib管理模块304清除在访问文件列表306中注册的信息以再次生成访问文件列表306的信息。

下面，在步骤s15104，针对在第一类路径402中描述的库和安装的应用，lib管理模块304开始循环处理直到步骤s15107。

下面，在步骤s15105，lib管理模块304读取配置文件601或配置文件502，并确定直接访问文件设置613或516是否分别存在于配置文件中。如果确定直接访问文件设置存在，则处理进行到步骤s15106，并且如果确定不存在，则处理进行到步骤s15107。

在步骤s15106，lib管理模块304向访问文件列表306添加直接访问文件设置613的信息，并且处理进行到步骤s15107。

在步骤s15107，lib管理模块304确定是否针对所有库和应用已执行了循环处理。如果没有针对所有库和应用执行循环处理，则处理返回至步骤s15104，并且如果针对所有库和应用已执行循环处理，则处理进行到步骤s15108。

在步骤s15108，lib管理模块304计算在访问文件列表中注册的库文件的总文件尺寸，并且处理进行到步骤s15109。

在步骤s15109，lib管理模块304确定在步骤s15108中计算的总文件尺寸是否大于或等于预定尺寸。在步骤s15109中，如果确定大于或等于预定尺寸，则处理进行到步骤s15111，如果确定小于预定尺寸，则处理进行到步骤s15110。这里，为了简要描述，尽管这是通过固定的阈值做比较的流程图，但是，例如，在获得图像形成装置的可用空间之后可以动态确定阈值。

在步骤s15110，lib管理模块304根据图10c的处理执行库整合处理和类路径改变处理，并且处理进行到步骤s15112。换句话说，如在第一实施例中那样，在启动选项配置文件400和应用配置文件502中描述的库被整合。

在步骤s15111，lib管理模块304根据图14的处理执行库整合处理和类路径改变处理，并且处理进行到步骤s15112。换句话说，如第二实施例那样，在启动选项配置文件400和应用配置文件502中描述的库中，仅整合不被直接访问的那些库。

在步骤s15112，lib管理模块304针对存储在步骤s15102中的库启动用于该处理的循环处理直到步骤s15115。

在步骤s15113，lib管理模块304确定与访问文件列表306对应的库是否被注册。如果确定它们已被注册，则处理进行到步骤s15115，如果确定它们没有被注册，则处理进行到步骤s15114。

在步骤s15114，lib管理模块304删除对应的库文件，并且处理进行到步骤s15115。

在步骤s15115，lib管理模块304确定是否针对在步骤s15102中存储的所有库已执行了处理。如果没有针对所有库执行处理，则处理返回到步骤s15112，如果针对所有库已执行了处理，则离开循环并终止lib管理模块的处理。

如上所述，在本发明的第三实施例中，配置为根据被直接访问的库的总文件尺寸，切换用于库整合和类路径改变的处理细节。正因如此，由于在被直接访问的库的总文件尺寸小于或等于阈值的情况中采用了第一实施例的方法，因此能够在抑制存储使用量的同时，将使用的文件描述符的数量抑制到最小。此外，因为在被直接访问的库的总文件尺寸大于阈值的情况中采用了第二实施例的方法，所以能够在抑制文件描述符的使用量的同时，将存储使用量抑制到最小。由于通过这种方式根据存储容量的情况采用适当的方法，因此，即使针对具有小存储容量的设备，也变得更容易降低使用的文件描述符的数量。

[变形例]

在第三实施例中，在s15109中，将被直接访问的库的总文件尺寸与阈值进行比较，并且根据比较的结果，确定是否整合被直接访问的库。与此相反，可以采用如下的配置：要抑制文件描述符或存储的消耗量的优先次序被例如管理员指定，并且根据该指定来改变确定的基准。在不需要图15b的步骤s15108的情况下，在s15109中确定优先的资源，并且如果文件描述符优先，则处理分支到步骤s15110，否则，换句话说，当存储容量优先时，处理分支到步骤s15111。

可选的，在s15109中，在访问文件列表中描述的文件数量与预定阈值(例如，通过从文件描述符的上限值中减去1(整合库数量)而获得的值)之间进行比较，并且使处理根据比较结果进行分支。例如，可以采用如下配置：如果在访问文件列表中描述的文件数量小于或等于该阈值，则处理分支到步骤s15111，并且如果超过该阈值，则分支到步骤s15110。此外，可以是如下配置：如果在访问文件列表中描述的文件数量超过该阈值，则将访问文件列表中描述的一些文件整合为整合库，并且不整合剩余的。这样做，能够实现文件描述符的消耗量的抑制和存储的消耗的抑制。

其他实施例

本发明的实施例还可以通过如下的方法来实现，即，通过网络或者各种存储介质将执行上述实施例的功能的软件(程序)提供给系统或装置，该系统或装置的计算机或是中央处理单元(cpu)、微处理单元(mpu)读出并执行程序的方法。

虽然已经结合示例性实施例描述了本发明，应当认识到，本发明并不局限于公开的示例性实施例。所附权利要求的范围应当适合最广泛的解释，以便囊括所有变形、等同结构和功能。