Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1997-12-16
2002-02-19
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000, C717S152000
Reexamination Certificate
active
06349344
ABSTRACT:
FIELD OF THE INVENTION
This invention relates generally to Java class files, and more particularly to the combination of such files into a run-time image.
BACKGROUND OF THE INVENTION
Java is a relatively new object-oriented programming language that has become the subject of interest of many programmers. Ideally, Java is an architecture neutral and portable language, in that the same version of the program purportedly should run on any platform without modification—i.e., a computer running a version of the Microsoft Windows operating system, a computer running a version of the Apple MacOS operating system, a computer running a version of the UNIX operation system, etc., should all be able to run the same version of a Java program. That is, there are purportedly no “implementation-dependent” aspects of the Java language specification.
However, in reality, programs written in Java may not be realistically run on any platform without modification to allow for differences among different platforms, because of the inherent limitations and particularities of any given platform. For example, Microsoft Windows CE is a compact, efficient and scalable operating system that may be used in a wide variety of embedded products, from handheld PCs to specialized industrial controllers and consumer electronic devices. Many devices that utilize Microsoft Windows CE are intended to have a relatively low amount of random-access memory (RAM), such as one megabyte, to ensure that the devices remain low in cost, compact in size, and efficient in the usage of power. Further, devices designed to utilize Microsoft Windows CE typically have less powerful processors than what is typically found on computers designed to run more powerful operating systems like Microsoft Windows NT.
The nature of Java, however, is not necessarily consistent with the running of Java-written programs in such environments as Microsoft Windows CE. Java is both a compiled and an interpreted language. Java source code is turned into simple binary instructions—called Java byte codes or J-code—much like ordinary microprocessor machine code. However, whereas C or C++ source code is refined to native instructions for a particular processor, Java source code is compiled into a universal format, instructions for what is known as a Java virtual machine.
The Java virtual machine thus is a native program running within an operating system to interpret and execute Java byte code. The fundamental unit of Java code is the class. As in other object-oriented languages, classes are application components that hold executable code and data. Compiled Java classes are distributed in a universal binary format that contains Java byte code and other class information. Classes may be maintained discretely and stored in files or archives on a local system or on a network server. Typically, classes are loaded and parsed dynamically at run-time, if they are needed by an application.
In other words, Java has been designed so that software implementations of the run-time system are able to optimize their performance by compiling byte-code to native machine code on the fly. A class file is loaded and parsed, such that it is compiled on a “just in time” basis at run-time. Thus, when a Java program is run by a Java virtual machine, there are ultimately two versions of necessary class files: the byte-code versions that initially existed prior to the running of the program, and the loaded and parsed versions when the program is first run on the Java virtual machine.
There are several disadvantages to this design of the Java programming language in the context of platforms like the Microsoft Windows CE platform that are designed for efficiency and cost, and thus may not have as much memory as and have slower processors than, for example, desk-top computers running Microsoft Windows NT. First, the typical Java program uses many class files, such that loading and parsing these class files at run-time takes a long time on a less powerful processor. For example, it has been found that running a simple “Hello World” program—e.g., a program that causes the words “Hello World” to be displayed on the screen—may take more than nine minutes to execute on a handheld device having a processor running at about forty megahertz, because of the initial loading and parsing of class files at run-time.
One aspect of this initial loading and parsing is frequently the translation of the byte codes of the Java class files from big endian format to little endian format. That is, byte codes in Java class files are in big endian format such that the bytes are ordered from least significant to most significant (e.g., 0, 1, 2, 3), whereas on many platforms, little endian format is used, where bytes are to be ordered from most significant to least significant (e.g., 3, 2, 1, 0). Another aspect of this initial loading and parsing is that the Java class file format does not specify the location of a native member function, such that the virtual machine must search trough all the loaded files in a process to find the desired method.
A second distinct disadvantage ties into the fact that each Java class file contains a copy of all the data required to run that class—e.g., such as information regarding the superclasses to which the class is related. This data is often duplicated in other class files as well, wasting space unnecessarily. This is especially problematic in devices having limited amounts of RAM. For example, it has been found that in Java 1.1 (more specifically, Java Development Kit 1.1, or JDK 1.1), a simple “Hello World” program has a run-time memory footprint of over 700 kilobytes in a given handheld device, or nearly seventy percent of an available one megabyte of RAM. Such a handheld device may also require about 300 kilobytes of RAM to maintain the screen, meaning that programs greater in complexity than a simple “Hello World” program are not likely to run at all on the device.
Third, a related problem is that in a typical Java run-time system the Java class files are filed in storage. This may be RAM or read-only memory (ROM). When the Java virtual machine requires these files for execution, they are loaded into RAM and parsed, such that the resulting data are stored in RAM during execution. This means that during the running of a Java program, there are actually two versions of the needed class files stored on the machine—the unloaded and unparsed Java class files in storage (either RAM or ROM), and the loaded and parsed Java class files in RAM. For memory-constrained devices, this is burdensome.
There is a need, therefore, for a solution that overcomes these disadvantages and shortcomings of the loading and parsing of Java class files at run-time by a Java virtual machine, so that Java programs may realistically be more able to run on memory-constrained and slower platforms such as handheld devices running Microsoft Windows CE.
SUMMARY OF THE INVENTION
The above-mentioned shortcomings, disadvantages and problems are addressed by the present invention, which will be understood by reading and studying the following specification. The invention describes combining multiple Java class files into a run-time image. The run-time image of the Java class files is such that class files are in a preloaded and pre-parsed state for a Java virtual machine. Desirably, the run-time image is a DLL file stored in read-only memory (ROM), and comprises non-redundant data.
The run-time image is desirably created by a separate utility that preloads and preparses a given collection of Java class files, such that the Java virtual machine does not have to load and parse the files at run time, but instead can rely on the run-time image itself. Desirably, this includes translating the byte codes of the Java class files from big endian format to little endian format, and also creating import records such that native member function data structures point thereto, permitting faster native member function resolution.
The invention therefore provides for advantages not found in the prior art.
Markley Michael E.
Sauntry David M.
Courtenay III St. John
Microsoft Corporation
Workman & Nydegger & Seeley
LandOfFree
Combining multiple java class files into a run-time image does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Combining multiple java class files into a run-time image, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Combining multiple java class files into a run-time image will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2948274