KR100679687B1 - 객체지향적 컴퓨터 프로그램의 로딩 - Google Patents

Abstract

객체지향적 컴퓨터 프로그램을 실행하는 방법은 클래스의 전체를 반드시 로딩할 필요 없이 동작되는 선택된 메소드들을 실행환경으로 로딩하는 것으로 구성된다. 멀티프로세서 환경에서, 서버(410)는 프로세서 독립 가상프로세서 툴들(482)의 스토어를 보유한다. 개별 툴들은, 원래 클래스 파일의 전체(480)를 전혀 전송할 필요없이, 요구에 의해 통신네트워크(450)를 통하여 개별 클라이언트들(430,440)로 전송될 수 있다. 각 클라이언트는 다운로드된 프로세서 독립 툴을 네이티브 코드로 번역하는 소형의 프로세서 독립 네이티브 번역기(424,425)를 가진다. 본 발명은 장착된 시스템들 특히 이동전화 네트워트같은 무선클라이언트에 응용된다.

객체지향, JVM,

Description

객체지향적 컴퓨터 프로그램의 로딩{LOADING OBJECT-ORIENTED COMPUTER PROGRAMS}

본 발명은 일반적으로 객체지향적 컴퓨터 프로그램을 로딩하는 방법과 객체지향적 컴퓨터 프로그램을 로딩하기 위한 시스템에 관한 것이다. 더욱 구체적으로는, 본 발명은 코드가 클래스 파일들의 형태로 제공되고 각 클래스 파일은 복수의 메소드들을 담고있는 객체지향적 프로그램에 관한 것(여기에 한정되는 것은 아님)이다.

잘 알려진 객체지향적 프로그래밍 언어의 예에는 "자바(Java)"(선 마이크로시스템즈사의 상표이다)가 있다. "자바구현(Java implementation)"은 하나 이상의 클래스 파일로 구성되는 소프트웨어 애플리케이션(application)이 작동되도록 하는 소프트웨어 시스템이다. 이들 클래스 파일들은 선 마이크로시스템즈사에 의해 공개된 임의 버전의 표준 자바 가상 장치 스펙(standard Java Virtual Machine Specification)에 부합해야 한다. 클래스 파일은 특정 클래스를 위해 요구되는 데이터와 프로그램 코드를 정의한다.

약간의 상호작용이 있지만, 자바구현은 개념적으로 2개 부분으로 나뉘어질 수 있다.

· 자바가상장치(Java Virtual Machine, JVM). 이것은 클래스 파일들을 읽어서, 그 안에 있는 명령들을 임의버전의 선 마이크로시스템즈사의 자바 가상 장치 스펙에 부합하는 방식으로 실행한다. 클래스에 있는 일부 명령들은 다른 클래스의 데이터 또는 프로그램 코드를 참조할 수 있다. JVM은 또한 클래스들 상호간의 관계를 조정한다.

·자바 클래스 라이브러리(Java Class Library). 이것은 선 마이크로시스템즈사의 자바 클래스 라이브러리 스펙과 일치하는 방식으로 동작하는 데이터와 프로그램 코드를 갖는 기정의된 클래스들의 집합이다. 이들 라이브러리 클래스들은 예를 들면 C 또는 어셈블러 프로그래밍 언어를 사용함으로써 리얼 클래스 파일들과는 다른 방식으로 구현될 수 있고, 이 경우에 JVM은 그것들의 데이터와 프로그램 코드에 대한 레퍼런스들이 리얼 클래스 파일들로부터 파생된 클래스에 대한 레퍼런스와 같은 방식으로 작동하는 것을 확인해야 한다.

클래스 파일속의 프로그램 코드는 자바 바이트 코드(JBC) 또는 간단히 바이트 코드라고 알려진 명령 포맷으로 되어 있다. 클래스 안의 각 메소드는 자체 바이트 코드 시퀴언스(sequence)을 가진다. 메소드를 위한 바이트 코드는 JBC명령들의 시퀴언스로 구성된다.

바이트 코드를 수행하기 위하여 JVM이 사용하는 방식에는 2가지가 있다.

· 인터프리터. 이 방식에서는, JVM은 인터프리터를 포함하는데, 인터프리터는 각 JBC 명령을 차례로 보고 그것을 디코딩하고 그것에 의해 요구되는 작동을 수행함으로써 바이트 코드를 실행하는 프로그램 코드의 일부이다. 이런 방식은 구현하기에 제일 간단하지만, 인터프리터 프로그램의 많은 단계가 하나의 JBC 명령을 해석하는데 필요하기 때문에 다른 방식보다 느리다는 단점이 있다.

· 컴파일러. 이 방식에서는, 어떤 실행이 시작되기 전에 JVM이 바이트 코드의 JBC명령들을 작동될 CPU에 의해 이해될 수 있는 기계 코드(네이티브 기계 코드) 명령들로 변환한다. 그리고는, 메소드를 위한 프로그램 코드를 실행하기 위하여, 컴파일된 기계 코드가 대신으로 실행된다. JBC명령들에서 기계 코드 명령들로의 초기 컴파일을 하는 것에 시간이 걸린다는 오버헤드(overhead)가 있지만, 이것은 애플리케이션이 시작될 때라기보다는 애플리케이션의 준비 동안에 행해질 수 있다. 일단 컴파일이 수행되면, 메소드의 프로그램 코드는 C와 같은 다른 종래의 컴파일된 언어에 상당하는 속도로 매우 빨리 동작한다. 컴파일러 방식의 특별한 케이스로는 저스트-인-타임(just-in-time) 컴파일러(JIT)가 있는데, 여기서는 클래스를 위한 바이트 코드는 처음 사용되기 직전에 컴파일된다.

어떤 JVM는 두 방식의 조합을 쓰는데, 여기서는 여러 번 실행되는 프로그램 코드만이 컴파일방식에 의하고, 나머지는 인터프리터방식에 의한다.

링킹이라는 것은 어떤 클래스 C1에서 다른 클래스 C2(혹은 C2의 데이터 또는 메소드)로의 레퍼런스를 해결하는 프로세스이다. C2가 아직 로딩되지 않았다면, 그것은 로딩되고, 컴파일러방식를 사용한다면 컴파일되고, 그 자체는 링크된다. 그리고는, C1에서 C2(C2안의 데이터 또는 메소드의 일부 아이템)로의 레퍼런스는 수정되어, C2안에서 참조되고 있는 것으로의 직접적 포인터가 있도록 한다.

선 마이크로시스템즈의 자바 가상 기계 스펙에서는 다음의 링킹방식이 가능하다.

· 정적 링킹(Static linking) : 애플리케이션이 준비될 때 애플리케이션의 모든 클래스들의 로딩과 링킹이 수행된다. 이 방식은 애플리케이션이 디바이스에 영구적으로 설치되어 있을 때 전형적으로 사용된다.

· 동적 로드 타임 링킹(Dynamic load time linking) : C2(C2내의 어떤 데이터 아이템 또는 메소드)를 참조하는 다른 클래스가 최초로 로딩될 때 클래스 C2가 로딩된다.

· 동적 지연 바인딩(Dynamic late binding) : C2(C2내의 어떤 데이터 아이템 또는 메소드)를 참조하는 JBC명령(또는 이것의 컴파일된 동등한 것)이 최초로 실행될 때 클래스 C2는 로딩된다.

