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

Abstract

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

Description

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

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

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

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

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

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

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

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

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

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

링킹은 어떤 클래스 C1에서 다른 클래스 C2(혹은 C2의 데이터 또는 메소드)로의 레퍼런스가 주소분해되는 프로세스이다. C2가 아직 로딩되지 않았다면, 그것은 로딩되고, 컴파일러체계를 사용한다면 컴파일되고, 그 자체는 링크된다. 그리고는, C2(C2안의 데이터 또는 메소드의 일부 항목)에 대한 C1안의 레퍼런스는 수정되어, 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)으로 번역한다. 네이티브 코드 (130)이 작동 중 참조할 필요가 있는 경우를 대비하여 클래스의 나머지 (140) (또는 어쩌면 클래스의 전부)은 메모리에 이용가능한 상태로 남아있다.

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

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

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

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

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

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

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

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

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

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

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

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

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

이 방법발명은 종래의 접근과 비교해볼 때 실제적으로 줄어든 풋프린트(footprint)와 함께, JVM의 모든 동적 특성을 제공한다.

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

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

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

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

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

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

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

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

마지막으로, 본 발명은 기록매체상에서 실시되거나 그렇지 않던 간에 서술된 방법들 중 어떤 것이라도 구현하기 위한 컴퓨터 프로그램까지도 확장된다. 또한 본 발명은 서술된 방법을 수행하기 위한 컴퓨터 프로그램을 대표하는 데이터 스트림까지 확장된다.

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

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

상기 설명된 것처럼 도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)과 접속되어 있다. 모든 프로세서 독립 계산은 서버에서 수행된다. 특히, 서버는 클래스 스토어 (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툴이 다운로드되어야 한다고 요구하는 신호를 자동적으로 서버로 보낸다. 서버는 로컬 네이티브 번역기 (424, 425)에 의해 네이티브 형식으로 번역된 요구된 VP툴을 전송하는 반응을 한다.

도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툴로 변환된다.

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

· 클래스 툴. 이것은 (할당하기 위한 객체의 크기, 있다면 클래스의 정적 데이터의 크기, 슈퍼클래스, 슈퍼인터페이스를 포함하는) JVM에 의해 사용되는 정리작업정보, code for none, 비정적 메소드들의 일부 또는 전부를 포함한다.

· 영 이상의 메소드 툴들. 클래스 툴안에 나타나지 않는 메소드들은 그것들만의 자체 개별 툴들을 가진다. 메소드를 자체 툴안에 둘 것인지의 결정은 메소드의 크기같은 다수의 인자에 기초한다.

· 픽스업 툴. 픽스업 툴은 전형적으로 특정 필드의 객체내의 오프셋을 결정하기 위해 사용되는 상수 픽스업 값을 리턴시킨다. 이 툴은 오프셋을 제공하기 위한 픽스업 타임에 호출되고, 바인더/링커는 이 오프셋을 이것을 사용하기 원하는 코드 속으로 패치시킨다.

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

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

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)은 픽스업 코드 (621)이 더해진 대응되는 VP 툴로 변환된다.

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

호출하는 관습은 바이트코드와 VP에서 오히려 다르다. 자바 바이트코드와 같은 종래의 바이트코드에서는, 서브루틴에 패스되는 매개변수들은 스택에 위치하고, 호출되는 메소드에 대한 레퍼런스에 의해 추적된다. 메소드를 호출하기 위하여 스택으로부터 메소드 레퍼런스를 취하고, 그것을 주소분해하고, 스택으로부터 매개변수와 함께 새로운 메소드를 실행하기 시작하는 바이트코드 명령이 실행된다. 리턴 명령이 실행될 때 컨트롤은 원래의 메소드로 리턴된다. 이것은 수신지 메소드에 대해 포인트 하기 위해 픽스업되어진 (이 픽스업은 정적 또는 동적으로 바인딩된다) gos(goto subroutine)명령을 수행하기 전에 모든 매개변수를 VP 레지스터들로 로딩하는 VP로 변환된다. 실행은 'ret'명령이 실행될 때 서브루틴으로 패스되고 리턴한다.

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

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

