KR20170085979A - 정보 처리장치 및 리소스 관리방법 - Google Patents

정보 처리장치 및 리소스 관리방법 Download PDF

Info

Publication number
KR20170085979A
KR20170085979A KR1020170005891A KR20170005891A KR20170085979A KR 20170085979 A KR20170085979 A KR 20170085979A KR 1020170005891 A KR1020170005891 A KR 1020170005891A KR 20170005891 A KR20170005891 A KR 20170005891A KR 20170085979 A KR20170085979 A KR 20170085979A
Authority
KR
South Korea
Prior art keywords
class
library
application
libraries
path
Prior art date
Application number
KR1020170005891A
Other languages
English (en)
Other versions
KR102090977B1 (ko
Inventor
키와무 하세가와
Original Assignee
캐논 가부시끼가이샤
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 캐논 가부시끼가이샤 filed Critical 캐논 가부시끼가이샤
Publication of KR20170085979A publication Critical patent/KR20170085979A/ko
Application granted granted Critical
Publication of KR102090977B1 publication Critical patent/KR102090977B1/ko

Links

Images

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/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0646—Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
    • G06F3/0647—Migration mechanisms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0662—Virtualisation aspects
    • G06F3/0667—Virtualisation aspects at data level, e.g. file, record or object virtualisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/54—Link editing before load time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/72—Code refactoring
    • 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30181—Instruction operation extension or modification
    • G06F9/30192—Instruction operation extension or modification according to data descriptor, e.g. dynamic data typing
    • 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/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • 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/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44568—Immediately runnable code
    • G06F9/44578—Preparing or optimising for loading
    • 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/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44589—Program code verification, e.g. Java bytecode verification, proof-carrying code
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Stored Programmes (AREA)

Abstract

본 발명에 따르면, 장치의 기동 처리의 일부로서, 또는 어플리케이션이 인스톨되는 경우에, 클래스 패스의 설정에 라이브러리가 복수 존재하는지 아닌지를 판정하여, 라이브러리가 복수 설정되어 있다고 판정된 경우에, 설정되어 있는 라이브러리를 전개하고, 전재한 라이브러리를 새로운 라이브러리로서 통합한 후에, 새롭게 작성한 라이브러리를 클래스 패스로서 설정한다.

Description

정보 처리장치 및 리소스 관리방법{INFORMATION PROCESSING APPARATUS AND RESOURCE MANAGEMENT METHOD}
본 발명은, 클래스 패스(class path)에 설정되어 있는 라이브러리를 관리하는 정보 처리장치 및 리소스 관리방법에 관한 것이다.
Java(등록상표)의 실행 환경에 있어서, 클래스(실행에 필요한 코드)가 클래스 로더에 의해 로드된다. 클래스는, JAR(Java Archive) 형식으로 라이브러리 내부에 있는 클래스 파일로 정의되어 있다. 라이브러리는 복수의 클래스의 클래스 파일로 구성되어 있고, 특정한 기능마다 나누어져 있는 경우가 많다. 이때, 라이브러리가 위치를 나타내는 패스는 클래스 패스로서 미리 Java(등록상표)의 실행 환경에 설정해 놓을 필요가 있다. 이것은, 클래스의 로드시에, 클래스 로더가 클래스 패스에 설정되는 있는 라이브러리를 탐색하여 로드할 클래스를 찾기 위해서이다. 여기에서, 클래스 로더는, 라이브러리를 참조해서 클래스를 탐색하기 위해, 파일 디스크립터를 사용하므로, 사용된 파일 디스크립터가 리소스로서 소비된다. Java(등록상표)의 실행 환경에서는, 퍼포먼스를 향상시키기 위해, 혹은 라이브러리에 대한 참조가 끊어지는 것에 의한 동작 불안정을 방지하기 위해, 한번 참조한 라이브러리는, 실행 환경에서 동작하는 프로그램이 종료할 때까지 참조된다. 그 때문에, 클래스 로더가 라이브러리를 참조하기 위해 소비한 파일 디스크립터는 프로그램이 종료할 때까지 계속해서 소비되게 된다.
임베디드 기기에 있어서, 어플리케이션 실행 환경인 정보 처리장치가 사용가능한 리소스가 제한된다. 파일 디스크립터도 리소스의 일종으로, 사용가능한 파일 디스크립터 수에 제한이 있다. 그 때문에, 이하와 같은 것이 행해지고 있다. 우선, 개발자는 어플리케이션이 사용할 리소스 량에 대한 상한값을 정한다. 그후, 유저 관리자가 어플리케이션을 개시할 때, 그 상한값에 근거하여, 어플리케이션 관리 프레임워크는 정보 처리장치가 사용가능한 리소스 량을 초과하지 않는지 확인한다.
종래기술로서, 전혀 사용된 적이 없는 클래스를 검지하고, 클래스 패스로부터 사용된 적이 없는 클래스를 갖는 라이브러리를 삭제하는 기술이 있다(예를 들면, 일본국 특개 2005-293084호 공보(특허문헌 1)).
일본국 특개 2005-293084호 공보는, 클래스 패스로부터 사용되는 클래스를 갖는 라이브러리를 남긴다. 즉, 클래스 패스로부터 사용되는 클래스를 갖는 라이브러리의 수가 많으면, 다수의 파일 디스크립터를 소비한다. 그 때문에, 파일 디스크립터의 사용가능한 수를 초과하면, 결과적으로 기동 처리에 영향을 미친다. 특히, 소프트웨어의 업데이트나 기능 확장에 의해 라이브러리의 수가 계속 증가하면, 소비된 파일 디스크립터의 수가 증가하게 된다.
상기한 내용을 감안하여, 본 발명은, 사용된 라이브러리의 수가 증가하더라도, 파일 디스크립터의 소비를 억제한다.
본 발명은, 그것의 제 1 면에서, 열린 라이브러리의 수에 의존하는 양의 리소스를 소비하는 정보 처리장치로서, 인스톨된 프로그램에 대해 설정된 클래스를 포함하는 라이브러리의 수가 2개 이상인지 판정하는 판정 수단과, 상기 라이브러리의 수가 2개 이상이라고 판정된 경우에, 상기 라이브러리에 포함된 클래스를, 상기 라이브러리의 수보다 적은 수의 라이브러리로 통합하는 통합 수단을 구비한 정보 처리장치를 제공한다.
본 발명에 따르면, 라이브러리 증가에 따르는 파일 디스크립터의 증가를 억제할 수 있다.
본 발명의 또 다른 특징 및 국면은 첨부된 도면을 참조하여 주어지는 이하의 실시형태의 상세한 설명으로부터 명백해질 것이다.
도 1은 화상 형성장치의 구성도이다.
도 2는 화상 형성장치의 하드웨어 구성도이다.
도 3은 제1 실시예의 화상 형성장치에 있어서의 어플리케이션 실행 환경의 구성도이다.
도 4a 및 도 4b는 제1 실시예에 있어서의 기동 옵션 설정 파일의 구성도이다.
도 5a, 도 5b 및 도 5c는 제1 실시예에 있어서의 어플리케이션 설정 파일의 구성도이다.
도 6은 화상 형성장치(100) 내에 있는 라이브러리 배치를 도시한 도면이다.
도 7a 및 도 7b는 제1 실시예에 있어서의 라이브러리 내부의 클래스 파일의 배치를 도시한 도면이다.
도 8a, 도 8b 및 도 8c는 제1 실시예에 있어서의 화상 형성장치에 의한 처리의 흐름을 나타낸 흐름도이다.
도 9는 제2 실시예의 화상 형성장치에 있어서의 어플리케이션 실행 환경의 구성도이다.
도 10a 및 도 10b는 제2 실시예에 있어서의 기동 옵션 설정 파일의 구성도이다.
도 11은 제2 실시예에 있어서의 어플리케이션 설정 파일의 구성도이다.
도 12는 제2 실시예에 있어서의 통합 라이브러리 내부의 클래스 파일의 배치를 도시한 도면이다.
도 13aa, 도 13ab 및 도 13b는 제2 실시예에 있어서의 화상 형성장치에 의한 처리의 흐름을 나타낸 흐름도이다.
도 14a 및 도 14b는 제3 실시예에 있어서의 화상 형성장치에 의한 처리의 흐름을 나타낸 흐름도이다.
이하, 본 발명을 실시하기 위한 형태에 대해 도면을 참조하여 설명한다.
제1 실시예
도 1에 나타낸 것은 본 발명의 제1 실시예의 시스템 전체의 구성을 나타낸 도면이다. 화상 형성장치(100)는 본 실시예를 구현한 정보 처리장치의 일례이며, 예를 들면, 다기능 주변 장치(MFP)이다. 정보 처리장치(101)는 화상 형성장치(100)를 관리한다. 네트워크(120)는 화상 형성장치(100)와 정보 처리장치(101)를 접속한다. 정보 처리장치(101)는 화상 형성장치(100)를 네트워크(120) 경유로 이용하기 위해서 사용된다. 어플리케이션 A(110)는 화상 형성장치(100) 상에서 동작하는 어플리케이션의 일례이다. 어플리케이션 B(111)은 마찬가지로 화상 형성장치(100) 상에서 동작하는 어플리케이션의 또 다른 일례이다. 더구나, 어플리케이션 C(112)는 마찬가지로 화상 형성장치(100) 상에서 동작하는 어플리케이션의 또 다른 일례이다. 화상 형성장치(100) 상에서는, 한 개, 혹은 복수의 어플리케이션을 동작시키는 것이 가능하다. 여기에서는, 어플리케이션을 3개 예시하고 있다. 이후, "어플리케이션(11n)"이라고 하는 표현은, 어플리케이션 A(110), 어플리케이션 B(111), 어플리케이션 C(112)로 대표되는 한개 또는 복수의 어플리케이션을 가리킨다. 일반 이용자 또는 관리자는 화상 형성장치(100)의 기본 기능, 어플리케이션(11n), 및, 화상 형성장치(100)와 어플리케이션(11n)을 관리하기 위한 리소스 관리 장치를 이용하는 것이 가능하다. 이와 같은 이용에 있어서는, 화상 형성장치(100)를 직접 조작, 혹은 네트워크(120) 경유로 정보 처리장치(101)로부터 조작하는 것이 가능하다.
화상 형성장치의 하드웨어 구성
도 2는 화상 형성장치(100)의 하드웨어 구성을 도식화한 것이다. 코어부(200)는 프로세서, 메모리 등을 포함하는 제어부이며, 코어부(200)에 접속된 다양한 디바이스를, 프로세서와 메모리가 상호작용해서 프로그램을 실행함으로써 제어한다. 또한, 어플리케이션의 실행 환경을 실현하고, 인스톨된 어플리케이션을 실행한다. 코어부(200)에는, 유저 인터페이스부(201), 기억장치(202), 네트워크(120)에 접속하기 위한 네트워크 인터페이스부(203), 스캐너부(204), 프린터부(205), 피니셔부(206) 등이 주변 디바이스로서 접속되어 있다. 코어부(200)는 이들 디바이스를 제어하고, 그 기능을 유저 인터페이스(201) 혹은 네트워크(120)를 거쳐 유저에게 제공하는 동시에, 어플리케이션에도 제공하고 있다.
어플리케이션 실행 환경
도 3은 본 실시예의 화상 형성장치(100) 상에 어플리케이션(11n)을 실행하기 위한 어플리케이션 실행 환경이다.
기동 모듈(300)은, 어플리케이션 실행 환경을 기동하기 위한 모듈이다. 유저가 화상 형성장치(100)의 전원을 넣으면, 시스템이 동작하기 시작하고, 기동 모듈(300)이, 본 실시예를 위한 처리인 통합 라이브러리의 작성 처리를 행하도록 Lib 관리 모듈(304)에 명령한다. Lib 관리 모듈(304)은, 본 실시예를 실시하기 위한 모듈이며, 클래스 패스에 설정되는 있는 라이브러리를 한개의 통합 라이브러리로서 재작성한다. 통합 라이브러리의 작성 처리가 끝난 후에, 기동 모듈(300)은 어플리케이션 실행 기반(301)을 기동한다. 어플리케이션 실행 기반(301)은 Java(등록상표)의 실행 환경이며, 예를 들면, Java(등록상표) VM(가상 머신)이다. 클래스 로더(302)는, 클래스를 로드하기 위한 모듈이다. 어플리케이션이나 시스템 프로그램이 실행되고 그 내부에서 클래스가 사용되면, 그 클래스는, 클래스 패스에 의해 특정되는 그 클래스를 포함하는 라이브러리로부터 클래스 로더(302)에 의해 동적으로 로드된다.
로드되기 전에 클래스의 실행 처리가 명령된 경우, 클래스 로더(302)는, 클래스 패스에 설정되는 있는 라이브러리를 탐색하여, 실행 처리가 명령되어 있는 클래스를 찾는다. 클래스는 어플리케이션 실행 기반(301)이 명령을 실행하기 위한 실행가능한 코드이고, 클래스 패스는 클래스를 포함하는 라이브러리의 장소를 나타내는 패스의 정보이다. 클래스 패스는 시스템이 필요로 하는 클래스가 포함된 제1 클래스 패스와, 각 어플리케이션(11n)용의 클래스가 포함되는 제2 클래스 패스를 포함한다. 시스템은 협의로는 오퍼레이팅 시스템으로 정의되지만, 본 예에서는, 오퍼레이팅 시스템을 포함한, 어플리케이션 이외의 소프트웨어 모듈도 가리킨다. 제1 클래스 패스는, 시스템의 클래스를 로드하기 위해 필요한 패스이며, 부트 클래스 패스와 시스템 클래스 패스 모두, 또는 그것들의 적어도 한쪽을 포함한다. 부트 클래스 패스는 Java(등록상표)의 실행 환경을 기동하기 위해 필요한 클래스를 포함하는 라이브러리의 장소를 나타내는 패스이다. 시스템 클래스 패스는 어플리케이션 실행 기반(301) 및 앱 관리 프레임워크(303)를 기동하기 위해서 필요한 클래스를 포함하는 라이브러리의 장소를 나타내는 패스이다. 이때, "앱(app)"은 "어플리케이션"의 약자이다. 제2 클래스 패스는, 어플리케이션의 클래스를 포함하는 라이브러리의 장소를 나타내는 앱 클래스 패스(혹은 어플리케이션 클래스 패스)이다. 제1 클래스 패스는, 기동 모듈(300)이 어플리케이션 실행 기반(301)을 기동할 때에 기동 옵션으로서 어플리케이션 실행 기반(301)으로 건네진다. 어플리케이션 실행 기반(301)은 그 건네진 제1 클래스 패스를 등록한다. 제2 클래스 패스는, 앱 관리 프레임워크(303)가 어플리케이션 내에 포함되는 앱 설정 파일(예를 들면, 도 5a에 나타낸 앱 설정 파일 502)로부터 판독하는 클래스 패스(도 5b에 나타낸 어플리케이션 클래스 패스(514))이며, 앱 관리 프레임워크(303)는 판독한 클래스 패스를 개시되고 있는 어플리케이션 만을 위한 제2 클래스 패스에 설정한다. 그 때문에, 제2 클래스 패스로 불려도, 다른 어플리케이션(11n) 각각에 대한 제2 클래스 패스는 모두 전혀 다른 클래스 패스가 된다. 본 예에서는, 앱 설정 파일은 Java(등록상표)의 매니페스트 파일이다.
클래스 로더(302)가 클래스 패스에 설정된 라이브러리를 탐색하여 클래스를 찾고, 라이브러리에서 탐색 대상의 클래스가 발견된 경우, 클래스 로더(302)는 라이브러리로부터 클래스를 로드한다. 그후, 어플리케이션 실행 기반(301)이 로드한 클래스를 실행한다. 대상의 클래스가 발견되지 않은 경우에는, 클래스가 발견되지 않았다는 것을, 콘솔 화면이나 브라우저의 화면 등의 유저 인터페이스부(201)를 거쳐, 유저에게 경고한다. 화상 형성장치(100)의 시스템이 동작할 때부터, 유저에 의해 화상 형성장치(100)의 전원이 꺼질 때까지 로드되지 않은 클래스가 실행되면, 이러한 클래스 로더(302)에 의한 클래스의 로드 처리가 행해진다. 또한, 클래스에는, 같은 이름을 갖는 클래스가 충돌하지 않도록, 이름 공간이 개발자에 의해 미리 주어져 있다. 라이브러리는 1개 이상의 클래스를 JAR(Java Archive) 파일로서 압축하여 얻어진 파일이다. 라이브러리 내부에서 클래스가 충돌하는 것을 방지하기 위해, 일반적으로 JAR 파일에는 이름 공간에 대응하는 디렉토리 계층이 구성되고, 그 내부에 클래스의 파일이 배치된다. 본 실시예에서도, 라이브러리 내부가 이름 공간의 디렉토리 계층으로 구성되어 있는 예를 사용하여 설명한다.
앱 관리 프레임워크(303)는 어플리케이션(11n)의 인스톨, 언인스톨, 실행과 정지를 관리하는 프레임워크이며, 예를 들면 OSGi이다. 어플리케이션 실행 환경 내에 어플리케이션(11n)을 인스톨해서 실행하기 위해, 앱 관리 프레임워크(303)를 이용한다. 관리자가 어플리케이션(11n)을 인스톨해서 개시하는 리퀘스트를 앱 관리 프레임워크(303)에 행함으로써, 앱 관리 프레임워크(303)는 앱 인스톨 처리나 앱 개시 처리를 행한다. 이때, 앱 관리 프레임워크(303)은 그 어플리케이션의 앱 설정 파일(예를 들면, 도 5a에 나타낸 앱 설정 파일 502)을 참조하여, 거기에 선언되어 있는 리소스 상한값(예를 들면, 도 5b의 리소스 상한값(513))이 현재의 어플리케이션 실행 환경 내의 리소스의 빈 용량 내부에 들어가는지 아닌지를 판정한다. 그리고, 충분하지 않은 빈 용량이 존재하는 경우에는, 앱 관리 프레임워크(303)는 어플리케이션의 개시를 중단시킨다.
이하의 내용은 본 실시예를 실시하기 위한 특별한 구성요소의 설명이다.
Lib 관리 모듈(304)은, 통합 라이브러리(305)를 작성하기 위한 모듈이다. Lib 관리 모듈(304)은 기동 모듈(300)에 의한 통합 라이브러리 작성 처리를 행하도록 명령된다. Lib 관리 모듈(304)은 기동 옵션 설정 파일(예를 들면, 도 4a의 기동 옵션 설정 파일 400)의 제1 클래스 패스(예를 들면, 도 4a의 클래스 패스(402))에 설정되는 있는 라이브러리 전체, 및 앱 설정 파일(예를 들면, 도 5a의 앱 설정 파일 502)의 제2 클래스 패스(예를 들면, 도 5b의 클래스 패스(514))에 설정되어 있는 라이브러리 전체를 추출한다. 그리고, Lib 관리 모듈(304)은, 추출해서 전개된 클래스를 새로운 통합 라이브러리(305)로서 JAR 파일 형식으로 재압축한다. Lib 관리 모듈(304)은, 통합 라이브러리를 작성한 후, 기동 옵션 설정 파일(예를 들면, 도 4a의 기동 옵션 설정 파일 400)에 있는 제1 클래스 패스(예를 들면, 도 4a의 클래스 패스(402))의 설정을 변경하여, 새롭게 작성한 통합 라이브러리(305)만을 남긴다. 또한, Lib 관리 모듈(304)은 앱 설정 파일(예를 들면, 도 5a의 앱 설정 파일 502)의 제2 클래스 패스(예를 들면, 도 5b의 클래스 패스(514))에 설정된 라이브러리의 기재를 삭제한다. 제1 클래스 패스, 혹은 제2 클래스 패스로서 설정되어 있는 복수의 라이브러리 내의 클래스 군을 합친 통합 라이브러리(305)는 제1 클래스 패스에 설정되는 유일한 라이브러리이며, 클래스 로더(302)는 통합 라이브러리를 보는 것 만으로 필요한 클래스를 탐색할 수 있다. 통합 라이브러리(305)는, Lib 관리 모듈(304)에 의해 작성되는 라이브러리이다. 통합 라이브러리(305)는, 상기한 것과 같이, 제1 클래스 패스, 혹은 제2 클래스 패스에 설정되어 있는 복수의 라이브러리의 클래스 군을 JAR 파일 형식으로 압축하여 얻어진 라이브러리이다. 통합 라이브러리(305)에 포함되는 클래스는, 일단 이 클래스가 클래스 로더에 의해 로드되면, 어플리케이션 실행 기반(301), 앱 관리 프레임워크(303) 및 어플리케이션(11n)에 의해 실행될 수 있다.
기동 옵션 설정 파일의 예
도 4a 및 도 4b는 본 실시예에 있어서의 기동 옵션 설정을 기재하는 대표적인 파일의 내용을 설명하는 도면이다.
도 4a는, 본 실시예에 있어서의 Lib 관리 모듈(304)에 의해 변경되지 않은 기동 옵션 설정 파일 400을 도시한 도면이다. 기동 옵션 설정 파일 400은, Lib 관리 모듈(304)이 통합 라이브러리를 작성하고 파일의 내용을 변경하기 전의 기동 옵션 설정 파일이다. 패스 401은, 어플리케이션 실행 기반(301)을 기동하기 위한 실행 파일의 장소를 나타내는 장소 정보이다. 패스 402는, 라이브러리의 장소를 나타낸 장소 정보이며, 제1 클래스 패스에 해당한다. 라이브러리(403)는, 제1 클래스 패스로서 설정되어 있는 라이브러리의 장소 정보이다. 제1 클래스 패스(402)에 설정된 라이브러리(403)는, 어플리케이션 실행 기반(301), 앱 관리 프레임워크(303) 등이, 처리를 실행하는데 필요한 클래스 군을 포함한다. 메인 프로그램(404)은, 어플리케이션 실행 기반(301)이 앱 관리 프레임워크(303)를 기동하기 위해서 필요한 메인 프로그램의 장소 정보이다.
도 4b는 본 실시예에 있어서의 Lib 관리 모듈에 의해 변경된 기동 옵션 설정 파일 410을 도시한 도면이다. 기동 옵션 설정 파일 410은, Lib 관리 모듈(304)이 통합 라이브러리를 작성하고 파일의 내용을 변경한 후의 기동 옵션 설정 파일이다. 기동 옵션 설정 파일 410은, 예를 들면, 기동 옵션 설정 파일 400을 변경해서 얻어진다. 기동 모듈(300)은 기동 옵션 설정 파일 410의 내용을 판독하고, 판독한 내용을 어플리케이션 실행 기반(301)의 기동 옵션으로서 사용한다. 통합 라이브러리(411)는, 제1 클래스 패스로서 설정되어 있는 통합 라이브러리(305)의 장소 정보이다. Lib 관리 모듈(304)은, 통합 라이브러리를 작성한 후, 기동 옵션 설정 파일 400의 클래스 패스 설정에 통합 라이브러리의 패스를 추가하고, 통합 라이브러리 이외의 라이브러리의 패스를 제1 클래스 패스 402로부터 삭제한다.
어플리케이션 파일의 예
도 5a는 본 실시예에 있어서의 어플리케이션(11n)을 구성하는 대표적인 파일의 내용을 설명하는 도면이다. 어플리케이션(11n)은 다수의 종류의 파일을 유지하고 있다. 앱 실행 코드 파일(500)은 어플리케이션의 실행 코드 등의 정보를 포함하는 파일이다. 앱 내포 라이브러리(501)는 어플리케이션의 처리를 실행하는데 필요한 라이브러리다. 어플리케이션(11n)의 처리의 실행에 있어서, 제1 클래스 패스(402)에 설정되어 있는 라이브러리(403)에 불충분한 특정한 클래스의 존재로 인해 기능을 실현할 수 없는 경우, 개발자는 어플리케이션용의 라이브러리를 앱 내포 라이브러리(501)로서 준비한다. 앱 설정 파일 502는, 어플리케이션 ID와 다른 기본 정보, 어플리케이션이 사용하는 리소스의 상한값, 및 제2 클래스 패스가 기재되어 있는 파일이다. 앱 설정 파일 502는 개발자에 의해 미리 기재되고, 앱 실행 코드 파일(500) 및 앱 내포 라이브러리(501)와 함께 어플리케이션(11n)에 포함되어 있다.
도 5b는, Lib 관리 모듈(304)에 의해, 제2 클래스 패스 514에 설정된 라이브러리의 기재를 삭제하기 전에, 앱 설정 파일 502에 기재되어 있는 항목의 예를 나타낸 도면이다. 어플리케이션 명(511)은 어플리케이션(11n)의 명칭이다. 어플리케이션 명(511)은 화상 형성장치(100)의 유저 인터페이스부(201) 등에 표시된다. 어플리케이션 ID(512)은, 앱 관리 프레임워크(303)가 각 어플리케이션(11n)을 고유하게 식별하기 위해서 제공되는 식별 정보다. 리소스 상한값(513)은, 어플리케이션(11n)이 사용하는 리소스의 상한값이다. 리소스 상한값(513)은 리소스마다 정의된다. 개발자는 미리 어플리케이션(11n)이 사용할 수 있는 리소스의 상한값을 계측해 두고, 계측된 상한값을 앱 설정 파일 502에 리소스 상한값(513)으로서 선언한다. 앱 관리 프레임워크(303)는, 어플리케이션(11n)을 인스톨해서 개시할 때에, 이 리소스 상한값(513)을 참조한다. 그리고, 앱 관리 프레임워크(303)는, 현재의 어플리케이션 실행 환경 내의 리소스에 대한 빈 용량 내부에 리소스 상한값(513)이 들어갈 것인지 아닌지를 판정한다. 앱 관리 프레임워크(303)는, 충분한 빈 용량이 존재하면 앱을 개시하고, 불충분한 빈 용량이 존재하면 어플리케이션(11n)의 개시를 중단한다. 제2 클래스 패스 514는, 어플리케이션(11n)의 처리를 실행할 때에 필요한 앱 실행 코드 파일(500)이나 앱 내포 라이브러리(501)의 장소를 나타내는 정보이다. 패스 515는 제2 클래스 패스에 설정되어 있는 앱 실행 코드 파일(500)이나 앱 내포 라이브러리(501)의 장소의 정보이다. 도 5b에서는, 간단하게 하기 위해서, 앱 실행 코드 파일(500)의 패스를 상대 패스로 설정하고 있지만, 절대 패스로 기재되어 있어도 된다. 또한, 일반적으로는, 앱 내포 라이브러리(501)는 제1 클래스 패스 402에 설정되어 있지 않은 라이브러리이므로, 제2 클래스 패스 514 내부에 장소를 나타낼 필요가 있다.
도 5c는, Lib 관리 모듈(304)에 의해 제2 클래스 패스 514에 설정된 라이브러리의 기재를 삭제된 후, 앱 설정 파일 502에 기재되어 있는 항목의 예를 나타낸 도면이다. 기동 모듈(300)이 통합 라이브러리(305)의 작성 처리를 Lib 관리 모듈(304)에게 명령하면, Lib 관리 모듈(304)은 앱 설정 파일 502의 제2 클래스 패스 514를 참조한다. 그리고, Lib 관리 모듈(304)은 거기에 설정되어 있는 앱 내포 라이브러리(501)를 추출하여, 제1 클래스 패스 402에 설정된 라이브러리 내부의 클래스, 및 앱 내포 라이브러리(501) 내부의 클래스를, 통합 라이브러리(305)로서 JAR 파일 형식으로 재압축한다. 그후, Lib 관리 모듈(304)은 제1 클래스 패스 402를 통합 라이브러리(305)만으로 변경한다. 변경에 의해 제1 클래스 패스 411이 얻어진다. 그리고, Lib 관리 모듈(304)은 앱 설정 파일 502의 제2 클래스 패스 514에 설정된 라이브러리의 기재를 삭제한다. 앱 설정 파일 520은, 제2 클래스 패스 514에 설정된 라이브러리의 기재를 삭제된 후의 앱 설정 파일이다. 라이브러리의 기재가 삭제된 후의 제2 클래스 패스 521에 설정된 유일한 패스는, 앱 실행 코드 파일(500)의 패스이다. 패스 522는 제2 클래스 패스에 설정되어 있는 앱 실행 코드 파일(500)의 장소 정보이다. 패스 515에서 설정되어 있었던 라이브러리는 Lib 관리 모듈(304)에 의해 통합 라이브러리(305)로서 기동 옵션 설정 파일의 제1 클래스 패스 411에 설정되기 때문에, Lib 관리 모듈(304)은 앱 설정 파일로부터 라이브러리의 설정을 삭제한다. 이때, 본 실시예에서는, 기동 옵션 설정 파일과 앱 설정 파일을 합쳐서 설정 파일로 부르는 일이 있다.
라이브러리 배치의 일례
도 6은, 화상 형성장치(100) 내부의 라이브러리 배치의 일례를 트리 형상으로 나타낸 구성도다. 폴더 601은, 제1 클래스 패스 402에 설정되어 있는 라이브러리를 배치하기 위한 폴더다. 도 6에서는, 라이브러리(601)가 화상 형성장치(100)의 내부, 즉 "Device" 아래의 "system" 폴더에 남아 있고, 기동 옵션 설정 파일 400에 기술된 제1 클래스 패스에 표시된 것과 동일한 폴더 구성이 남겨져 유지되어 있다. 그러나, 스토리지에 사용된 리소스를 경감시키기 위해서, 제1 클래스 패스 402의 설정으로부터 라이브러리(403)를 삭제한 후에, Lib 관리 모듈(304)이 라이브러리(601)를 삭제해도 된다. 통합 라이브러리(602)는, Lib 관리 모듈(304)에 의해 작성된 라이브러리이다. Lib 관리 모듈(304)은, 통합 라이브러리(602)를 작성한 후, 이 라이브러리 602의 패스를 제1 클래스 패스 411에 설정한다. 폴더 603은, 화상 형성장치(100)에 인스톨된 어플리케이션(11n)을 배치하기 위한 폴더다. 앱 관리 프레임워크(303)는, 어플리케이션(11n)을 인스톨할 때에, 앱 내포 라이브러리(501)를 어플리케이션(11n)으로부터 제거하고, 앱 내포 라이브러리(501)를 어플리케이션 격납용 폴더(603)에 배치한다. 본 실시예에서는, 간단하게 하기 위해서, 도 6에서는, 어플리케이션마다 라이브러리를 합쳐서 배치한 예를 제시하지만, 기동 옵션인 제1 클래스 패스 402 및 411과, 제2 클래스 패스 514가 정합하면, 이들 라이브러리가 임의의 장소에 배치되어도 된다. 도 6에서는, 예를 들면, PreviewApp으로 불리는 어플리케이션의 앱 내포 라이브러리(501)인 libpa1.jar 등이, PreviewApp으로 불리는 폴더 아래에 배치되어 있다.
클래스 파일의 배치의 일례
도 7a 및 도 7b는 본 실시예의 라이브러리 내부의 클래스 파일의 배치의 일례를 트리 형상으로 나타낸 구성도다. 도 7a는, Lib 관리 모듈(304)이 클래스 파일을 모아서 압축하기 위해서 추출하는 라이브러리 내부를 나타낸 도면이다. 라이브러리 701 내지 704는 제1 클래스 패스 402에 설정되어 있는 라이브러리이며, 그것의 내부에 포함된 클래스 파일과 그것의 배치가 표시되어 있다. 라이브러리 705 및 706은 제2 클래스 패스 514에 설정되어 있는 라이브러리이며, 그것의 내부에 포함된 클래스 파일과 그것의 배치를 나타낸다.
도 7b는, Lib 관리 모듈(304)이 라이브러리를 추출한 후, 모든 클래스 파일을 압축해서 작성한 통합 라이브러리(305)의 내부 구성을 나타낸 도면이다. 라이브러리 710은, 제1 클래스 패스 411에 설정되어 있는 통합 라이브러리이며, 그것의 내부에 포함된 클래스 파일과 그것의 배치를 나타낸다. 도 7a에 나타낸 클래스 파일은 모두가 통합 라이브러리 내부에 배치되어 있기 때문에, 클래스 로더(302)는 이 통합 라이브러리로부터 클래스를 간단히 탐색하여 필요한 클래스를 찾음으로써 처리의 실행에 필요한 클래스를 발견할 수 있다. 또한, 도 7a 및 도 7b의 예에서는, 라이브러리 내부의 상대적인 패스는 통합의 전후에 바뀌지 않는다.
화상 형성장치에 의한 어플리케이션 관련 처리
도 8a는, 유저가 화상 형성장치(100)의 전원을 넣을 때부터, 전원이 꺼질 때까지의 처리의 흐름을 모식적으로 나타낸 본 실시예에 있어서의 흐름도이다. 도 8a의 절차는, 코어부(200), 특히 코어부(200)에 포함된 프로세서에 의해 실행된다. 이 절차는 오퍼레이팅 시스템에 의한 개시되고, 각 소프트웨어 모듈이 각 스텝에서 동작한다. 이하의 설명에서는, 소프트웨어가 주체인 것처럼 절차를 기술하지만, 소프트웨어는 가상적인 처리 주체이며, 실체는 소프트웨어를 실행하는 프로세서 또는 프로세서 코어이다.
유저가 화상 형성장치(100)의 전원을 넣으면, 오퍼레이팅 시스템이 동작하기 시작하여, 우선 기동 모듈(300)이 기동되고, 스텝 S8101에서, 기동 모듈(300)이 Lib 관리 모듈(304)에게 통합 라이브러리의 작성 처리를 행하도록 명령한다. Lib 관리 모듈(304)에 의한 통합 라이브러리의 작성 처리에 대해서는 도 8b를 참조해서 설명한다. Lib 관리 모듈(304)이 통합 라이브러리 작성 처리를 완료하면, 스텝 S8102에서, 기동 모듈(300)은, 기동 옵션 설정 파일 410의 내용을 기동 옵션으로 하여 어플리케이션 실행 기반(301)을 기동한다. 어플리케이션 실행 기반(301)이 기동하면, 메인 프로그램(404)의 처리가 실행되고 처리가 진행된다. 어플리케이션 실행 기반(301)의 일부인 클래스 로더(302)는 클래스의 로드를 감시한다. 스텝 S8105에서, 클래스 로더(302)는, 클래스가 로드되었는지 아닌지를 판정한다. 스텝 S8105에서, 클래스 로더(302)가, 메인 프로그램의 실행중에 어플리케이션 실행 기반(301), 앱 관리 프레임워크(303), 혹은 어플리케이션(11n)이 클래스가 클래스 생성 처리를 실행했다고 판정하면, 스텝 S8103으로 처리가 진행하고, 클래스 생성 처리가 실행되지 않은 경우에는, 스텝 S8104로 처리가 진행한다. 스텝 S8103에서, 클래스 로더(302)는 클래스 로드 처리를 행한다. 클래스 로드 처리가 종료한 후, 스텝 S8106에서, 어플리케이션 실행 기반(301), 앱 관리 프레임워크(303), 혹은 어플리케이션(11n)이 클래스를 생성하고, 스텝 S8104로 처리가 진행한다. 스텝 S8104에서, 어플리케이션 실행 기반(301)은, 메인 프로그램의 기동후에, 유저에 의해 화상 형성장치(100)의 전원이 꺼졌는지 아닌지를, 예를 들면, 오퍼레이팅 시스템으로부터의 통지 등에 근거하여 판정한다. 어플리케이션 실행 기반(301)이 전원이 꺼졌다고 판정한 경우에는, 어플리케이션 실행 기반(301)은 화상 형성장치(100)의 전원을 끄기 위한 처리를 행하고, 화상 형성장치(100)의 시스템이 종료된다. 전원이 꺼지지 않은 경우에는, 어플리케이션 실행 기반(301)은 메인 프로그램을 계속해서 실행한다.
이렇게, 어플리케이션 실행 기반(301)은, 일단 기동되면, 스텝 S8105 내지 스텝 S8104의 루프에서 클래스의 생성과 전원 오프를 감시한다. 어플리케이션 실행 기반(301)은, 클래스가 생성되면 클래스를 로드하고, 전원이 오프로 되면 전원 오프 처리를 행한다.
통합 라이브러리의 작성 처리
도 8b는, 스텝 S8101의 상세 흐름도이며, 기동 모듈(300)에 의해 통합 라이브러리의 작성 처리가 명령되었을 때의 Lib 관리 모듈(304)에 의한 본 실시예에 있어서의 처리의 흐름을 모식적으로 나타낸 것이다. 스텝 S8201에서, Lib 관리 모듈(304)은, 제1 클래스 패스 402 및 제2 클래스 패스 514에 설정되어 있는 라이브러리의 합계 수가 2개 이상인지 판정한다. Lib 관리 모듈(304)은, 제1 클래스 패스에 대해서는 기동 옵션 설정 파일 400을, 제2 클래스 패스에 대해서는 앱 설정 파일 502를 참조함으로써 이들 클래스 패스에 대한 내용을 취득할 수 있다. 설정되어 있는 라이브러리의 수가 1개인 경우에는, Lib 관리 모듈(304)은 통합 라이브러리의 작성 처리를 행하지 않고 처리를 종료한다. 복수의 라이브러리가 설정되어 있는 경우에는, 스텝 S8202로 처리를 진행한다. 스텝 S8202에서, Lib 관리 모듈(304)은 기동 옵션 설정 파일 400을 판독하고, 제1 클래스 패스 402에 복수의 라이브러리가 설정되어 있는지 아닌지를 판정한다. 제1 클래스 패스 402에 라이브러리가 복수 설정되어 있는 경우에는, 스텝 S8203으로 처리를 진행하고, 복수의 라이브러리가 설정되지 않은 경우에는, 스텝 S8204로 처리를 진행한다. 스텝 S8203에서, Lib 관리 모듈(304)은, 제1 클래스 패스 402에 설정되어 있는 라이브러리 403을 모두 추출한다. 이때, Lib 관리 모듈(304)은, 라이브러리가 기재되어 있는 역순으로 라이브러리의 추출을 행한다. 예를 들면, 도 4a의 기재 내용의 경우, Lib 관리 모듈(304)은, Libsystem003.jar, Libsystem002.jar 및 Libsystem001.jar의 순서로 라이브러리를 추출한다. 이에 따라, 같은 이름을 갖는 클래스들이 같은 이름 공간에 우연히 존재하는 일이 발생하는 것으로 인해 충돌이 일어난 경우에, 기재의 역순으로 라이브러리를 추출함으로써, 먼저 추출된 클래스 파일을, 나중에 추출된 클래스 파일로 덮어쓸 수 있다. 일반적으로, 같은 이름 공간에서 같은 이름을 갖는 클래스가 충돌하는 경우, 클래스 패스가 앞에 설정된 클래스 파일을 로드한다. 따라서, 클래스의 충돌이 일어난 경우, 기재가 앞에 나타내는 클래스 파일, 즉 나중에 추출되는 클래스 파일로 덮어씀으로써, 원래 일반적인 환경에서 로드될 것으로 예측되는 클래스를 유지할 수 있다. 스텝 S8204에서, Lib 관리 모듈(304)은 화상 형성장치(100)에 인스톨되어 있는 어플리케이션(11n)이 있는지 아닌지를 판정한다. 인스톨되어 있는 어플리케이션이 없는 경우에는, 스텝 S8206으로 처리를 진행하고, 인스톨되어 있는 어플리케이션이 있는 경우에는, 스텝 S8205로 처리를 진행한다. 스텝 S8205에서, Lib 관리 모듈(304)은, 제2 클래스 패스 514에 설정되어 있는 앱 내포 라이브러리(501)를 모두 추출한다. 이때, Lib 관리 모듈(304)은, 라이브러리가 기재되는 역순으로 라이브러리의 추출을 행한다. 이 이유는 전술한 것과 같다. 앱 내포 라이브러리(501)의 추출 처리가 끝나면, 스텝 S8206으로 처리를 진행한다. 스텝 S8206에서, Lib 관리 모듈(304)은 스텝 S8203, 및 스텝 S8205에서 추출한 모든 클래스 파일을 통합 라이브러리(305)로서 1개의 JAR 파일 형식으로 압축한다. 통합 라이브러리(305)의 구성 예는 도 7b에 나타낸 것과 같으며, 도 7a에 나타낸 통합전의 모든 클래스 파일이 통합되어 있다. 그리고, 스텝 S8207에서, Lib 관리 모듈(304)은 스텝 S8206에서 압축해서 작성한 통합 라이브러리(305)를, 제1 클래스 패스 402의 설정에 추가한다. 통합 라이브러리의 추가후, 스텝 S8208에서, Lib 관리 모듈(304)은 제1 클래스 패스 402에 설정되어 있는 통합 라이브러리 이외의 라이브러리의 기재를 삭제한다. 이 예가 도 4b에 표시되어 있으며, 기동 옵션 설정 파일 410과 유사한 기재 내용을 갖는다. 여기에서, 스토리지를 위해 사용된 리소스를 경감시키기 위해서, 제1 클래스 패스 402의 설정으로부터 통합 라이브러리 이외의 기재를 삭제한 후에, Lib 관리 모듈(304)은, 화상 형성장치(100)의 내부에 남아 있는 라이브러리(601)를 삭제해도 된다. Lib 관리 모듈(304)은, 기동 옵션 설정 파일의 기재 내용을 변경하면, 통합 라이브러리(305)의 작성 처리를 종료한다.
클래스의 로드 처리
도 8c는, 스텝 S8103의 상세 흐름도이며, 메인 프로그램 실행중에 클래스가 생성될 때 클래스 로더(302)에 의한 본 실시예에 있어서의 처리의 흐름을 모식적으로 나타낸 것이다.
스텝 S8301에서, 클래스 로더(302)는, 실행중인 메인 프로그램에 의해 로드되지 않은 클래스가 실행되었는지 아닌지를 판정한다. 클래스가 로드된 경우에는 클래스 로드의 처리는 종료하고, 메인 프로그램의 처리를 진행한다. 로드되지 않은 클래스가 존재하는 경우에는, 스텝 S8302로 처리를 진행한다. 스텝 S8302에서, 클래스 로더(302)는, 통합 라이브러리(305)가 아미 열려 있는지 아닌지를 판정한다. 통합 라이브러리(305)가 열려 있다고 판정한 경우에는, 스텝 S8304로 처리를 진행하고, 통합 라이브러리(305)가 열려 있지 않은 것으로 판정한 경우에는, 스텝 S8303으로 처리를 진행한다. 스텝 S8303에서, 클래스 로더(302)는 제1 클래스 패스 411에 설정되어 있는 통합 라이브러리(305)를 연다. 이때, 열린 라이브러리의 수에 의존하는 양의 리소스를 소비한다. 구체적으로는, 1개의 파일이 열리기 때문에, 클래스 로더(302)는 파일 디스크립터를 1개만 소비한다. 그리고 스텝 S8304로 처리를 진행한다. 스텝 S8304에서, 클래스 로더(302)는 통합 라이브러리(305)에 로드하고 싶은 클래스가 있는지 아닌지를 판정한다. 로드하고 싶은 클래스가 발견된 경우, 스텝 S8305에서, 클래스 로더(302)는 통합 라이브러리(305)로부터 클래스를 로드하고, 클래스 로드 처리를 종료한다. 로드하고 싶은 클래스가 발견되지 않은 경우, 클래스 로더(302)는, 스텝 S8306에서, 클래스가 발견되지 않은 것을, 콘솔 화면이나 브라우저의 화면 등의 유저 인터페이스부(201)를 거쳐 유저에게 경고한다. 그리고 클래스 로드 처리를 종료한다.
이상과 같이, 본 발명의 제1 실시예에서는, 어플리케이션 실행 기반(301)의 기동전에, Lib 관리 모듈(304)은 통합 라이브러리(305)를 작성하고, 이 통합 라이브러리(305)만을 제1 클래스 패스 411에 설정한다. 그 결과, 클래스 파일이 모두 통합 라이브러리(305)에 포함되므로, 어플리케이션 실행 기반(301)을 기동한 후에, 클래스 로더(302)가 클래스를 탐색하는 경우, 클래스 로더(302)는 통합 라이브러리(305) 내부만을 탐색함으로써 클래스를 찾을 수 있다. 즉, 클래스 로더(302)가 단지 1개의 라이브러리만을 열므로, 사용되는 파일 디스크립터의 수도 1개로 유지할 수 있다. 따라서, 제1 클래스 패스 402에 설정되어 있는 라이브러리 수와, 제2 클래스 패스 514에 설정되어 있는 라이브러리 수에 상관없이, 클래스 로더(302)가 라이브러리를 열기 위해 사용되는 파일 디스크립터의 수를 1개로 유지할 수 있다.
또한, 통합 라이브러리(305)를 일단 작성하면, 다음에 화상 형성장치(100)가 기동될 때부터, Lib 관리 모듈(304)은, 스텝 S8201에서, 클래스 패스에 설정되어 있는 라이브러리의 수가 1개라고(통합 라이브러리 뿐이라고) 판정한다. 그 때문에, 통합 라이브러리(305)의 작성 처리는 처음으로 화상 형성장치(100)를 기동할 때에만 행할 필요가 있다. 더구나, 시스템의 업데이트나 어플리케이션의 인스톨이 발생하고, 기동 옵션 설정 파일 410이나 앱 설정 파일 502가 갱신된 경우에도, 화상 형성장치(100)가 다음에 기동될 때, Lib 관리 모듈(304)은 통합 라이브러리 작성 처리를 행한다. 어플리케이션 및 시스템 프로그램의 업데이트와 인스톨에 의해 설정 파일이 갱신됨으로써, 제1 클래스 패스나 제2 클래스 패스에 복수의 라이브러리가 설정될 수도 있다. 복수의 라이브러리가 존재하면, 화상 형성장치(100)가 다음번에 기동될 때, Lib 관리 모듈(304)이 스텝 S8201에서 이들 라이브러리를 검지하여, 통합 라이브러리를 다시 만들 수 있다. 또한, 예를 들면, 어플리케이션 실행 기반(301)이 새로운 어플리케이션의 인스톨과 설정 파일의 갱신을 감시하고, 갱신이 존재한다고 판정하면, Lib 관리 모듈(304)에 의해 도 8b의 처리가 실행되어도 된다.
이때, 본 실시예에서는, 통합 라이브러리 만을 제1 클래스 패스에 설정하지만, 화상 형성장치(100)에서 사용가능한 파일 디스크립터의 상한값이 초과하지 않는 한, 일부의 라이브러리 만을 통합 라이브러리로서 작성해도 된다. 예를 들면, Lib 관리 모듈(304)이 제1 클래스 패스 402에 설정되어 있는 라이브러리 만을 추출하고, 추출된 클래스 파일을 통합 라이브러리로서 압축한다. 그리고, Lib 관리 모듈(304)은, 통합 라이브러리를 제1 클래스 패스에 추가하고, 제1 클래스 패스에 설정되어 있는 추출한 라이브러리 만의 기재를 삭제한다. 이렇게 함으로써, Lib 관리 모듈(304)의 통합 라이브러리 작성의 처리가 감소하므로, 퍼포먼스를 향상시킬 수 있다. 따라서, 복수의 라이브러리가 존재하는 경우에는, 이들 라이브러리에 포함된 클래스를 이들 라이브러리의 수보다 적은 수의 라이브러리(본 실시예에서는 1개)로 통합한다. 통합후의 라이브러리의 수가 통합전의 라이브러리의 수보다도 적으면, 리소스 소비량의 절감의 과제를 해결할 수 있다.
제2 실시예
다음에, 본 발명의 제2 실시예에 대해 도면을 참조해서 설명한다.
제1 실시예에서는, 제1 클래스 패스 402와 제2 클래스 패스 514에 설정되는 라이브러리 내의 모든 클래스를 1개의 통합 라이브러리(305)로서 압축하였다. 여기에서, 어떤 어플리케이션 110의 제2 클래스 패스 514에 설정되는 라이브러리의 클래스가 1개의 통합 라이브러리로서 압축되면, 다른 어플리케이션(예를 들면, 111)으로부터 그 클래스를 실행할 수 있다. 그렇지만, 부정한 동작을 행하는 어플리케이션이나 악의가 있는 어플리케이션이 다른 어플리케이션의 클래스를 실행하면, 화상 형성장치(100)의 동작이 불안정해질 수 있다. 이때, 일반적으로는, 클래스 패스를 부트 클래스 패스, 시스템 클래스 패스, 앱 클래스 패스 등으로 나누고, 각각의 클래스 패스 설정에서 실행될 수 있는 클래스의 범위가 설정된다. 이에 따라, 부정한 동작을 행하는 어플리케이션과 악의가 있는 어플리케이션이, 다른 어플리케이션의 클래스를 실행하는 것을 방지할 수 있지만, 라이브러리수 증가로 인한 소비된 파일 디스크립터의 수의 증대를 방지할 수 없다. 제2 실시예에서는, 클래스의 범위마다 클래스를 통합함으로써, 액세스가능한 클래스의 제한과, 소비된 파일 디스크립터의 수의 억제를 양립한다.
본 발명의 제2 실시예의 장치의 구성을 도시한 도면은 도 1에 나타낸 것과 유사하다. 또한, 본 실시예의 화상 형성장치(100)의 하드웨어 구성은 도 2에 나타낸 것과 유사하다.
도 9는, 본 실시예의 화상 형성장치(100) 상에서 어플리케이션(11n)을 실행하기 위한 어플리케이션 실행 환경을 나타낸 것이다. 앱 클래스 로더 군(900)은, 앱 관리 프레임워크(303)가 각 어플리케이션에 대해 생성하는 앱 클래스 로더(901)를 합친 어플리케이션 클래스 로더군이다. 앱 클래스 로더(901)는, 앱 내포 라이브러리(501)의 클래스를 로드하기 위한 클래스 로더이다. 앱 관리 프레임워크(303)는, 어플리케이션(11n)을 개시할 때에, 개시할 어플리케이션용의 앱 클래스 로더(901)를 생성한다. 그 때문에, 각 어플리케이션(11n)에 대응하는 앱 클래스 로더(901)가 생성된다. 각종 클래스 로더의 동작으로서, 로드되지 않은 클래스가 실행된 경우, 우선 클래스 로더(302)가 부트 클래스 패스 1011 및 시스템 클래스 패스 1012(모두 도 10b에 예시되어 있다)에 설정되어 있는 라이브러리를 탐색하여 로드할 클래스를 찾는다. 제1 실시예에서는, 부트 클래스 패스와 시스템 클래스 패스를 합쳐서 제1 클래스 패스로 부르고 있었지만, 이하의 실시예에서는, 부트 클래스 패스와 시스템 클래스 패스로 실시예의 설명에서 별개로 부른다. 또한, 제1 실시예에서는 앱 클래스 패스를 제2 클래스 패스로 불렀지만, 이하의 실시예에서는 앱 클래스 패스로 불러 실시예의 설명을 행한다. 클래스 로더(302)가, 부트 클래스 패스 1011 및 시스템 클래스 패스 1012에 설정되어 있는 라이브러리에서 클래스를 찾을 수 있는 경우에는, 그 라이브러리로부터 클래스를 로드한다. 클래스를 찾을 수 없는 경우에는, 앱 클래스 로더 군(900)이 기동된다. 그리고, 처리를 실행하고 있는 어플리케이션(11n)에 대응하는 앱 클래스 로더(901)가, 앱 클래스 패스 1101에 설정되어 있는 라이브러리로부터 로드할 클래스를 탐색한다. 따라서, 클래스를 찾을 수 있으면, 앱 클래스 로더(901)가 클래스를 로드한다. 앱 클래스 로더(901)가 클래스를 찾을 수 없는 경우에는, 클래스가 발견되지 않은 것을 콘솔 화면과 브라우저의 화면 등의 유저 인터페이스부를 거쳐 유저에게 경고한다.
또한, 부트 클래스 패스 1011, 시스템 클래스 패스 1012, 각 어플리케이션(11n)에 대한 앱 클래스 패스 1101의 설정에서 실행할 수 있는 클래스의 범위는 각각 다르다.
통합 라이브러리 군(902)은, Lib 관리 모듈(304)에 의해 작성되는 통합 라이브러리를 합친 라이브러리 군이다. 본 실시예의 통합 라이브러리 군(902)은 부트 클래스 패스 통합 라이브러리(903), 시스템 클래스 패스 통합 라이브러리(904) 및 앱 클래스 패스 통합 라이브러리 군(906)을 포함한다. 각 어플리케이션(11n)에 대응하는 클래스를 통합하는 앱 클래스 패스 통합 라이브러리(905)는, 앱 클래스 로더(901)와 유사하게, 앱 클래스 패스 통합 라이브러리 군(906)의 라이브러리로서 존재한다.
이 통합 라이브러리 군(902)은 Lib 관리 모듈(304)에 의해 작성된다. Lib 관리 모듈(304)은, 기동 모듈(300)에 의해 통합 라이브러리 작성 처리를 행하도록 명령되면, 우선 부트 클래스 패스 1001에 설정되어 있는 라이브러리를 모두 추출한다. 그리고, Lib 관리 모듈(304)은 추출해서 전개된 클래스를 새로운 부트 클래스 패스 통합 라이브러리(903)로서 JAR 파일 형식으로 재압축한다.
Lib 관리 모듈(304)은, 부트 클래스 패스 통합 라이브러리(903)를 작성한 후, 기동 옵션 설정 파일 1000에 있는 부트 클래스 패스 1001의 설정을 변경하여, 새롭게 작성한 부트 클래스 패스 통합 라이브러리(903) 만을 남긴다.
다음에, Lib 관리 모듈은 시스템 클래스 패스 1002(도 10a를 참조해서 후술한다)에 설정되어 있는 라이브러리를 모두 추출한다.
그리고, Lib 관리 모듈(304)은 추출해서 전개된 클래스를 새로운 시스템 클래스 패스 통합 라이브러리(904)로서 JAR 파일 형식으로 재압축한다. 그후, Lib 관리 모듈(304)은, 기동 옵션 설정 파일 1000에 있는 시스템 클래스 패스 1002의 설정을 변경하여, 새롭게 작성한 시스템 클래스 패스 통합 라이브러리(904) 만 남긴다.
최후에, Lib 관리 모듈(304)은 인스톨되어 있는 어플리케이션(11n)마다, 앱 클래스 패스 통합 라이브러리 작성 처리를 행한다. 앱 클래스 패스 통합 라이브러리 작성 처리로서, 우선, Lib 관리 모듈(304)은 앱 클래스 패스 1101(도 11을 참조해서 후술한다)에 설정된 라이브러리를 모두 추출한다. 그리고, Lib 관리 모듈(304)은 추출해서 전개된 클래스를 새로운 앱 클래스 패스 통합 라이브러리(905)로서 JAR 파일 형식으로 재압축한다. Lib 관리 모듈(304)은, 새로운 앱 클래스 패스 통합 라이브러리(905)를 작성한 후, 앱 설정 파일 502에 있는 앱 클래스 패스(514)의 라이브러리의 설정을 변경하여, 새롭게 작성한 앱 클래스 패스 통합 라이브러리(905)만 남긴다. 이 시점까지 설명한 처리를 인스톨된 어플리케이션(11n) 모두에 대해 행하면, Lib 관리 모듈(304)에 의한 앱 클래스 패스 통합 라이브러리의 작성 처리가 완료된다.
이렇게 하여, Lib 관리 모듈(304)은 부트 클래스 패스, 시스템 클래스 패스 및 앱 클래스 패스로서 설정되어 있는 복수의 라이브러리 내부의 클래스 군으로 통합 라이브러리를 작성하고, 그 작성한 통합 라이브러리를 각각의 클래스 패스로서 설정한다. 통합 라이브러리를 클래스 패스의 종류마다 설정함으로써, 실행할 수 있는 클래스의 범위를 각각의 클래스 패스의 범위에 따라 설정할 수 있다.
기동 옵션 설정 파일 예
도 10a 및 도 10b는 본 실시예에 있어서의 기동 옵션 설정을 설명하는 대표적인 파일의 내용에 대해 설명하는 도면이다.
도 10a는, 본 실시예에 있어서의 Lib 관리 모듈(304)에 의해 변경되기 전의 기동 옵션 설정 파일 1000을 도시한 도면이다. 기동 옵션 설정 파일 1000은, Lib 관리 모듈(304)이 기동 옵션 설정 파일의 내용을 변경하기 전의 기재 내용이다. 부트 클래스 패스 1001은, Java(등록상표)의 실행 환경을 기동하기 위해서 필요한 라이브러리의 장소를 나타내기 위한 부트 클래스 패스이다. 시스템 클래스 패스 1002는, 어플리케이션 실행 기반(301) 및 앱 관리 프레임워크(303)를 기동하기 위해서 필요한 라이브러리의 장소를 나타내기 위한 시스템 클래스 패스이다.
도 10b는, 본 실시예에 있어서의 Lib 관리 모듈(304)에 의해 변경된 후의 기동 옵션 설정 파일 1010을 도시한 도면이다. 기동 옵션 설정 파일 1010은, Lib 관리 모듈(304)이 파일을 변경한 후의 기재 내용을 나타낸다. 본 실시예에서는, 기동 모듈(300)은 기동 옵션 설정 파일 1010의 내용을 판독하고, 판독한 내용을 어플리케이션 실행 기반(301)의 기동 옵션으로서 사용한다. 부트 클래스 패스 1011은, 부트 클래스 패스 통합 라이브러리(903)의 소재를 나타낸 클래스 패스이다. Lib 관리 모듈(304)은, 부트 클래스 패스 통합 라이브러리(903)의 작성후에, 기동 옵션 설정 파일 1000의 클래스 패스 설정에 부트 클래스 패스 통합 라이브러리를 추가해서, 이것을 새로운 부트 클래스 패스 1011로 설정하고, 통합 라이브러리 이외의 라이브러리를 부트 클래스 패스 1001로부터 삭제한다. 시스템 클래스 패스 1012는, 시스템 클래스 패스 통합 라이브러리(904)의 소재를 나타내는 클래스 패스이다. Lib 관리 모듈(304)은, 시스템 클래스 패스 통합 라이브러리(904)의 작성후에, 기동 옵션 설정 파일 1000의 클래스 패스 설정에 시스템 클래스 패스 통합 라이브러리를 추가해서 이것을 새로운 시스템 클래스 패스 1012로 설정하고, 통합 라이브러리 이외의 라이브러리를 시스템 클래스 패스 1002로부터 삭제한다.
앱 설정 파일 예
도 11은, Lib 관리 모듈(304)에 의해, 앱 클래스 패스(514)에 설정된 라이브러리의 기재가 삭제된 후의, 앱 설정 파일 502에 기재되어 있는 항목의 예를 나타낸 도면이다. 기동 모듈(300)이 통합 라이브러리의 작성 처리를 행하도록 Lib 관리 모듈(304)에게 명령하면, Lib 관리 모듈(304)은 앱 설정 파일 502의 앱 클래스 패스(514)를 참조한다. 그리고, Lib 관리 모듈(304)은 거기에 설정되어 있는 앱 내포 라이브러리(501)를 추출하고, 추출된 클래스를 앱 클래스 패스 통합 라이브러리(905)로서 JAR 파일 형식으로 재압축한다. 그후, Lib 관리 모듈(304)은 앱 클래스 패스(514)를 변경하여, 새롭게 작성한 앱 클래스 패스 통합 라이브러리(905) 만을 남기고, 앱 클래스 패스(514)에 설정된 통합 라이브러리 이외의 라이브러리의 기재를 삭제한다. 앱 설정 파일 1100은, Lib 관리 모듈(304)이 라이브러리의 기재를 삭제한 후의 앱 설정 파일을 나타내고 있다. 앱 클래스 패스 1101은, 앱 클래스 패스 통합 라이브러리(905)가 설정된 앱 클래스 패스이다. 장소 정보(1102)는, 앱 클래스 패스에 설정되어 있는 앱 실행 코드 파일(500)이나 앱 클래스 패스 통합 라이브러리의 장소의 정보이다.
통합 라이브러리 군의 구성 예
도 12는, Lib 관리 모듈(304)이 각 클래스 패스의 라이브러리를 추출한 후, 클래스 패스마다 클래스 파일을 압축해서 작성한 각각의 통합 라이브러리 내부를 나타낸 도면이다. 즉, 도 12는 통합 라이브러리 군(902)의 내용을 예시한다. 부트 클래스 패스 통합 라이브러리(1201)는, 부트 클래스 패스 1011에 설정되어 있는 부트 클래스 패스 통합 라이브러리(903) 내부의 클래스 파일의 배치이다. 시스템 클래스 패스 통합 라이브러리(1202)는, 시스템 클래스 패스 1012에 설정되어 있는 시스템 클래스 패스 통합 라이브러리(904) 내부의 클래스 파일의 배치이다. 클래스 패스 통합 라이브러리 1203 내지 1205는, 인스톨되어 있는 각 어플리케이션(11n)의 앱 클래스 패스 1101에 설정되어 있는 앱 클래스 패스 통합 라이브러리(905) 내부의 클래스 파일의 배치이다.
각 클래스 패스에 설정되어 있는 라이브러리의 클래스 파일은 각 통합 라이브러리 내에 모두 배치되어 있다. 그 때문에, 클래스 로더(302)와 앱 클래스 로더(901)는 이들 통합 라이브러리를 탐색하여 클래스를 찾는 것만으로, 처리의 실행에 필요한 클래스를 발견할 수 있다.
통합 라이브러리 생성 처리
도 13aa 및 도 13ab는, 스텝 S8101의 상세 흐름도를 나타낸 것으로, 기동 모듈(300)에 의해 통합 라이브러리의 작성 처리가 명령되었을 때의 Lib 관리 모듈(304)의, 본 실시예에 있어서의 처리의 흐름을 모식적으로 나타낸 것이다. 이때, 도 8a의 절차는, 본 실시예와 제1 실시예에서 공통이다. 화상 형성장치(100)의 전원을 넣은 후부터 전원을 끊을 때까지의 처리의 흐름은 제1 실시예와 유사하다.
스텝 S13101에서, Lib 관리 모듈(304)은 기동 옵션 설정 파일 1000을 판독하고, 부트 클래스 패스 1001에 복수의 라이브러리가 설정되어 있는지 아닌지를 판정한다. 부트 클래스 패스 1001에 라이브러리가 복수 설정되어 있는 경우에는, 스텝 S13102로 처리를 진행하고, 복수의 라이브러리가 설정되지 않은 경우에는, 스텝 S13110으로 처리를 진행한다. 스텝 S13102에서, Lib 관리 모듈(304)은, 부트 클래스 패스 1001에 설정되어 있는 라이브러리를 모두 추출한다. 이때, Lib 관리 모듈(304)은, 라이브러리가 기재되어 있는 역순으로 라이브러리의 추출을 행한다. 예를 들면, 도 10a의 기재 내용의 경우, Lib 관리 모듈((304)은 Libsystem002.jar 및 Libsystem001.jar의 순서로 라이브러리를 추출한다. 이에 따라, 같은 이름을 갖는 클래스들이 같은 이름 공간에 우연히 존재하는 일이 발생하는 것으로 인해 충돌이 일어난 경우에, 기재의 역순으로 라이브러리를 추출함으로써, 먼저 추출된 클래스 파일을, 나중에 추출된 클래스 파일로 덮어쓸 수 있다. 일반적으로, 같은 이름 공간에서 같은 이름을 갖는 클래스가 충돌하는 경우, 클래스 패스가 앞에 설정된 클래스 파일을 로드한다. 따라서, 클래스의 충돌이 일어난 경우, 기재가 앞에 나타내는 클래스 파일, 즉 나중에 추출되는 클래스 파일로 덮어씀으로써, 원래 일반적인 환경에서 로드될 것으로 예측되는 클래스를 유지할 수 있다. 스텝 S13103에서, Lib 관리 모듈(304)은 스텝 S13102에서 추출된 모든 클래스 파일을 부트 클래스 패스 통합 라이브러리(903)로서 1개의 JAR 파일 형식으로 압축한다. 그리고, 스텝 S13104에서, Lib 관리 모듈(304)은 스텝 S13103에서 압축해서 작성한 부트 클래스 패스 통합 라이브러리를 부트 클래스 패스 1001의 설정에 추가한다. 그후, 스텝 S13105에서, Lib 관리 모듈(304)은 부트 클래스 패스 1001에 설정되어 있는 부트 클래스 패스 통합 라이브러리 이외의 라이브러리의 기재를 삭제한다(기동 옵션 설정 파일 1011과 유사한 기재 내용이 된다). 여기에서, 스토리지를 위해 사용된 리소스를 경감시키기 위해서, 스텝 S13105의 후에, Lib 관리 모듈(304)이, 화상 형성장치(100)의 내부에 남아 있는 부트 클래스 패스 1001로서 설정된 라이브러리를 삭제해도 된다. Lib 관리 모듈(304)은 기동 옵션 설정 파일의 기재 내용을 변경하면, 스텝 S13110으로 처리를 진행한다.
스텝 S13110에서, Lib 관리 모듈(304)은 기동 옵션 설정 파일 1000을 판독하고, 시스템 클래스 패스 1002에 복수의 라이브러리가 설정되어 있는지 아닌지를 판정한다. 시스템 클래스 패스 1002에 라이브러리가 복수 설정되어 있는 경우에는, 스텝 S13111로 처리를 진행하고, 복수의 라이브러리가 설정되지 않은 경우에는, 스텝 S13120으로 처리를 진행한다. 스텝 S13111에서, Lib 관리 모듈(304)은 시스템 클래스 패스 1002에 설정되어 있는 라이브러리를 모두 추출한다. 이때, Lib 관리 모듈(304)은, 라이브러리가 기재되어 있는 역순으로 라이브러리의 추출을 행한다. 예를 들면, 도 10a의 기재 내용의 경우, Lib 관리 모듈(304)은 Libsystem004.jar 및 Libsyste m003.jar의 순서로 라이브러리를 추출한다. 이에 따라, 같은 이름을 갖는 클래스들이 같은 이름 공간에 우연히 존재하는 일이 발생하는 것으로 인해 충돌이 일어난 경우에, 기재의 역순으로 라이브러리를 추출함으로써, 먼저 추출된 클래스 파일을, 나중에 추출된 클래스 파일로 덮어쓸 수 있다. 일반적으로, 같은 이름 공간에서 같은 이름을 갖는 클래스가 충돌하는 경우, 클래스 패스가 앞에 설정된 클래스 파일을 로드한다. 따라서, 클래스의 충돌이 일어난 경우, 기재가 앞에 나타내는 클래스 파일, 즉 나중에 추출되는 클래스 파일로 덮어씀으로써, 원래 일반적인 환경에서 로드될 것으로 예측되는 클래스를 유지할 수 있다. 스텝 S13112에서, Lib 관리 모듈(304)은 스텝 S13111에서 추출한 모든 클래스 파일을 시스템 클래스 패스 통합 라이브러리(904)로서 1개의 JAR 파일 형식으로 압축한다. 그리고, 스텝 S13113에서, Lib 관리 모듈(304)은 압축해서 작성한 시스템 클래스 패스 통합 라이브러리를, 시스템 클래스 패스 1002의 설정에 추가한다. 그후, 스텝 S13114에서, Lib 관리 모듈(304)은 시스템 클래스 패스 1002에 설정되어 있는 시스템 클래스 패스 통합 라이브러리 이외의 라이브러리의 기재를 삭제한다(기동 옵션 설정 파일 1011과 유사한 기재 내용이 된다). 여기에서, 스토리지를 위해 사용된 리소스를 경감시키기 위해서, 스텝 S13114의 후에, Lib 관리 모듈(304)이, 화상 형성장치(100)의 내부에 남아 있는 시스템 클래스 패스 1002로서 설정되어 있었던 라이브러리를 삭제해도 된다. Lib 관리 모듈(304)은 기동 옵션 설정 파일의 기재 내용을 변경하면, 스텝 S13120으로 처리를 진행한다.
스텝 S13120에서, Lib 관리 모듈(304)은, 화상 형성장치(100)에 인스톨되어 있는 어플리케이션(11n)의 수만큼 스텝 S13121 내지 S13125의 처리를 반복한다. 어플리케이션(11n)이 인스톨되지 않으면, 통합 라이브러리의 작성 처리가 명령되었을 때의 Lib 관리 모듈(304)의 처리가 종료한다.
스텝 S13121에서, Lib 관리 모듈(304)은 앱 설정 파일 502를 판독하고, 앱 클래스 패스(514)에 복수의 라이브러리가 설정되어 있는지 아닌지를 판정한다. 앱 클래스 패스(514)에 라이브러리가 복수 설정되어 있는 경우에는, 스텝 S13122로 처리를 진행하고, 복수의 라이브러리가 설정되지 않은 경우, 다른 인스톨된 어플리케이션이 존재하지 않으면, Lib 관리 모듈(304)은 통합 라이브러리의 작성 처리를 종료한다.
다른 인스톨된 어플리케이션이 존재하는 경우에는, Lib 관리 모듈은 그 어플리케이션에 대하여 스텝 S13121 내지 S13125의 처리를 행한다. 스텝 S13122에서, Lib 관리 모듈(304)은, 앱 클래스 패스(514)에 설정되어 있는 라이브러리를 모두 추출한다(또는 전개한다). 이때, Lib 관리 모듈(304)은, 라이브러리가 기재되어 있는 역순으로 라이브러리의 추출을 행한다. 예를 들면, 도 5b의 기재 내용의 경우, Lib 관리 모듈(304)은 Libpa005.jar, Libp a004.jar, …-, Libpa001.jar의 순서로 라이브러리를 추출한다. 이에 따라, 같은 이름을 갖는 클래스들이 같은 이름 공간에 우연히 존재하는 일이 발생하는 것으로 인해 충돌이 일어난 경우에, 기재의 역순으로 라이브러리를 추출함으로써, 먼저 추출된 클래스 파일을, 나중에 추출된 클래스 파일로 덮어쓸 수 있다. 일반적으로, 같은 이름 공간에서 같은 이름을 갖는 클래스가 충돌하는 경우, 클래스 패스가 앞에 설정된 클래스 파일을 로드한다. 따라서, 클래스의 충돌이 일어난 경우, 기재가 앞에 나타내는 클래스 파일, 즉 나중에 추출되는 클래스 파일로 덮어씀으로써, 원래 일반적인 환경에서 로드될 것으로 예측되는 클래스를 유지할 수 있다. 스텝 S13123에서, Lib 관리 모듈(304)은 스텝 S13122에서 추출한 모든 클래스 파일을 앱 클래스 패스 통합 라이브러리(905)로서 1개의 JAR 파일로 압축한다. 그리고, 스텝 S13124에서 Lib 관리 모듈(304)은 스텝 S13112에서 압축해서 작성한 앱 클래스 패스 통합 라이브러리를, 앱 클래스 패스(514)의 설정에 추가한다. 그후, 스텝 S13125에서, Lib 관리 모듈(304)은 앱 클래스 패스(514)에 설정되어 있는 앱 클래스 패스 통합 라이브러리 이외의 라이브러리의 기재를 삭제한다(앱 설정 파일 1100과 유사한 기재 내용이 된다). 여기에서, 스토리지를 위해 사용된 리소스를 경감시키기 위해서, 스텝 S13114의 후에, Lib 관리 모듈(304)이, 화상 형성장치(100)의 내부에 남아 있는 앱 클래스 패스(514)로서 설정된 라이브러리를 삭제해도 된다. 화상 형성장치(100)에 인스톨되어 있는 어플리케이션(11n)에 대해 스텝 S13121 내지 S13125의 처리가 완료하면, Lib 관리 모듈(304)은 통합 라이브러리의 작성 처리를 종료한다.
클래스의 로드 처리
도 13b는, 스텝 S8103의 상세 흐름도이며, 메인 프로그램 실행중의 클래스 로더(302)와 앱 클래스 로더(901)의, 본 실시예에 있어서의 처리의 흐름을 모식적으로 나타낸 것이다.
스텝 S13200에서, 어플리케이션 실행 기반(301) 및 앱 관리 프레임워크(303) 또는 그 중 어느 한개가 클래스의 생성을 실행하면, 어플리케이션 실행 기반(301) 및 앱 관리 프레임워크(303) 또는 그 중 어느 한개가 클래스 로더(302)에게 생성된 클래스의 로드 처리를 행하도록 명령한다. 어플리케이션이 클래스의 생성 처리를 실행하면, 앱 클래스 로더 군(900) 중, 클래스를 생성하고자 하는 앱에 대한 앱 클래스 로더가, 클래스 로더(302)에게 생성된 클래스의 로드 처리를 행하도록 명령한다. 스텝 S13200에서, 클래스 로더(302)가 클래스의 로드 처리를 행하도록 명령되면, 스텝 S8301로 처리를 진행한다. 스텝 S8301에서, 클래스 로더(302)는, 실행중인 메인 프로그램에 의해 로드되지 않은 클래스가 실행되었는지 아닌지를 판정한다. 로드되지 않은 클래스가 존재하는 것으로 판정된 경우에, 스텝 S13201로 처리를 진행한다. 스텝 S13201에서, 클래스 로더(302)는, 부트 클래스 패스 통합 라이브러리(903)가 이미 열려 있는지 아닌지를 판정한다. 부트 클래스 패스 통합 라이브러리(903)가 열려 있다고 판정한 경우에는, 스텝 S13203으로 처리를 진행하고, 부트 클래스 패스 통합 라이브러리(903)가 열려 있지 않다고 판정한 경우에는, 스텝 S13202로 처리를 진행한다. 스텝 S13202에서, 클래스 로더(302)는 부트 클래스 패스 1011에 설정되어 있는 부트 클래스 패스 통합 라이브러리(903)를 연다. 그리고, 스텝 S13203으로 처리를 진행한다. 스텝 S13203에서, 클래스 로더(302)는 부트 클래스 패스 통합 라이브러리(903)에 로드하고 싶은 클래스가 있는지 아닌지를 판정한다. 로드하고 싶은 클래스가 발견된 경우, 스텝 S13204에서, 클래스 로더(302)는 부트 클래스 패스 통합 라이브러리(903)로부터 클래스를 로드하고, 클래스 로드 처리를 종료한다. 로드하고 싶은 클래스가 발견되지 않은 경우, 스텝 S13210으로 처리를 진행한다.
스텝 S13210에서, 클래스 로더(302)는, 시스템 클래스 패스 통합 라이브러리(904)가 이미 열려 있는지 아닌지를 판정한다. 시스템 클래스 패스 통합 라이브러리(904)가 열려 있다고 판정한 경우에는, 스텝 S13212로 처리를 진행하고, 시스템 클래스 패스 통합 라이브러리(904)가 열려 있지 않다고 판정한 경우에는, 스텝 S13211로 처리를 진행한다. 스텝 S13211에서, 클래스 로더(302)는 시스템 클래스 패스 1012에 설정되어 있는 시스템 클래스 패스 통합 라이브러리(904)를 연다. 그리고, 스텝 S13212로 처리를 진행한다. 스텝 S13212에서, 클래스 로더(302)는 시스템 클래스 패스 통합 라이브러리(904)에 로드하고 싶은 클래스가 있는지 아닌지를 판정한다. 로드하고 싶은 클래스가 발견된 경우, 스텝 S13213에서, 클래스 로더(302)는 시스템 클래스 패스 통합 라이브러리(904)로부터 클래스를 로드하고, 클래스 로드 처리를 종료한다. 로드하고 싶은 클래스가 발견되지 않은 경우, 스텝 S13224로 처리를 진행한다. 스텝 S13224에서, 클래스 로더(302)는, 앱 클래스 로더(901)에 의해 클래스의 로드 처리가 명령되었는지 아닌지를 판정한다. 어플리케이션 실행 기반(301), 혹은 앱 관리 프레임워크(303)가 클래스의 생성 처리를 실행하는 경우에는, 어플리케이션 실행 기반(301) 혹은 앱 관리 프레임워크(303)가 클래스 로더(302)에게 클래스의 로드 처리를 행하도록 명령한다. 이에 반해, 어플리케이션(11n)이 클래스의 생성 처리를 실행한 경우에는, 앱 클래스 로더(901)가 클래스 로더(302)에게 클래스의 로드 처리를 행하도록 명령한다. 스텝 S13224에 있어서의 클래스 로드 처리의 상태는, 클래스 로더(302)가 부트 클래스 패스 또는 시스템 클래스 패스에 설정되어 있는 라이브러리에서 로드할 클래스를 찾을 수 없는 상태이다. 그 때문에, 앱 클래스 로더(901)가 클래스 로드 처리를 명령한 경우, 클래스 로더(302)는 앱 클래스 로더(901)에 클래스 로드 처리를 되돌리고, 앱 클래스 로더(901)는 앱 클래스 패스에 설정되어 있는 라이브러리로부터 클래스 로드 처리를 행한다. 여기에서, 클래스 로더(302)는 클래스의 로드 처리를 명령한 앱 클래스 로더(901)로 처리를 되돌린다. 로드 처리를 명령한 앱 클래스 로더(901)는, 클래스의 생성 처리를 실행한 어플리케이션에 대한 앱 클래스 로더이므로, 어플리케이션 군 중에서, 클래스의 생성 처리를 실행한 앱에 대한 클래스 로드 처리를 행할 수 있다. 앱 클래스 로더(901)에 의한 클래스 로드 처리는 스텝 S13220에서 행한다. 어플리케이션 실행 기반(301) 혹은 앱 관리 프레임워크(303)가 클래스 로더(302)에게 클래스의 로드 처리를 행하도록 명령한 경우에는, 스텝 S8306A로 처리를 진행한다.
스텝 S13220에서, 앱 클래스 로더(901)는, 처리를 실행중인 어플리케이션(11n)에 대한 앱 클래스 패스 통합 라이브러리(905)가 이미 열려 있는지 아닌지를 판정한다. 앱 클래스 패스 통합 라이브러리(905)가 열려 있다고 판정한 경우에는, 스텝 S13222로 처리를 진행하고, 앱 클래스 패스 통합 라이브러리(905)가 열려 있지 않다고 판정한 경우에는, 스텝 S13221로 처리를 진행한다. 스텝 S13221에서, 앱 클래스 로더(901)는 앱 클래스 패스 1101에 설정되어 있는 앱 클래스 패스 통합 라이브러리(905)를 연다. 그리고, 스텝 S13222로 처리를 진행한다. 스텝 S13222에서, 앱 클래스 로더(901)는 앱 클래스 패스 통합 라이브러리(905)에 로드하고 싶은 클래스가 있는지 아닌지를 판정한다. 로드하고 싶은 클래스가 발견된 경우, 스텝 S13223에서, 앱 클래스 로더(901)는 앱 클래스 패스 통합 라이브러리(905)로부터 클래스를 로드하고, 클래스 로드 처리를 종료한다. 로드하고 싶은 클래스가 발견되지 않은 경우, 스텝 S8306B로 처리를 진행한다. 스텝 S8306, 혹은 스텝 S13223의 처리가 완료하면, 클래스 로드 처리를 종료한다.
이상의 절차를 아래와 같이 요약할 수 있다. 프로그램의 실행중에 클래스의 생성 처리가 실행되면, 클래스 로더는 클래스 로드 처리를 행한다. 생성할 클래스가 로드되지 않은 경우, 클래스 로더(302)는 부트 클래스 패스로서 설정되어 있는 부트 클래스 패스 통합 라이브러리(903)를 탐색하여 로드할 클래스를 찾는다. 부트 클래스 패스에 설정되어 있는 부트 클래스 패스 통합 라이브러리(903)에서 클래스를 찾을 수 있는 경우에는, 클래스 로더(302)는 부트 클래스 패스 통합 라이브러리(903)로부터 클래스를 로드한다. 부트 클래스 패스 통합 라이브러리(903)에서 클래스를 찾을 수 없는 경우, 클래스 로더(302)는 시스템 클래스 패스 통합 라이브러리(904)를 탐색하여 로드할 클래스를 찾는다. 시스템 클래스 패스 통합 라이브러리(904)에서 클래스를 찾을 수 있는 경우에는, 클래스 로더(302)는 시스템 클래스 패스에서 표시된 시스템 클래스 패스 통합 라이브러리(904)로부터 클래스의 로드를 행한다. 시스템 클래스 패스 통합 라이브러리(904)에서 클래스를 찾을 수 없는 경우, 클래스 로더(302)는 클래스 로드 처리를 중지하고, 실행중인 프로그램이 시스템인지 어플리케이션인지를 판정한다. 실행중인 프로그램이 어플리케이션 실행 기반(301)이나 앱 관리 프레임워크(303) 등의 시스템인 경우, 클래스 로더(302)는 클래스가 발견되지 않았다는 것을 경고하는 에러를 유저에게 제공한다. 실행중인 프로그램이 앱인 경우, 실행중인 앱의 앱 클래스 로더(901)가 클래스 로드 처리를 행한다. 이때, 어플리케이션의 실행 후에 어플리케이션 실행 기반(301)이나 앱 관리 프레임워크(303)가 실행되는 경우에는, 실행중인 프로그램이 앱이라고 판정되는 것으로 가정한다. 앱이 클래스 생성 처리를 실행하는 경우, 앱 클래스 로더 군(900)이 클래스 로더(302)에게 클래스의 로드 처리를 행하도록 명령한다. 클래스를 찾을 수 없을 때, 클래스의 로드 처리를 명령한 앱 클래스 로더(901)에게 클래스 로더(302)가 처리를 되돌림으로써, 프로그램 실행중에 앱에 대한 앱 클래스 로더(901)가 클래스 로드 처리를 개시할 수 있다. 예를 들면, 어플리케이션 A(110)에 대한 앱 클래스 로더를 앱 클래스 로더 A로서 주어지면, 실행중인 프로그램이 어플리케이션 A(110)인 경우, 앱 클래스 로더 A가 클래스의 로드 처리를 행하도록 클래스 로더(302)에게 명령한다. 클래스 로더(302)가 부트 클래스 패스 통합 라이브러리(903) 또는 시스템 클래스 패스 통합 라이브러리(904)에서 로드할 클래스를 찾을 수 없는 경우, 클래스 로더(302)는 앱 클래스 로더 A에게 처리를 되돌린다. 앱 클래스 로더 A에 처리가 되돌려지기 때문에, 복수의 어플리케이션 중에서 실행중인 어플리케이션 A(110)의 앱 클래스 패스에 설정되어 있는 앱 클래스 패스 통합 라이브러리로부터 클래스의 로드 처리를 실행할 수 있다. 앱 클래스 로더가 로드 처리를 개시하면, 앱 클래스 로더는, 대응하는 앱 클래스 패스 통합 라이브러리(905)를 탐색하여 로드할 클래스를 찾는다. 앱 클래스 패스 통합 라이브러리(905)에서 로드할 클래스를 찾을 수 있는 경우, 앱 클래스 로더 A는 클래스를 로드한다. 앱 클래스 패스 통합 라이브러리(905)에서 로드할 클래스를 찾을 수 없는 경우에는, 클래스 로더(302)는 클래스가 발견되지 않았다고 경고하는 에러를 유저에게 제공한다. 클래스 로더(302) 혹은 앱 클래스 로더 A가 클래스를 로드하거나, 혹은 로드할 클래스가 발견되지 않아 경고를 낸 경우, 클래스의 로드 처리가 종료한다.
이상과 같이, 본 발명의 제2 실시예에서는, 어플리케이션 실행 기반(301)의 기동전에, Lib 관리 모듈(304)은 각 클래스 패스에 대한 라이브러리를 통합해서 통합 라이브러리를 작성하고, 그 통합 라이브러리 만을 각 클래스 패스에 설정한다. 그 결과, 각 클래스 패스에 설정되어 있는 라이브러리의 클래스 파일이 모두 통합 라이브러리에 포함되므로, 클래스 로더(302)가 클래스를 탐색하는 경우, 클래스 로더(302)는 간단히 각 통합 라이브러리만을 탐색함으로써 클래스를 찾을 수 있다. 통합 라이브러리를 클래스 패스의 종류마다 설정하고 있으므로, 실행할 수 있는 클래스의 범위를 각각의 클래스 패스의 범위와 맞출 수 있다. 따라서, 각 클래스 패스에 설정되어 있는 라이브러리의 수에 상관없이, 클래스 로더에 의해 소비된 파일 디스크립터의 수를 클래스 패스의 종류의 수만큼 줄일 수 있다. 또한, 부정한 동작을 행하는 어플리케이션과 악의가 있는 어플리케이션이, 다른 어플리케이션의 클래스를 실행하는 것을 방지할 수 있다.
이때, 본 실시예에서는, 부트 클래스 패스, 시스템 클래스 패스 및 앱 클래스 패스에 대해 통합 라이브러리를 작성하고, 클래스 패스에 설정하는 구성을 채용하였다. 그러나, 화상 형성장치(100)에서 사용가능한 파일 디스크립터의 상한값이 초과하지 않으면, 일부의 종류의 클래스 패스에 대해서만, 통합 라이브러리를 작성해 설정해도 된다. 예를 들면, Lib 관리 모듈이 부트 클래스 패스 및 시스템 클래스 패스에 대하여만 통합 라이브러리를 작성하고, 이들 클래스 패스에 작성된 통합 라이브러리를 설정해도 된다. 이와 같이 함으로써, Lib 관리 모듈(304)에 의한 통합 라이브러리 작성 처리가 감소하기 때문에, 퍼포먼스를 향상시킬 수 있다.
제3 실시예
다음에, 본 발명의 제3 실시예에 대해 도면을 참조해서 설명한다.
제1 실시예 및 제2 실시예에서는, 화상 형성장치(100)의 기동시에 Lib 관리 모듈(304)이 통합 라이브러리를 작성하고, 통합 라이브러리를 클래스 패스에 설정한다. 화상 형성장치(100)의 기동시에, Lib 관리 모듈(304)이 앱 클래스 패스에 라이브러리가 복수 설정되어 있는지 아닌지를 판정하므로, 새롭게 어플리케이션(11n)이 인스톨되어도, 통합 라이브러리 작성 처리를 실행할 수 있다. 그렇지만, 어플리케이션(11n)을 화상 형성장치(100)에 인스톨한 후에, 유저 관리자가, 화상 형성장치(100)를 재기동하지 않고, 어플리케이션(11n)을 개시하는 경우가 있다. 그 경우, 화상 형성장치(100)를 재기동할 때까지, 새롭게 인스톨된 어플리케이션(11n)의 다수의 라이브러리에 대해, 클래스 로더가 파일 디스크립터를 소비해 버린다. 본 실시예는, 어플리케이션의 인스톨시에도 라이브러리의 통합 처리를 행함으로써, 화상 형성장치의 재기동을 행하지 않더라도, 클래스 라이브러리를 통합할 수 있는 시스템을 설명한다.
본 발명의 제3 실시예의 장치의 구성을 도시한 도면은 도 1과 유사하다. 또한, 본 실시예에 있어서의 화상 형성장치(100)의 하드웨어 구성은 도 2와 유사하다. 본 실시예에 있어서의 화상 형성장치(100) 상에서 어플리케이션(11n)을 실행하기 위한 어플리케이션 실행 환경의 구성도는 도 9와 유사하다. 기동 옵션 설정 파일 및 앱 설정 파일의 구성은 각각 도 10b 및 도 11과 유사하다. 또한, 화상 형성장치(100)의 기동으로부터 전원 오프까지의 처리 절차는 도 14a에 나타낸 것과 같다.
화상 형성장치(100)에 의한 처리
도 14a는, 본 실시예의 화상 형성장치(100)의 전원을 넣은 후부터 전원을 끊을 때까지의 처리의 흐름을 모식적으로 나타낸 흐름도다. 이때, 각각의 스텝은 도 8a 내지 도 8c와 상위하지만, 실행 주체 등은 도 8a 내지 도 8c와 유사하다. 스텝 S8101 및 스텝 S8102는 도 8a에 나타낸 처리와 유사하다. 스텝 S8101의 상세한 것은 도 13aa 및 도 13ab의 절차에서와 같다. 스텝 S14101에서, 메인 프로그램의 실행중에, 앱 관리 프레임워크(303)가 어플리케이션(11n)의 리퀘스트를 수신하였는지 아닌지를 판정한다. 유저 관리자가 화상 형성장치(100)에 어플리케이션(11n)의 인스톨을 행하도록 리퀘스트를 보내면, 앱 관리 프레임워크(303)가 그 리퀘스트를 수신한다. 어플리케이션(11n)의 인스톨 리퀘스트를 수신하면, 스텝 S14102로 처리를 진행하고, 이와 같은 리퀘스트를 수신하지 않으면, 스텝 S8103으로 처리를 진행한다. 스텝 S8103 및 스텝 S8104는 도 8a에 나타낸 처리와 유사하다. 스텝 S8103의 상세한 것은 도 13b의 절차에서 나타낸 것과 같다. 스텝 S14102에서, 앱 관리 프레임워크(303)가 스텝 S14101에서 유저에 의해 지정된 어플리케이션(11n)을 화상 형성장치(100)에 인스톨한다. 어플리케이션(11n)의 인스톨 처리가 완료하면, 스텝 S14103으로 처리를 진행한다. 스텝 S14103에서, 앱 관리 프레임워크(303)는 Lib 관리 모듈(304)에게, 인스톨되는 어플리케이션(11n)에 대한 앱 클래스 패스 통합 라이브러리(905)의 작성 처리를 행하도록 명령한다. Lib 관리 모듈(304)이 앱 클래스 패스 통합 라이브러리(905)의 작성 처리를 완료하면, 스텝 S14104로 처리를 진행한다. 스텝 S14104에서, 앱 관리 프레임워크(303)가 인스톨한 어플리케이션(11n)을 개시 준비 상태로 설정한다. 어플리케이션(11n)이 개시 준비한 상태가 되면, 유저 관리자는 인스톨한 어플리케이션(11n)의 개시 리퀘스트를 화상 형성장치(100)에 보낼 수 있다. 어플리케이션(11n)이 개시 준비 상태로 진입한 후, 스텝 S8103으로 처리를 진행한다.
통합 라이브러리 작성 처리
도 14b는, 스텝 S14103의 상세 흐름도이며, 앱 관리 프레임워크에 의해 앱 클래스 패스 통합 라이브러리의 작성 처리가 명령되었을 때의 Lib 관리 모듈의, 본 실시예에 있어서의 처리의 흐름을 모식적으로 나타낸 것이다.
스텝 S14201에서, Lib 관리 모듈(304)은 인스톨할 어플리케이션(11n)의 앱 설정 파일 502를 판독하고, 앱 클래스 패스(514)에 복수의 라이브러리가 설정되어 있는지 아닌지를 판정한다. 앱 클래스 패스(514)에 라이브러리가 복수 설정되어 있는 경우에는, 스텝 S13122로 처리를 진행하고, 복수의 라이브러리가 설정되지 않은 경우, Lib 관리 모듈(304)은 어플리케이션 인스톨시의 앱 클래스 패스 통합 라이브러리(905)의 작성 처리를 종료한다. 스텝 S13122 내지 S13125는 도 13b에 나타낸 처리와 유사하다.
본 실시예에 있어서의 클래스 로더(302) 및 앱 클래스 로더(901)에 의한 클래스 로드시의 처리의 흐름은 도 13aa 및 도 13ab와 유사하다.
이상과 같이, 본 발명의 제3 실시예에서는, 어플리케이션(11n)을 인스톨한 후에, Lib 관리 모듈(304)이 앱 클래스 패스 통합 라이브러리(905)를 작성하고, 작성된 앱 클래스 패스 통합 라이브러리(905)를 앱 클래스 패스 1101에 설정한다. 앱 클래스 패스 통합 라이브러리 작성 처리 후에, 앱 관리 프레임워크(303)가 인스톨한 어플리케이션(11n)을 개시 준비 상태로 설정한다. 그 결과, 화상 형성장치(100)를 재기동하기 전에, 유저 관리자에 의해 인스톨된 어플리케이션(11n)을 개시해도, 앱 클래스 로더(901)가 앱 클래스 패스 통합 라이브러리(905)를 이용할 수 있다. 즉, 인스톨한 어플리케이션(11n)의 클래스 패스에 설정되어 있는 라이브러리의 수에 상관없이, 인스톨한 어플리케이션에 대한 앱 클래스 로더(901)에 의해 소비되는 파일 디스크립터의 수를 1개로 줄일 수 있다.
기타 실시예
제3실시예는, 제2실시예를 베이스로 하고 있지만, 제1 실시예를 베이스로 하여도 된다. 그 경우에는, 도 14a의 스텝 S8101의 상세를 도 8b에 나타낸 것과 같이 하고, 스텝 S8103의 상세를 도 8c에 나타낸 것과 같이 한다. 또한, 도 14b의 스텝 S13122 내지 S13125를, 도 8b의 스텝 S8205 내지 스텝 S8208로 치환하면 된다.
본 발명의 실시형태는, 본 발명의 전술한 실시형태(들)의 1개 이상의 기능을 수행하기 위해 기억매체('비일시적인 컴퓨터 판독가능한 기억매체'로서 더 상세히 언급해도 된다)에 기록된 컴퓨터 실행가능한 명령(예를 들어, 1개 이상의 프로그램)을 판독하여 실행하거나 및/또는 전술한 실시예(들)의 1개 이상의 기능을 수행하는 1개 이상의 회로(예를 들어, 주문형 반도체 회로(ASIC)를 포함하는 시스템 또는 장치의 컴퓨터나, 예를 들면, 전술한 실시형태(들)의 1개 이상의 기능을 수행하기 위해 기억매체로부터 컴퓨터 실행가능한 명령을 판독하여 실행함으로써, 시스템 또는 장치의 컴퓨터에 의해 수행되는 방법에 의해 구현될 수도 있다. 컴퓨터는, 1개 이상의 중앙처리장치(CPU), 마이크로 처리장치(MPU) 또는 기타 회로를 구비하고, 별개의 컴퓨터들의 네트워크 또는 별개의 컴퓨터 프로세서들을 구비해도 된다. 컴퓨터 실행가능한 명령은, 예를 들어, 기억매체의 네트워크로부터 컴퓨터로 주어져도 된다. 기록매체는, 예를 들면, 1개 이상의 하드디스크, 랜덤 액세스 메모리(RAM), 판독 전용 메모리(ROM), 분산 컴퓨팅 시스템의 스토리지, 광 디스크(콤팩트 디스크(CD), 디지털 다기능 디스크(DVD), 또는 블루레이 디스크(BD)TM 등), 플래시 메모리소자, 메모리 카드 등을 구비해도 된다.
본 발명은, 상기한 실시형태의 1개 이상의 기능을 실현하는 프로그램을, 네트워크 또는 기억매체를 개입하여 시스템 혹은 장치에 공급하고, 그 시스템 혹은 장치의 컴퓨터에 있어서 1개 이상의 프로세서가 프로그램을 읽어 실행하는 처리에서도 실행가능하다. 또한, 1개 이상의 기능을 실현하는 회로(예를 들어, ASIC)에 의해서도 실행가능하다.
예시적인 실시형태들을 참조하여 본 발명을 설명하였지만, 본 발명이 이러한 실시형태에 한정되지 않는다는 것은 자명하다. 이하의 청구범위의 보호범위는 가장 넓게 해석되어 모든 변형, 동등물 구조 및 기능을 포괄하여야 한다.

Claims (16)

  1. 열린 라이브러리의 수에 의존하는 양의 리소스를 소비하는 정보 처리장치로서,
    인스톨된 프로그램에 대해 설정된 클래스를 포함하는 라이브러리의 수가 2개 이상인지 판정하는 판정 수단과,
    상기 라이브러리의 수가 2개 이상이라고 판정된 경우에, 상기 라이브러리에 포함된 클래스를, 상기 라이브러리의 수보다 적은 수의 라이브러리로 통합하는 통합 수단을 구비한 정보 처리장치.
  2. 제 1항에 있어서,
    상기 라이브러리는 1개 이상의 클래스를 압축하여 얻어진 파일이고,
    상기 통합 수단은, 상기 판정 수단에 의해 라이브러리의 수가 2개 이상이라고 판정된 경우에, 상기 라이브러리를 추출하고, 추출된 라이브러리를 상기 라이브러리의 수보다 적은 수의 라이브러리로 압축해서 통합하는 정보 처리장치.
  3. 제 1항 또는 제 2항에 있어서,
    상기 통합 수단은, 상기 정보 처리장치가 기동될 때, 상기 라이브러리를 통합하는 정보 처리장치.
  4. 제 1항 또는 제 2항에 있어서,
    상기 통합 수단은, 상기 프로그램으로서 어플리케이션이 인스톨될 때, 상기 라이브러리를 통합하는 정보 처리장치.
  5. 제 1항 또는 제 2항에 있어서,
    상기 프로그램을 실행할 때, 상기 프로그램에 의해 사용되는 클래스를 포함하는 라이브러리를 열어서 이 클래스를 로드하는 로드 수단을 더 구비한 정보 처리장치.
  6. 제 1항 또는 제 2항에 있어서,
    상기 판정 수단은, 인스톨된 상기 프로그램의 설정 파일에 기술된 라이브러리의 장소를 나타내는 클래스 패스를 참조하여, 상기 프로그램에 대해 설정되는 클래스를 포함하는 라이브러리를 특정하는 정보 처리장치.
  7. 제 1항 또는 제 2항에 있어서,
    상기 통합 수단은, 상기 라이브러리에 포함된 클래스를 1개의 라이브러리로 통합하는 정보 처리장치.
  8. 제 6항에 있어서,
    상기 통합 수단은, 상기 라이브러리에 포함된 클래스를, 상기 클래스 패스마다 1개의 라이브러리로 통합하는 정보 처리장치.
  9. 제 8항에 있어서,
    상기 프로그램은 시스템 프로그램과 어플리케이션을 포함하고, 상기 시스템 프로그램에 대해서는, 상기 설정 파일에 부트 클래스 패스와 시스템 클래스 패스가 기술되고, 상기 어플리케이션에 대해서는, 상기 설정 파일에 어플리케이션 클래스 패스가 기술되고,
    상기 통합 수단은, 상기 라이브러리에 포함된 클래스를, 상기 클래스 패스마다 1개의 라이브러리로 통합하는 정보 처리장치.
  10. 제 1항 또는 제 2항에 있어서,
    상기 통합 수단은, 통합할 클래스를 포함하는 라이브러리를 생성함으로써, 상기 라이브러리를 통합하는 정보 처리장치.
  11. 제 1항 또는 제 2항에 있어서,
    상기 통합 수단은, 통합전에 상기 라이브러리에 존재하는 클래스의 상대적인 구성이 상기 라이브러리의 통합후에 유지되도록 상기 라이브러리를 통합하는 정보 처리장치.
  12. 제 1항 또는 제 2항에 있어서,
    상기 리소스는 파일 디스크립터를 포함하는 정보 처리장치.
  13. 열린 라이브러리의 수에 의존하는 양의 리소스를 소비하는 정보 처리장치에 대한 리소스 관리방법으로서,
    인스톨된 프로그램에 대해 설정된 클래스를 포함하는 라이브러리의 수가 2개 이상인지 판정하는 단계와,
    상기 라이브러리의 수가 2개 이상이라고 판정된 경우에, 상기 라이브러리에 포함된 클래스를, 상기 라이브러리의 수보다 적은 수의 라이브러리로 통합하는 단계를 포함하는 리소스 관리방법.
  14. 제 13항에 있어서,
    상기 라이브러리는 1개 이상의 클래스를 압축하여 얻어진 파일이고,
    상기 통합단계에서, 상기 판정단계에서 라이브러리의 수가 2개 이상이라고 판정된 경우에, 상기 라이브러리를 추출하고, 추출된 라이브러리를 상기 라이브러리의 수보다 적은 수의 라이브러리로 압축해서 통합하는 리소스 관리방법.
  15. 열린 라이브러리의 수에 의존하는 양의 리소스를 소비하는 컴퓨터를,
    인스톨된 프로그램에 대해 설정된 클래스를 포함하는 라이브러리의 수가 2개 이상인지 판정하는 판정 수단과,
    상기 라이브러리의 수가 2개 이상이라고 판정된 경우에, 상기 라이브러리에 포함된 클래스를, 상기 라이브러리의 수보다 적은 수의 라이브러리로 통합하는 통합 수단으로서 기능시키기 위해 매체에 기억된 프로그램.
  16. 제 15항에 있어서,
    상기 라이브러리는 1개 이상의 클래스를 압축하여 얻어진 파일이고,
    상기 통합 수단은, 상기 판정 수단에 의해 라이브러리의 수가 2개 이상이라고 판정된 경우에, 상기 라이브러리를 추출하고, 추출된 라이브러리를 상기 라이브러리의 수보다 적은 수의 라이브러리로 압축해서 통합하는, 프로그램.
KR1020170005891A 2016-01-15 2017-01-13 정보 처리장치 및 리소스 관리방법 KR102090977B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016006558A JP2017126293A (ja) 2016-01-15 2016-01-15 情報処理装置及びリソース管理方法
JPJP-P-2016-006558 2016-01-15

Publications (2)

Publication Number Publication Date
KR20170085979A true KR20170085979A (ko) 2017-07-25
KR102090977B1 KR102090977B1 (ko) 2020-04-23

Family

ID=57614262

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020170005891A KR102090977B1 (ko) 2016-01-15 2017-01-13 정보 처리장치 및 리소스 관리방법

Country Status (5)

Country Link
US (1) US10169022B2 (ko)
EP (1) EP3193252B1 (ko)
JP (1) JP2017126293A (ko)
KR (1) KR102090977B1 (ko)
CN (1) CN106980516B (ko)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111198708A (zh) * 2018-11-16 2020-05-26 北京奇虎科技有限公司 一种jar包冲突解决方法和装置
CN113626040B (zh) * 2020-05-06 2023-12-22 伊姆西Ip控股有限责任公司 用于安装应用的方法、电子设备和计算机程序产品
CN116893858B (zh) * 2023-09-11 2023-12-12 西安智多晶微电子有限公司 一种FPGA快速启动PCIe的配置方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000029706A (ja) * 1997-10-31 2000-01-28 Sun Microsyst Inc クラスファイルのプリプロセシング及びパッケ―ジングのための方法及び装置
US20040103404A1 (en) * 2002-11-25 2004-05-27 Gleb Naumovich Class coalescence for obfuscation of object-oriented software
JP2007206965A (ja) * 2006-02-01 2007-08-16 Canon Inc 情報処理装置及び当該装置におけるオブジェクト指向プログラムの実行方法とそのプログラム
US20080301710A1 (en) * 2007-05-31 2008-12-04 Ritesh Shetty Class Loader for Managing a Network
JP2013186779A (ja) * 2012-03-09 2013-09-19 Nec Corp 情報処理装置およびプログラム実行方法

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5548759A (en) * 1994-07-05 1996-08-20 Microsoft Corporation System for storing executable code within a resource data section of an executable file
ATE496330T1 (de) * 2002-11-29 2011-02-15 Research In Motion Ltd Verfahren zur erzeugung eines interpretierbaren codes zur speicherung auf einer vorrichtung mit begrenzter speicherkapazität
KR100518584B1 (ko) * 2003-07-12 2005-10-04 삼성전자주식회사 공유 라이브러리 시스템 및 상기 시스템 구축 방법
US7434215B2 (en) * 2003-09-11 2008-10-07 International Business Machines Corporation Mechanism for loading plugin classes at an appropriate location in the class loader hierarchy
JP4168962B2 (ja) 2004-03-31 2008-10-22 日本電気株式会社 Ｊａｖａクラスパスの最適化方式
US7814484B2 (en) * 2004-05-14 2010-10-12 Bea Systems, Inc. System and method for web application extensibility
US20070050760A1 (en) * 2005-08-30 2007-03-01 Erxiang Liu Generation of application specific xml parsers using jar files with package paths that match the xml xpaths
US8458753B2 (en) * 2006-02-27 2013-06-04 Time Warner Cable Enterprises Llc Methods and apparatus for device capabilities discovery and utilization within a content-based network
US9477495B2 (en) * 2006-08-17 2016-10-25 International Business Machines Corporation Conservative class preloading for real time Java execution
US8875115B2 (en) * 2008-11-29 2014-10-28 International Business Machines Corporation Type merging technique to reduce class loading during Java verification
US8387032B1 (en) * 2009-03-04 2013-02-26 Adobe Systems Incorporated Captive runtime deployment
WO2011143181A2 (en) * 2010-05-10 2011-11-17 Tibco Software Inc. Managing static data structures of legacy software in dynamic class loader environments
FR2960668A1 (fr) * 2010-05-27 2011-12-02 Airbus Operations Sas Procede et dispositif de configuration incrementale de modules de type ima
US9703551B2 (en) * 2014-04-28 2017-07-11 Ca, Inc. Modifying mobile application binaries to call external libraries
US20160232017A1 (en) * 2015-02-10 2016-08-11 ZeroTurnaround AS System and Method for Reloading Constructors
US10191753B2 (en) * 2016-03-30 2019-01-29 Oracle International Corporation Generating verification metadata and verifying a runtime type based on verification metadata

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000029706A (ja) * 1997-10-31 2000-01-28 Sun Microsyst Inc クラスファイルのプリプロセシング及びパッケ―ジングのための方法及び装置
US20040103404A1 (en) * 2002-11-25 2004-05-27 Gleb Naumovich Class coalescence for obfuscation of object-oriented software
JP2007206965A (ja) * 2006-02-01 2007-08-16 Canon Inc 情報処理装置及び当該装置におけるオブジェクト指向プログラムの実行方法とそのプログラム
US20080301710A1 (en) * 2007-05-31 2008-12-04 Ritesh Shetty Class Loader for Managing a Network
JP2013186779A (ja) * 2012-03-09 2013-09-19 Nec Corp 情報処理装置およびプログラム実行方法

Also Published As

Publication number Publication date
JP2017126293A (ja) 2017-07-20
US10169022B2 (en) 2019-01-01
KR102090977B1 (ko) 2020-04-23
US20170206072A1 (en) 2017-07-20
CN106980516B (zh) 2020-04-10
EP3193252B1 (en) 2021-02-17
CN106980516A (zh) 2017-07-25
EP3193252A1 (en) 2017-07-19

Similar Documents

Publication Publication Date Title
KR100868410B1 (ko) 관리화된 파일 시스템 필터 모델 및 아키텍쳐
US9880889B2 (en) Virtual application extension points
US9304791B2 (en) State separation for virtual applications
US7516319B2 (en) Method for booting a computer with second OS involves formatting portion of main memory with a second file system to generate ramdisk
US7409537B2 (en) Fast booting an operating system from an off state
US20170308369A1 (en) Data processing method and device of preset application after upgrading
US9542228B2 (en) Image processing apparatus, control method thereof and storage medium
US8499143B2 (en) Method for shortening the boot time of a computer system
US11775475B2 (en) Deferred path resolution during container deployment
KR20150070121A (ko) Bpram을 사용한 소프트웨어 애플리케이션들의 레이아웃 및 실행
WO2018081349A1 (en) Smart storage policy
KR102090977B1 (ko) 정보 처리장치 및 리소스 관리방법
EP2113859A1 (en) Computer, operation rule application method, and operating system
US11200036B2 (en) Information processing apparatus, method of controlling the same, and storage medium
US9588755B2 (en) Information processing apparatus capable of controlling installation of application, method of controlling the same, and storage medium
US20220374256A1 (en) Information processing system, information processing apparatus, method of controlling the same, and storage medium
EP4290376A1 (en) Reducing deployment time for container clones in computing environments
US10387168B2 (en) Information processing apparatus and library management method
KR101384929B1 (ko) 사용자 단말의 저장 매체를 위한 미디어 스캐닝 방법 및 미디어 스캐닝 장치
US11586723B2 (en) Information processing apparatus, control method for information processing apparatus, and storage medium
JP2017157175A (ja) 情報処理装置及びライブラリ管理方法
JP6873772B2 (ja) 情報処理装置、情報処理装置の制御方法及びアプリケーション管理方法
US20150230080A1 (en) Media scanning method and media scanning terminal
US20230133971A1 (en) Access control method, computer-readable recording medium storing access control program, and information processing apparatus
CN117807039A (zh) 一种容器处理方法、装置、设备、介质及程序产品

Legal Events

Date Code Title Description
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right