작동 중에, 특정 클래스의 특정 메소드가 호출될 때, 필요한 특정 클래스는 JVM에 이미 있을 수도 있고 없을 수도 있다. 만약 필요한 클래스가 없다면, 그 클래스를 위한 클래스 파일이 먼저 JVM외부(예를 들면 디스크 또는 네트워크)로부터 로딩되고 링크되어, JVM 내부로 초기화되는 것이 필요하다. 그 후, 필요한 메소드는 클래스를 위한 메소드의 리스트를 검색함으로써 발견될 수 있다. 일단 필요한 메소드가 발견되면, 그 메소드의 자바 바이트 코드는 실행되고, 리턴 명령이 출현되면 그 메소드는 끝나고 제어권은 그 메소드의 호출기로 돌아온다. 메소드 호출은 그 메소드에서 잡히지 않는 예외가 던져진 경우에는 중단될 수 있다.

도 1은 JVM이 JIT 컴파일러를 이용하는 전형적 종래기술의 구현을 도시한다. JIT 컴파일러(120)은 클래스 바이트 코드(110)을 사용되기 직전에 취하여 그것을 특정 프로세서에서의 실행에 필요한 네이티브 코드(130)으로 번역한다. 클래스의 나머지(140) (또는 어쩌면 클래스의 전부)은, 네이티브 코드(130)가 작동 중 참조할 필요가 있는 경우를 대비하여 메모리에 이용가능한 상태로 남아있다.

도 3은 멀티프로세서 환경에서 전형적 종래기술인 JVM 구현을 도시하고 있다. 서버(210)는 클라이언트 프로세서(230, 240)가 필요로 할 수 있는 여러 가지 클래스들의 바이트 코드를 유지하기 위한 클래스 스토어(220)을 보유한다. 복수의 개별 메소드들(212)을 내부에 포함하는 전형적 자바 클래스(201)가 클래스 스토어(220)내에 도시되어 있다.

서버(210)는 필요하다면 일반적으로 250으로 표시된 통신 네트워크를 통하여 클래스 파일(201)을 클라이언트(230, 240)에게 공급한다. 이 예에서 프로세서(230, 240)은 서로 다른 타입, 즉 각각 클라이언트 타입 1과 클라이언트 타입 2이다. 각 클라이언트는 각기 자체 JIT(231, 241)을 보유하고, 자체 JIT를 활성화하여 수신된 클래스 파일(201)을 각 자체 버전인 네이티브 코드(233, 243)로 컴파일하고 그것을 각 자체 네이티브 코드 스토어(232, 242)에 저장하도록 한다. 또한, 도 1을 참조하여 위에서 설명한 것처럼, 클래스 파일의 나머지(또는 어쩌면 전체 클래스 파일)는 일반적으로 234, 244으로 표시된 것처럼 로컬 메모리에 잔류하여, 로컬 프로세서에서 동작하는 동안 네이티브 코드(233, 243)가 참조할 필요가 있는 경우를 대비한다.

다른 종래기술 구성(도시되지 않음)에서는, 클라이언트 JIT(231,241)은 서버(210)에 있을 수 있는데, 네이티브 코드로의 변환은 클라이언트(230, 240)에서가 아닌 서버에서 행해진다.

종래기술 구성에는 몇가지 단점이 있다. 첫째, 각 경우에서, 각 클라이언트에는 큰 실행환경이 필요하다. 또한, 자바 클래스 파일(201) 또는 네이티브 버전(233, 243)은 클래스 파일의 나머지들(234, 244)와 함께 통신네트워크(250)을 통하여 전송될 필요가 있다. 이들 각각의 방식은 실제에서는 만족스럽지 못하다. 특히 이동 셀룰러 전화 네트워크와 같은 무선 클라이언트 네트워크와 관련해서는 클래스 파일들이 일반적으로 크기 때문에 더욱 그러하다.

본 발명의 제1형태에 따르면, 복수의 메소드를 각기 포함하는 클래스들의 형식으로 제공되는 코드를 포함하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법으로서, (a) 실행을 위해 클래스들 중 하나에서 메소드들 중 하나를 선택하는 단계와; (b) 선택된 클래스의 전부를 실행환경 속으로 반드시 로딩할 필요 없이, 선택된 메소드를 실행환경으로 로딩하는 단계;를 구비하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법이 제공된다.

이 방법발명은 JVM의 모든 동적 기능을 구현하지만, 종래의 방식과 비교해볼 때 실질적으로 줄어든 풋프린트(footprint)를 갖는다.

바람직한 형태에서, 본 발명은 통신네트워크를 통한 바인딩/링킹, 로딩, 컴파일, 및 전송을 미세한 세분성(granularity)으로 제어가능하다. 더욱 구체적으로는, 세분성은 종래 객체지향적 시스템에서처럼 클래스 레벨이라기 보다는 메소드/툴(tool) 레벨이다. 본 발명은 JVM 환경에 적용가능하다(이에 한정되는 것은 아님). 본 발명은 모든 JVM 링킹 방식, 즉 정적 링킹, 동적 로드 타임 링킹, 그리고 동적 지연 바인딩을 대비한 것이다. 본 발명의 바람직한 실시예의 특정의 적용분야는 무선통신(무선클라이언트 네트워크), 더 구체적으로는 이동 셀룰러 전화 네트워크를 포함한다(이에 한정되는 것은 아님). 또한 본 발명은 다른 장착형 디바이스, 양호하게는 (제한없이) 핸드 헬드 컴퓨터(hand-held computer), 게임콘솔, 카메라같은 네트워크형 디바이스, 또는 또다른 타입의 네트워크형 또는 네트워크형 가능 디바이스에 적용가능하다. 한 실시예에서 본 시스템은 무선네트워크로 구성되거나 무선네트워크를 포함할 수 있고, 한편 다른 실시예에서는 개인 또는 공용의 고정형 네트워크 또는 인터넷을 포함할 수도 있다. 클라이언트 디바이스들이 무선통신을 이용할 수 없는 경우, 필요에 따라 (예를 들면 표준모뎀 또는 ISDN 링크를 통하여) 디바이스들이 인터넷에 연결되도록 준비될 수 있다. 이런 방식으로, 본 발명은 예를 들면 카메라, 텔레비전, 세척기계, 차량 또는 실제로 생각할 수 있는 임의의 다른 종류의 컴퓨터 작동 디바이스를 포함하는 광범위의 장착형 디바이스에 적용가능하다.

본 발명의 특징은, 본 발명이 무선 클라이언트 네트워크에 적용될 때, (메소드/툴의) 각 개별 전송 시간이, 전체 클래스 파일이 다운로드되어야 하는 종래의 시스템에서보다 훨씬 단축된다는 것이다. 이것은 네트워크 제공자가 긴 기간동안 네트워크의 가상회로를 오픈할 필요가 없다는 것을 뜻한다. 필요하다면 각 작은 메소드/툴은 다른 루트를 통하여 전송될 수 있다. 게다가, 작은 독립된 데이터 조각의 전송은 낮은 중복과 에러보정이 필요하다는 것을 의미한다. 그래서 네트워크상에서의 부하는 단순히 데이터 전송속도을 고려함으로써 기대되는 것보다 훨씬 줄어들 수 있다.