· 슈퍼클래스의 이름은 컴파일러에 의해 출력된 코드와 데이터안의 슈퍼클래스에 대한 어떤 레퍼런스가 된다. 양호한 구현에서, 출력데이터는 부착된 픽스업과 함께 포인터를 담아서, 링크 후 포인터는 슈퍼클래스 코드와 데이터를 포인트한다.

· 각 인터페이스의 이름은 출력 코드와 데이터 내의 인터페이스에 대한 레퍼런스가 된다. 양호한 구현에서, 출력 데이터는 부착된 픽스업과 함께 각 인터페이스를 위한 포인터를 담아서, 링크 후에 포인터는 인터페이스 코드와 데이터를 포인트한다.

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

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

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

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

본 발명의 양호한 실시예의 특정의 적용분야는 무선통신(무선클라이언트 네트워크), 더 구체적으로는 유일하지는 않지만 이동 셀룰러 전화 네트워크를 포함한다. 또한 본 발명은 다른 장착되는 디바이스, 양호하게는 (제한없이) 손에 쥐는 컴퓨터, 게임콘솔, 카메라같은 네트워크된 디바이스 또는 또다른 타입의 네트워크되거나 네트워크화할 수 있는 디바이스에 적용가능하다. 한 실시예에서 시스템은 무선네트워크로 구성되거나 무선네트워크를 포함할 수 있고, 반면에 다른 실시예에서는 개인 또는 공용의 고정된 네트워크 또는 인터넷을 포함할 수도 있다. 클라이언트 디바이스들이 무선통신을 이용할 수 없는 곳에서는 필요한대로(예를 들면 표준모뎀 또는 ISDN 링크를 통하여) 디바이스들이 인터넷에 연결되도록 제공된다. 이런 방식으로, 본 발명은 예를 들면 카메라, 텔레비전, 세척기계, 차량 또는 실제로 생각할 수 있는 어떤 형식의 컴퓨터로 작동되는 디바이스를 포함하는 광범위의 장착되는 디바이스에 적용가능하다.

Claims (39)

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항 또는 제14항에 있어서, 통신 네트워크를 통한 전송 전에 선택된 가상 프로세서 툴을 네이티브 코드로 컴파일하는 단계를 포함하는 것을 특징으로 하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법.
16. 제13항 또는 제14항에 있어서, 통신 네트워크를 통한 전송 후에 클라이언트 디바이스에서 가상 프로세서 툴을 네이티브 코드로 컴파일하는 단계를 포함하는 것을 특징으로 하는 객체지향적 컴퓨터 프로그램을 로딩하는 방법.
17. 제1항 내지 제16항 중 어느 항에 있어서의 방법을 수행하기 위해 구성되는 컴퓨터 시스템.
18. 각기 복수의 메소드를 담고 있는 클래스들의 형태로 제공된 코드로 구성되어; 실행환경을 규정하고, 실행을 위해 클래스 중 하나의 메소드들 중 하나를 선택하고 선택된 클래스의 전부를 실행환경으로 반드시 로딩할 필요는 없이 선택된 메소드를 실행환경으로 로딩하는 것이 작동가능하도록 한 객체지향적 컴퓨터 프로그램을 로딩하기 위한 컴퓨터 시스템.
19. 각기 복수의 메소드들을 담고 있는 클래스들의 형태로 제공되는 코드로 구성되는 객체지향적 컴퓨터 프로그램을 실행하기 위하여 각기 각각의 실행환경을 가지는 복수의 클라이언트 디바이스들과 통신수단을 통하여 통신하는 서버로 구성되는 분산 컴퓨터 시스템에 있어서,

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

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