바람직한 형태에서, 본 발명은 수행 전에 (해석(interpret)되기 보다는) 컴파일되어야 하는 객체지향적 컴퓨터 프로그램의 사용에 특히 적용될 수 있다. 본 발명이 분산 컴퓨터 시스템과 관련하여 사용되면, 각기 메소드들은 네트워크를 통하여 클라이언트 디바이스에 보내지기 전 또는 후에 컴파일될 수 있다.

양호하게는, 본 발명은 클래스를 가상프로세서의 명령집합을 사용하는 복수의 가상 프로세서 툴들로 번역하는 예비단계를 포함한다. 그리고, 실행을 위해 메소드들 중 하나를 선택하는 단계는 가상 프로세서 툴 중 하나를 선택하는 단계를 포함한다. 네트워크형 시스템과 관련되어 사용되면, 가상 프로세서 툴들이 각기 네트워크를 통하여 클라이언트 디바이스에 전송되거나 또는 개별 가상 프로세서 툴이 먼저 컴파일된 다음에 네이티브 컴파일된 코드(the native compiled code)가 네트워크를 통하여 전송될 수 있다.

본 발명은 상기 서술된 방법을 수행하기 위해 구성되는 컴퓨터 시스템에까지 더욱 확장된다.

본 발명은 복수의 메소드들을 각기 포함하는 클래스들의 형식으로 제공되는 코드를 포함하는 객체지향적 컴퓨터 프로그램을 로딩하고/하거나 실행하는 컴퓨터 시스템에까지 더욱 확장되는데, 이 시스템은 실행환경을 규정하고, 실행을 위하여 클래스들 중 하나에서 메소드들 중 하나를 선택하고, 선택된 클래스의 전체를 실행환경으로 반드시 로딩할 필요 없이 선택된 메소드를 실행환경으로 로딩하도록 작동가능하다.

본 발명의 또다른 형태에 따르면, 복수의 메소드들을 각기 포함하는 클래스들의 형태로 제공되는 코드를 포함하는 객체지향적 컴퓨터 프로그램을 실행하기 위하여 각기 각각의 실행환경을 가지는 복수의 클라이언트 디바이스들과 통신수단을 통하여 통신하는 서버를 포함하는 분산 컴퓨터 시스템으로서, (a) 클라이언트 디바이스 중 하나에서의 실행을 위해, 클래스들 중 하나에서 메소드들 중 하나를 선택하기 위한 수단과; (b) 선택된 클래스 전체를 상기 실행환경으로 반드시 로딩할 필요 없이, 상기 클라이언트 디바이스안의 실행환경으로 선택된 메소드를 로딩하는 수단;을 구비한 분산 컴퓨터 시스템이 제공된다.

본 발명은 객체지향적 컴퓨터 프로그램들을 로딩하는 방법과 장치 뿐만 아니라 상기 프로그램들을 컴파일링하고 상기 프로그램들을 바인딩하고 상기 프로그램들을 실행하고 통신 네트워크를 통하여 상기 프로그램들을 전송하기 위한 방법과 장치까지 확장된다.

마지막으로, 본 발명은, 기록매체 상에서 수행되는지 여부와 상관없이, 서술된 방법들 중 임의의 것을 구현하기 위한 컴퓨터 프로그램까지도 확장된다. 또한 본 발명은 서술된 방법을 수행하기 위한 컴퓨터 프로그램을 나타내는 데이터 스트림까지 확장된다.

발명의 상세한 설명과 청구의 범위에서 사용된 단어 "코드"는 그 자체로 프로그램의 일부인 데이터를 포함한다. 따라서, 제한은 없지만 "코드" 표현은 상수들, 변수 이름들과 타입들, 플래그들, 포인터들, 객체 이름들 등과 같은 것을 포함한다.

도 1은 JVM안에서의 통상적인 JIT 컴파일러의 작동을 도시한다.

도 2는 본 발명의 바람직한 실시예의 2단계 번역 프로세스를 도시한다.

도 3은 전형적 종래기술인 클라이언트/서버 시스템을 도시한다.

도 4는 클라이언트/서버 시스템내에서의 본 발명의 바람직한 실시예의 작동을 도시한다.

도 4a는 도 4에서 보여준 실시예의 변형을 도시한다.

도 5는 무선네트워크 내에서 본 발명의 작동을 도시한다.

도 6은 본 발명의 바람직한 실시예에 따라서 바이트 코드에서 중간 가상 프로세서 코드로의 번역의 한 형태를 도시한다.

본 발명은 여러 가지 방식으로 사용될 수 있으며, 예를 통해서 첨부된 도면을 참조하여 특정 실시예를 설명하겠다.

상기 설명된 것처럼 도 1은 JVM내에서의 JIT 컴파일러가 특정 프로세서 상에서 작동하기 위하여 프로세서 독립(processor-independent) 바이트 코드에서 프로세서 종속(processor-dependent) 네이티브 코드로 번역되는 방법을 보여준다. 본 발명에서, 바이트 코드에서 네이티브 코드로의 변환은 별도의 2단계에서 이루어진다.

1. 클래스 파일에서 중간 프로세서 독립 형태로의 변환. 이것은 가상프로세서 코드 또는 VP 코드라고 불리운다. 이 변환기 자체는 바람직한 실시예에서 "j 코드 번역기"로 알려져 있다.

2. 중간 VP 형태에서 네이티브 기계 코드로의 변환. 여기 이 변환기는 "네이티브 번역기"로 알려질 것이다.

도 2는 클래스 바이트 코드에서 네이티브 코드로의 번역을 좀 더 자세하게 도시한다. 클래스 검증기(211)은 먼저 클래스 바이트 코드(210)를 체크한다. 이것은 개별 바이트 자체를 체크할 뿐 아니라, 외부와 내부 레퍼런스의 유효성을 체크한다. 클래스 검증기는 필요하다면 외부 레퍼런스를 체크하기 위하여 부가적인 클래스들을 로딩한다. 일단 코드가 체크되면, j코드 번역기(212)로 전달되고, j코드 번역기는 하술하는 것과 같이 코드를 VP 코드(213)으로 변환시킨다. 그 후 VP 코드(213)은 네이티브 번역기(214)에 의해 네이티브 코드(230)으로 변환된다.

클래스 검증기(211), j코드 번역기(212), 및 VP 코드(213)는 모두 프로세서 독립이라는 것을 파악하는 것이 중요하다. 프로세서 특정(processor-specific)인 것은 네이티브 번역기(214)와 최종 네이티브 코드(230)뿐이다.

번역 프로세스 동안에 다루어지는 객체들의 개략적 표현이 도 2의 오른편에 도시되어 있다. 이 프로세스는 복수의 개별 메소드들(202)로 구성된 자바 클래스 파일(201) 형태의 클래스 바이트 코드와 함께 시작한다. j코드 번역기는 클래스 파일을 복수의 개별 가상 프로세서 툴(203)로 번역한다. 동작되는 애플리케이션에 따라서, 필요한 이들 가상 프로세서 툴들(203)이 선택되고, 이들 선택된 툴들은(이들 툴들만) 네이티브 번역기에 의하여 개별 네이티브 메소드(204)로 번역된다. 원래의 클래스 파일(201) 전부가 반드시 네이티브 번역기(214)를 통하여 패스될 필요가 없다는 것을 파악하는 것은 중요하다. 즉, 애플리케이션에 의해 실제 필요한 가상 프로세서 툴(203)만이 번역되고 궁극적으로 클라이언트 상에서 작동하기 위하여 저장된다.

도 4는 이종 멀티프로세서 환경에서의 바람직한 실시예의 사용을 개략적으로 도시하고 있다. 이것은 도 3에 도시된 대응 종래기술의 방식과 비교될 수 있다.

도 4에서, 서버(410)은 통신네트워크(450)을 통하여 (다른 프로세서를 가지는) 두 클라이언트(430, 440)에게 서비스를 제공하고 있다. 모든 프로세서 독립 계산(processor-independent calculation)은 서버에서 수행된다. 특히, 서버는 클래스 스토어(420), 클래스 검증기(421), j코드번역기(422), 및 VP스토어(423)을 보유한다. 복수의 메소드들(481)로 구성되는 초기 자바 클래스 파일(480)은 상기에서 설명된 2단계의 프로세스를 통하여 VP스토어(423)에 저장되는 복수의 VP툴(482)로 번역된다. VP (프로세서 독립) 툴은 필요하면 네트워크(450)을 통하여 개별 클라이언트에서 이용가능하다. 그 후 VP 툴은 개별 클라이언트 번역기(424,425)에 의해 그들 각각의 프로세서에 가장 적절한 네이티브 메소드(483,484)로 번역된다. 이들 네이티브 메소드들은 각각의 네이티브 코드 스토어(432, 442)에 저장된다.

도 4에 도시된 바와 같이, 서버상에서 VP의 사용은 클래스 파일의 검증과 컴파일의 첫째 단계(VP 코드로의 전환)가 서버상에서 단 한번만 실행되도록 한다. 그리하여, (프로세서 타입에 따라 다른) 네이티브 번역만이 실행 전에 클라이언트 디바이스에 의해 수행될 필요가 있다. 이러한 구성은, 서버가 업데이트된 클래스를 이용하기를 원하는 특정 클라이언트에 대해 자세히 알 필요없이, 서버에서 업데이트된 클래스를 공급하는 것을 용이하게 한다. 업데이트된 클래스는 클래스 바이트 코드에서 한번 수정되고, 그 후 VP로 한번 번역될 필요가 있다. VP는 필요에 따라서 클라이언트 디바이스로 전송되고, 네이티브 코드로의 최종번역은 최종 사용자에게 완전히 투과적인 방법으로 클라이언트에서 수행된다. 또한, 새로운 타입의 클라이언트가 다른 네이티브 코드를 필요로 하는 시장에 출시되는 경우에, 서버 또는 VP 코드에 대한 수정은 필요없다. 클라이언트 제조업자는 단순히 클라이언트에게 적당한 네이티브 번역기를 제공하고, 그 디바이스는 서버에서의 어떤 수동의 조정없이 작동할 것이다.

설명된 방식에서, 네트워크를 통하여 자바클래스 파일(480) 또는 개별 메소드들(481) 전체를 다운로드할 필요가 없다. 실제로 개별 클라이언트 애플리케이션에 의해 요구되는 VP 툴만이 네트워크를 통하여 전송될 필요가 있다. 필요한 VP툴은 요구에 응하여 (예를 들면 클라이언트에서 서버로 전송되는 컨트롤 신호에 의하여) 다운로드되거나, 또는 필요하다는 서버의 결정에 의해 전송될 수 있다. 예를 들면 한 실시예에서, 서버는 클라이언트 상에서 작동하는 애플리케이션 프로그램을 업데이트하기 위하여 네트워크를 통하여 업데이트된 VP 툴들을 전송할 수 있다. 이것은 최종 사용자에게 완전히 투과적인 방법으로 실시간으로 행해진다. 호환적으로 또는 부가적으로, 전송된 개별 VP툴들은 "애스-인(add-ins)", 즉 사용자가 클라이언트상에서 작동하는 애플리케이션 프로그램에 추가하기를 원하는 부가적 기능을 의미할 수 있다. 특정의 용이한 방식에 있어서, 사용자가 클라이언트쪽에서 사용할 수 없는 코드의 애플리케이션 프로그램에서의 기능을 사용하려 할 때, 클라이언트는 필요한 VP툴이 다운로드되어야 한다고 요구하는 신호를 자동적으로 서버로 보낸다. 서버는 요구된 VP툴을 전송하고, 상기 VP툴은 로컬 네이티브 번역기(424, 425)에 의해 네이티브 형식으로 번역된다.

도 4a는 서버상에 개별 네이티브 번역기가 서버에 있는 다른 실시예를 도시한다. 도 4a에서 레퍼런스 숫자는 도 4에서 쓰여진 것과 같은 의미를 가진다.

이 실시예의 한 버전에서, 각 클라이언트 프로세서를 위한 네이티브 메소드의 총 집합은 각 네이티브 코드 스토어(432′, 442′)내에서 서버 상에 저장된다. 어떤 메소드가 각 클라이언트에게 필요한지 반드시 먼저 결정될 수가 있는 것은 아니기 때문에, 네이티브 메소드(483, 484)의 포괄적인 선택을 제공하기 위하여 VP툴(482) 전체가 각 네이티브 번역기(424, 425)를 통과하는 것이 바람직하다. 특정의 새롭거나 업데이트된 메소드가 클라이언트에 의해 요구되거나 서버에 의해 보내질 필요가 있으면, 적절한 네이티브 메소드는 통신네트워크(450)을 통해 보내진다. 종전처럼 전체 클래스 또는 원래의 클래스로부터 발생되는 모든 네이티브 메소드가 아닌 개별 메소드만이 보내어진다.

그러나 또다른 방법에서, 서버는 가능한 각 클라이언트 프로세서를 위하여 미리 번역된 메소드들의 완전한 집합을 보유할 필요가 없다. 대신 특정 VP툴이 필요하면 그것은 즉시 적당한 네이티브 번역기(424, 425)에 의해 번역되고 클라이언트에게 즉시 네이티브 메소드가 전송된다.

도 5에 도시된 것은 이동 전화 네트워크의 한 특정 구현이다. 각 네트워크를 사용하는 개별 이동 전화(530, 550)은 각각의 네이티브 번역기(524, 535)와 네이티브 코드 스토어(532, 542)를 구비한다. 전화의 기능을 업그레이드할 필요가 있으면, 업데이트된 VP 코드가 중앙 서버(520)상의 VP스토어(523)으로부터 제공된다. 업데이트된 VP 코드는 지상기지의 통신네트워크를 통하여 무선송신기(512)로 보내진다. 그 후 코드는 패킷화되어 무선링크(513)을 통하여 개별 전화로 보내진다. 수신때 VP 코드는 자동적으로 네이티브로 번역되어 네이티브 코드 스토어에 저장된다. 전체 프로세스는 전화사용자에게 투과적일 수 있다. 또한, 업데이트된 코드는 전화사용자로부터의 특정 요구가 있을 때 무선링크(513)을 통해 보내질 수 있다.

이 방식에서의 이동 전화 네트워크(또는 다른 타입의 무선 클라이언트 네트워크)의 구현은 클라이언트가 전체 클래스(예를 들면 약 10k 바이트)을 다운로드받아야 할 필요없이 개별 메소드(예를 들면 각기 약 100 바이트)를 다운로드받도록 한다. 가상 회로가 큰 파일이 전송되는 긴 시간동안 오픈되어 있을 필요가 없기 때문에, 이런 방식으로 개별 메소드를 전송하는 것은 무선 네트워크 제공자를 위하여 큰 장점을 가진다. 각 작은 개별 메소드는 다른 루트로 전송될 수 있다. 게다가, 작은 독립된 조각의 전송은 중복과 에러보정의 기술의 필요를 감소시키고, 따라서 미가공된 데이터 전송 속도의 비교에 의해 단순히 기대되는 것 이상으로 네트워크의 용량을 높인다.

완벽을 위하여, 클래스 파일이 VP로 변환되고 VP툴이 네이티브로 변환되는 바람직한 방법을 설명하겠다. 이것은 단순히 예시적인 것이고 본 발명은 처음 바이트 코드에서 VP로 그 후 VP에서 네이티브로의 두 단계 번역이 있는 실시예에 한정되지 않는다는 것이 이해되어야 한다.

도 2로 돌아가서, 클래스 바이트 코드(210)에서 네이티브 코드(230)로의 바람직한 2단계 번역에 대해 더욱 상술하겠다. 상기에서 서술한 바와 같이 클래스 검증기(211)은 유효성을 위해 클래스 바이트 코드를 체크한다. 일부 실시예에서는 클래스 검증기는 j코드 번역기에 통합될 수 있다. 이 경우 클래스 바이트 코드(210)은 화살표(240)에 의해 도시된 바와 같이 바로 j코드 번역기로 바로 패스된다.

JVM 및 이것이 구현하는 바이트 코드 명령들은 스택 기반인데, 이것은 마지막에 들어간 아이템이 먼저 나오는 스택에 오퍼랜드들(숫자, 개체로의 포인터)이 저장됨을 의미한다. 바이트 코드 명령은 전형적으로 스택으로부터 하나 이상의 오퍼랜드를 제거하고, 어떤 작동을 수행하고, 결과 오퍼랜드를 (있다면) 스택으로 집어넣는다. 반면에, VP는 VP 명령에 의해 직접 어드레스되는 레지스터 집합을 가지는 레지스터 기반이다. 명령은 그 명령에서 특정된 레지스터(들)로부터 오퍼랜드(들)를 취하여 어떤 동작을 수행하고, 결과 오퍼랜드를 (있다면) 그 명령에서 특정된 레지스터에 넣는다. 이 레지스터 기반 구조는 VP가 매우 많은 레지스터를 가져서 VP로 전환하는 어떤 시스템이더라도 얼마나 많이 있는지에 대해 걱정할 필요가 없다는 것을 제외하고는 대부분의 실제 프로세서와 유사하다.

VP 명령은 식(式)에 기초한다. 하나의 명령은 전형적으로 하나 또는 둘의 오퍼랜드를 가지고, 각 오퍼랜드는 상수, 레지스터 또는 식이 될 수 있다. 식은 하나 또는 둘의 오퍼랜드를 가지고, 각 오퍼랜드는 상수, 레지스터 또는 식이 될 수 있다. 이런 방식으로 임의의 복합 명령이 만들어질 수 있다.

이제 클래스의 부분들이 어떻게 변환되는지 상술하겠다. 본 명세서에서 쓰이는 "픽스업(fixup)"은 컴파일러의 출력코드 또는 데이터 안에서의 특정 포인터에 첨부되는 데이터의 작은 아이템으로서, 특정 포인트에서의 코드 또는 데이터가 사용될 수 있기 전에 이것이 임의 방식으로 수정될 필요가 있다는 것을 JVM에게 지시한다. 픽스업은 네이티브명령 또는 데이터 아이템을 바꾸어 네이티브 코드가 다른 클래스나 그 안의 필드 또는 메소드에 대한 직접적 레퍼런스를 얻을 수 있게 하는데 사용된다.

자바 클래스 파일은 다음의 부분으로 구성된다.

· 상수 풀(pool). 이것은 클래스 파일의 다른 부분들의 상수들과 이름들을 저장하고, 이름 대신에 여기 저장되어 있다는 이름에 대한 레퍼런스가 있다.

· 이 클래스, 슈퍼클래스, 어떤 직접적 슈퍼인터페이스의 이름과 같은 정보.

· 각 필드에 대한 정보가 있는 필드의 리스트.

· 각 메소드에 대한 정보가 있는 메소드들의 리스트. 이 정보는 그것의 코드 섹션을 포함한다. 그래서 각 메소드마다 하나씩, 몇 개의 코드 섹션들이 있다.

자바 클래스 파일은 다음과 같은 VP툴로 변환된다.

· 데이터 툴. 이것의 이름에도 불구하고, 이것은 클래스에 의해 사용되는 데이터와는 아무 상관이 없다. 대신에, 이것은 이름, 모든 생성자(constructor)의 파라미터와 타입, 필드, 메소드 그리고 클래스의 API를 구성하는 다른 엔티티들 등을 (이에 한정되는 것은 아님) 포함하는 클래스에 대한 정보를 담고 있다. 이것의 대표적 용도로는 리플렉션(reflection)(즉, 자바 라이브러리 안의 java.lang.reflect에서의 기능)이 있다. 리플렉션은 프로그래머가 생성자, 필드, 메소드와 클래스에 속하는 다른 엔티티를 열거하고 다룰 수 있도록 하는 프로그램 인터페이스이다. 데이터 툴은, 클래스 파일을 사용할 수 없거나 클래스 파일이 이미 번역된 상황에서, 검증하는 코드 번역기에 의해 사용된다. 클래스가 VP로 쓰여진 경우에는 클래스 파일이 없다.

· 클래스 툴. 이것은 (할당하기 위한 객체의 크기, 있다면 클래스의 정적 데이터의 크기, 슈퍼클래스, 슈퍼인터페이스를 포함하는) JVM에 의해 사용되는 하우스키핑 정보, 및 비정적 메소드들의 일부 또는 전부에 대한 코드(코드를 포함하지 않을 수도 있음)를 포함한다.

· 0개 이상의 메소드 툴들. 클래스 툴안에 없는 메소드들은 그들의 자체 개별 툴들을 가진다. 메소드를 자체 툴안에 둘 것인지 여부에 대한 결정은 메소드의 크기와 같은 다수의 인자(factor)에 기초한다.

· 픽스업 툴(fixup tool). 픽스업 툴은 전형적으로 특정 필드의 객체내의 오프셋을 결정하기 위해 사용되는 상수 픽스업 값을 리턴시킨다. 이 툴은 오프셋을 제공하기 위한 픽스업 타임에 호출되고, 바인더/링커는 이 오프셋을 이것을 사용하기 원하는 코드 속으로 패치시킨다. 따라서, 이것은 바이트 코드 내에서 "필드 구하기(get a field)" 및 "필드 두기(put a field)"를 구현하기 위해 사용된다.

더욱 일반적으로는, 픽스업 툴은 픽스업들을 위해 사용된 데이터를 리턴시킨다. 이것은 단지 컴파일 타임이 아닌 픽스업 타임에만 결정될 수 있다. 데이터는 클래스 인스턴스의 크기와 필드의 클래스 인스턴스 내의 오프셋을 포함할 수 있다(이에 한정되는 것은 아님).

자바 애플리케이션이 어떤 기능(주로 리플렉트)를 사용하지 않는다고 알려지면 데이터툴은 버려질 수 있다. 그리고 자바 애플리케이션이 동적으로 자바클래스들을 로딩하지 않는 디바이스에 장착되면 픽스업 툴은 버려질 수 있다.

j코드 번역기는 스택상의 각 아이템을 위해 VP 레지스터를 사용한다.

VP 코드는 바이트 코드 내으로부터의 다른 클래스, 메소드 또는 필드를 억세스하기 위한 클래스 파일의 메카니즘을 직접적으로 구현하지 않는다. 바이트 코드에는, 이에 한정되지는 않지만, (여기 또는 다른 클래스에 있는) 메소드를 호출하고, (여기 또는 다른 클래스에 있는) 필드의 콘텐츠를 구하고, 스택에 값을 넣고, 스택에서 값을 빼고, 필드의 콘텐츠를 세팅하기 위한 명령어들이 있다. j코드 번역기는 이들을 다음 중 하나를 할 수 있는 VP 명령어들로 변환시킨다.(이것은 완벽한 리스트는 아니다.)

· 클래스안의 비정적 메소드(객체 포인터가 패스되어야 하는 것)을 호출하기. VP는 자바 클래스들을 구현하기 위해 사용되는 메소드들을 갖는 클래스의 개념을 가진다. 이런 메소드들은 가상적으로(호출되는 실제 메소드는 포인터가 패스되는 객체의 클래스를 따른다) 또는 비가상적으로(호출되는 메소드는 그 호출안에서 특정된 클래스안에 있다) 호출될 수 있다.

· 서브루틴을 호출하기. 이것은 정적 메소드(즉, 객체포인터가 패스될 필요가 없는 것)와 일부의 경우 비정적 메소드의 바이트 코드의 호출을 구현하기 위해 사용된다.

· 픽스업 툴로부터 상수 픽스업의 값을 구하기.

클래스 파일안의 상수 풀은 다음과 같이 변환된다.

· 상수(정수 또는 부동소수점수)을 담고 있는 상수 풀 엔트리는 그 상수를 참조하는 JBC 명령의 컴파일된 버전으로 합쳐진다.

· JBC 명령어가 직접 사용하는 문자열 데이터를 담고 있는 상수 풀 엔트리는 컴파일러의 출력코드에 첨부되는 데이터속으로 복사된다.

· 문자열 데이터를 담고 있는 다른 상수 풀은 직접적으로 사용되지 않지만, 하기 상수 풀 타입 또는 클래스 파일의 다른 부분에 의해 참조될 때 사용된다.

· 클래스 C를 참조하는 상수 풀 엔트리는 클래스 C(또는 클래스를 위한 JVM의 내부이름)를 참조하는 픽스업이 컴파일러의 출력 코드/데이터에 첨부되도록 하여, C를 참조하기 위해 이 상수 풀 엔트리를 이용하는 JBC명령이 픽스업을 적용한 후 클래스 C의 코드와 데이터로 억세스하는 네이티브 코드 시퀴언스로 컴파일된다.

· 클래스 C 안의 필드 F를 참조하는 상수 풀 엔트리는 C안의 F를 참조하는 픽스업(또는 C안의 F를 위한 JVM의 내부 이름)이 컴파일의 출력 코드/데이터에 첨부되도록 하여, F를 참조하기 위해 이 상수 풀 엔트리를 사용하는 JBC명령이 픽스업을 적용한 후 필드 F로 억세스하는 네이티브 코드 시퀴언스로 컴파일된다.

· 클래스 C 안의 메소드 M을 참조하는 상수 풀 엔트리는 C안의 M을 참조하는 픽스업(또는 C안의 M을 위한 JVM의 내부 이름)이 컴파일의 출력 코드/데이터에 첨부되도록 하여, M을 참조하기 위해 이 상수 풀 엔트리를 사용하는 JBC명령이 픽스업을 적용한 후 메소드 M으로 억세스하는 네이티브 코드 시퀴언스로 컴파일된다.

· 필드 또는 메소드의 이름과 타입을 부여하는 상수 풀 엔트리는 직접적으로 사용되지는 않지만, 다른 상수 풀 엔트리 타입 또는 클래스 파일의 다른 부분에 의해 참조될 때 사용된다.

클래스 파일안의 코드섹션은 다음과 같이 변환된다.

· 순전히 숫자 계산만 하는 코드(여기서 외부메소드에 대한 레퍼런스는 없다)는 바이트 코드에서 VP안의 대응되는 툴로 바로 번역된다.

· 바이트 코드(600)이 필드에 대한 레퍼런스(610)을 가지고 있는 도 6에서 도시된 바와 같이, 그것은 픽스업 타임에 호출(611)에 의해 픽스업 툴로 변환된다. 픽스업 툴로의 호출은 필드의 위치를 참조하는 값을 리턴시킨다. 그래서 명령이 동작되는 때 이것은 정확한 오프셋을 갖기 위해 패치된다.

· 정적 메소드(620)은 대응되는 VP 툴로 변환되지만, 필스업 코드(621)의 추가가 있다.

· 비정적 메소드(630)은 메소드 호출을 위한 픽스업(즉 메소드 이름에 대한 레퍼런스)으로 더해진다. 이것은 결국 최종 네이티브 코드에서 원자(atom)가 된다.

호출하는 규칙은 바이트 코드와 VP에서 다소 다르다. 자바 바이트 코드와 같은 종래의 바이트 코드에서는, 서브루틴에 패스되는 파라미터들은 스택에 위치하고, 호출되는 메소드에 대한 참조가 뒤따른다. 메소드를 호출하기 위하여 스택으로부터 메소드 레퍼런스를 취하고, 그 레퍼런스를 해결하고, 스택으로부터 파라미터를 갖는 새로운 메소드를 실행하기 시작하는 바이트 코드 명령이 실행된다. 리턴 명령이 실행될 때 제어권은 원래의 메소드로 리턴된다. 이것은 수신지 메소드에 대해 포인트 하기 위해 픽스업되어진 (이 픽스업은 정적 또는 동적으로 바인딩된다) gos(goto subroutine)명령을 수행하기 전에 모든 파라미터를 VP 레지스터들로 로딩하는 VP로 변환된다. 실행은 'ret'명령이 실행될 때 서브루틴으로 패스되고 리턴한다.

파일의 다른 부분들은 다음과 같이 변환된다.

· 클래스의 이름은 컴파일러에 의해 출력된 코드와 데이터를 참조하기 위해 JVM에 의해 사용되는 이름을 결정한다.

· 슈퍼클래스의 이름은 컴파일러에 의해 출력된 코드와 데이터안의 슈퍼클래스에 대한 임의의 레퍼런스가 된다. 바람직한 구현에서, 출력데이터는 픽스업이 첨부된 포인터를 포함하여, 링크 후 포인터는 슈퍼클래스 코드와 데이터를 포인트한다.

· 각 인터페이스의 이름은 출력 코드와 데이터 내의 인터페이스에 대한 임의의 레퍼런스가 된다. 바람직한 구현에서, 출력 데이터는 픽스업이 첨부된 각 인터페이스를 위한 포인터를 포함하여, 링크 후에 포인터는 인터페이스 코드와 데이터를 포인트한다.

· 각 메소드에 첨부된 디버그 정보(그리고 클래스 파일 안에 저장된 소스 파일이름)는, 혹시 있다면, JVM이 동작하는 환경에 적합한 포맷으로 변환된다. 바람직한 구현에서, 디버그 정보는 시스템의 자바가 아닌 부분을 위해 사용된 같은 포맷으로 변환된다.

최종 VP 클래스는 하나 이상의 명명(命名)된 툴들로 구성되는데, 일반적으로 적어도 데이터 툴, 클래스 툴, 픽스업 툴과 0개 이상의 메소드 툴들을 포함한다. 툴 이름들은 j코드 번역기에 의해 자동적으로 생성되고, 각 이름은 클래스의 이름과 그 클래스의 구현 내에서의 툴의 기능과 연관이 있다.

도 2로 다시 돌아가서, VP 코드를 네이티브 코드로 번역하는 네이티브 번역기에 대해 상술하겠다. 물론, VP 코드는 실제 응용에서 절대로 직접 그 자체로 동작될 수 없다고 이해될 것이다. 즉, 이것은 프로세서 독립 네이티브 번역기에 의해 이것이 실행되는 프로세서를 위한 적절한 네이티브 코드로 변환된다. 네이티브 번역기(214)는 매우 작은 조각의 코드(프로세서에 따라서, 약 150k)이다. 따라서, 이것은 장착형 시스템내의 메모리 안에 쉽게 저장될 수 있다. 번역기(214)는 VP 레지스터를 사용되는 특정 프로세서의 레지스터에 맵핑시킨다. 번역기는 실제 프로세서의 레지스터 구조의 지식을 이용하여, 출력 네이티브 코드안의 각 포인터에서 어떤 VP 레지스터가 실제 프로세서의 레지스터에 맵핑되어야 하는지 그리고 어떤 것이 메모리에 보관되어야 하는지 (어느 것이 억세스하기에 느린지)를 결정한다. 또한, 번역기는 명령들의 기계 종속(machine-dependent) 최적화를 제공한다. 네이티브 코드가 바인딩될 때까지, 이것은 보통 픽스업 코드의 섹션을 포함한다. 바인딩할 때 (혹은 간혹 동작시간에) 픽스업 코드는 적절한 기계 종속 명령들로 교체된다. 예를 들면, 비정적 메소드를 위한 픽스업은 네이티브 코드 안에서 원자(atom)로 변환된다.

j코드 번역기와 네이티브 번역기 둘다는 양호하게는 VP 코드로 쓰여지고 그래서 원하는 플랫폼상에서 작동하도록 번역될 수 있다(자체 네이티브 번역기를 사용하여). 그 초기 VP 코드로부터, 번역기들 둘다의 컴파일된 버전들은 네이티브 코드에 제공될 수 있고, 번역기가 수행되어야 하는 특정프로세서를 위해 최적화될 수 있다. j코드 번역기를 위한 VP 코드를 컴파일하기 위하여, 그 코드는 네이티브 번역기를 통하여 패스된다. 네이티브 번역기를 위한 VP 코드를 컴파일하기 위하여, 그 코드는 자체 네이티브 번역기를 통하여 패스된다. 바람직한 실시예는 JVM을 사용하지만, 전체 발명 개념은 더욱 일반적이고, JVM 또는 자바를 사용하는 것은 결코 중요하지 않다. 그러나, 자바가 사용되면, 설명된 발명은 자바로 숙달된 애플리케이터 프로그래머가 VP 코드를 이해하거나 전혀 알지 못하고도 자신들이 선호하는 언어로 프로그램을 개발할 수 있도록 한다.

상기 내용 중에 포함되어 있음.

Claims (41)

1. 각각 복수의 메소드를 포함하는 클래스들의 형식으로 제공되는 코드를 포함하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법으로서,

   (a) 실행을 위해 상기 클래스들 중 하나에서 메소드들 중 하나를 선택하는 단계와;

   (b) 상기 선택된 클래스의 전부를 실행환경 속으로 반드시 로딩할 필요 없이, 선택된 메소드를 실행환경으로 로딩하는 단계를 구비하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법.
2. 제1항에 있어서, 선택된 클래스의 모든 메소드들을 실행환경으로 반드시 로딩할 필요 없이, 상기 선택된 메소드가 로딩되는 것을 특징으로 하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법.
3. 제1항에 있어서, 선택된 메소드 이외에 선택된 클래스의 임의의 메소드를 실행환경으로 반드시 로딩할 필요 없이, 상기 선택된 메소드가 로딩되는 것을 특징으로 하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법.
4. 제1항에 있어서, 선택된 클래스의 모든 메소드들을 반드시 컴파일할 필요 없이, 상기 선택된 메소드를 컴파일하는 단계를 포함하는 것을 특징으로 하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법.
5. 제1항에 있어서, 선택된 메소드 이외에 선택된 클래스의 임의의 메소드를 반드시 컴파일할 필요 없이, 상기 선택된 메소드를 컴파일하는 단계를 포함하는 것을 특징으로 하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법.
6. 제1항에 있어서, 선택된 클래스의 모든 메소드들을 반드시 전송할 필요 없이, 상기 선택된 메소드를 서버로부터 상기 선택된 메소드가 작동되어지는 클라이언트 디바이스로 통신 네트워크를 통하여 전송하는 단계를 포함하는 것을 특징으로 하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법.
7. 제1항에 있어서, 선택된 메소드 외에 선택된 클래스의 임의의 메소드를 반드시 전송할 필요 없이, 상기 선택된 메소드를 서버로부터 상기 선택된 메소드가 작동되어지는 클라이언트 디바이스로 통신 네트워크를 통하여 전송하는 단계를 포함하는 것을 특징으로 하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법.
8. 제1항에 있어서, 상기 클래스들은 자바 클래스들인 것을 특징으로 하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법.
9. 제1항에 있어서, 상기 클래스들을, 가상 프로세서의 명령 집합을 사용하는 복수의 가상 프로세서 툴들로 번역하는 예비단계를 포함하는 것을 특징으로 하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법.
10. 제1항에 있어서, 상기 실행을 위해 메소드들 중 하나를 선택하는 단계는 가상 프로세서 툴들 중 하나를 선택하는 단계를 포함하는 것을 특징으로 하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법.
11. 제10항에 있어서, 선택된 클래스로부터 번역된 모든 가상 프로세서 툴들을 실행환경으로 반드시 컴파일하고 로딩할 필요 없이, 상기 선택된 가상 프로세서 툴을 컴파일하고 로딩하는 단계를 포함하는 것을 특징으로 하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법.
12. 제10항에 있어서, 선택된 툴 이외에 선택된 클래스로부터 번역된 임의의 가상 프로세서 툴을 실행환경으로 반드시 컴파일하고 로딩할 필요 없이, 상기 선택된 가상 프로세서 툴을 컴파일하고 로딩하는 단계를 포함하는 것을 특징으로 하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법.
13. 제10항에 있어서, 선택된 클래스로부터 번역된 모든 가상프로세서 툴을 반드시 전송할 필요 없이, 상기 선택된 가상 프로세서 툴을 서버로부터 상기 선택된 메소드가 작동되어지는 클라이언트 디바이스로 통신 네트워크를 통하여 전송하는 단계를 포함하는 것을 특징으로 하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법.
14. 제10항에 있어서, 선택된 클래스로부터 번역된 임의의 가상 프로세서 툴을 반드시 전송할 필요 없이, 상기 선택된 가상 프로세서 툴을 서버로부터 상기 선택된 메소드가 작동되어지는 클라이언트 디바이스로 통신 네트워크를 통하여 전송하는 단계를 포함하는 것을 특징으로 하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법.
15. 제13항에 있어서, 통신 네트워크를 통한 전송 전에 상기 선택된 가상 프로세서 툴을 네이티브 코드로 컴파일하는 단계를 포함하는 것을 특징으로 하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법.
16. 제14항에 있어서, 통신 네트워크를 통한 전송 전에 상기 선택된 가상 프로세서 툴을 네이티브 코드로 컴파일하는 단계를 포함하는 것을 특징으로 하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법.
17. 제13항에 있어서, 통신 네트워크를 통한 전송 후에 클라이언트 디바이스에서 가상 프로세서 툴을 네이티브 코드로 컴파일하는 단계를 포함하는 것을 특징으로 하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법.
18. 제14항에 있어서, 통신 네트워크를 통한 전송 후에 클라이언트 디바이스에서 가상 프로세서 툴을 네이티브 코드로 컴파일하는 단계를 포함하는 것을 특징으로 하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법.
19. 제1항 내지 제18항 중 어느 항 항에 따른 방법을 수행하기 위해 구성되는 컴퓨터 시스템.
20. 각각 복수의 메소드들을 포함하는 클래스들의 형태로 제공된 코드를 포함하는 객체지향적 컴퓨터 프로그램을 로딩하기 위한 컴퓨터 시스템으로서, 상기 시스템은 실행환경을 규정하고, 실행을 위해 상기 클래스들 중 하나에서 메소드들 중 하나를 선택하고, 상기 선택된 클래스의 전부를 실행환경으로 반드시 로딩할 필요 없이 선택된 메소드를 실행환경으로 로딩하도록 동작할 수 있는 컴퓨터 시스템.
21. 각각 복수의 메소드들을 포함하는 클래스들의 형태로 제공되는 코드를 포함하는 객체지향적 컴퓨터 프로그램을 실행하기 위하여 각각 개별적인 실행환경을 가지는 복수의 클라이언트 디바이스들과 통신수단을 통하여 통신하는 서버를 포함하는 분산 컴퓨터 시스템으로서,

    (a) 상기 클라이언트 디바이스 중 하나에서의 실행을 위해, 상기 클래스들 중 하나에서 메소드들 중 하나를 선택하기 위한 수단과;

    (b) 상기 선택된 클래스 전체를 상기 실행환경으로 반드시 로딩할 필요 없이, 상기 클라이언트 디바이스 내의 실행환경으로 상기 선택된 메소드를 로딩하는 수단을 구비한 분산 컴퓨터 시스템.
22. 제21항에 있어서, 상기 선택된 클래스의 모든 메소드들을 반드시 전송할 필요 없이, 상기 선택된 메소드를 서버에서 상기 클라이언트 디바이스로 전송하는 것을 특징으로 하는 분산 컴퓨터 시스템.
23. 제21항에 있어서, 상기 선택된 메소드 이외에 선택된 클래스의 임의의 메소드를 반드시 전송할 필요 없이, 상기 선택된 메소드를 서버에서 상기 클라이언트 디바이스로 전송하는 것을 특징으로 하는 분산 컴퓨터 시스템.
24. 제21항에 있어서, 상기 선택된 메소드는 전송 전에 서버에 의해 컴파일되는 것을 특징으로 하는 분산 컴퓨터 시스템.
25. 제21항에 있어서, 상기 선택된 메소드는 전송 후에 클라이언트 디바이스에 의해 컴파일되는 것을 특징으로 하는 분산 컴퓨터 시스템.
26. 제21항에 있어서, 상기 서버는, 클라이언트가 아웃데이트된 메소드를 사용하고 있다고 판단될 때, 상기 클라이언트 디바이스에 업데이트된 메소드를 전송하도록 구성되는 것을 특징으로 하는 분산 컴퓨터 시스템.
27. 제21항에 있어서, 상기 서버는, 클라이언트 디바이스가 업데이트된 메소드를 요구할 때, 상기 클라이언트 디바이스에 업데이트된 메소드를 전송하도록 구성되는 것을 특징으로 하는 분산 컴퓨터 시스템.
28. 제21항에 있어서, 상기 서버는 요구하는 클라이언트 디바이스에 의해 요구되는 메소드들을 전송하도록 구성되고, 상기 요구하는 클라이언트 디바이스는 수신한 메소드들을 그것의 실행환경으로 동적으로 바인딩하도록 구성되는 것을 특징으로 하는 분산 컴퓨터 시스템.
29. 제21항에 있어서, 상기 서버는 복수의 가상 프로세서 툴들을 저장하고, 상기 툴들은 가상 프로세서의 명령집합을 사용하고 상기 객체지향적 프로그램의 하나 이상의 클래스들의 번역이 되는 것을 특징으로 하는 분산 컴퓨터 시스템.
30. 제29항에 있어서, 상기 실행을 위해 메소드들 중에서 하나를 선택하기 위한 수단은 가상 프로세서 툴들 중에서 하나를 선택하기 위한 수단을 포함하는 것을 특징으로 하는 분산 컴퓨터 시스템.
31. 제30항에 있어서, 상기 서버는, 선택된 클래스로부터 번역된 모든 가상 프로세서 툴들을 반드시 전송할 필요 없이, 상기 선택된 가상 프로세서 툴을 상기 클라이언트 디바이스로 전송하는 것을 특징으로 하는 분산 컴퓨터 시스템.
32. 제30항에 있어서, 상기 서버는, 선택된 툴 이외에 선택된 클래스로부터 번역된 임의의 가상 프로세서 툴을 반드시 전송할 필요 없이, 상기 선택된 가상 프로세서 툴을 상기 클라이언트 디바이스로 전송하는 것을 특징으로 하는 분산 컴퓨터 시스템.
33. 제30항에 있어서, 상기 선택된 가상 프로세서 툴은 전송수단을 통한 전송 전에 네이티브 코드로 번역되는 것을 특징으로 하는 분산 컴퓨터 시스템.
34. 제30항에 있어서, 상기 선택된 가상 프로세서 툴은 전송수단을 통한 전송 후에 클라이언트 디바이스에 의해 네이티브 코드로 번역되는 것을 특징으로 하는 분산 컴퓨터 시스템.
35. 제21항에 있어서, 상기 전송 수단은 무선네트워크로 구성되거나 무선네트워크를 포함하는 것을 특징으로 하는 분산 컴퓨터 시스템.
36. 제35항에 있어서, 상기 클라이언트 디바이스는 이동전화인 것을 특징으로 하는 분산 컴퓨터 시스템.
37. 제35항에 있어서, 상기 클라이언트 디바이스는 핸드 헬드 컴퓨터인 것을 특징으로 하는 분산 컴퓨터 시스템.
38. 제35항에 있어서, 상기 클라이언트 디바이스는 게임 콘솔인 것을 특징으로 하는 분산 컴퓨터 시스템.
39. 삭제
40. 제1항 내지 제18항 중 어느 항에 따른 방법을 수행하기 위한 컴퓨터프로그램을 담고 있는 기록매체.
41. 삭제

Images