Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1998-08-13
2001-08-28
Powell, Mark R. (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C717S152000, C717S152000
Reexamination Certificate
active
06282702
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to the field of computer systems, and, more specifically, to virtual machine runtime environments.
Solaris, Sun, Sun Microsystems, the Sun logo, Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
2. Background Art
The Java™ programming language, developed by Sun Microsystems®, has an advantage over other programming languages of being a “write once, run anywhere”™ language. The Java programming language provides a substantially platform-independent mechanism for applications, or “applets,” to be designed, distributed and executed in the form of bytecode class files. The Java virtual machine handles the resolution of the bytecodes into the requisite platform dependent instruction set, so that all computing platforms which contain a Java virtual machine are capable of executing the same bytecode class files. When functions are needed which are not supported by the Java programming language, a Java application executing within the virtual machine may invoke native code functions implemented in linked libraries. Native code is not subject to Java programming and execution restrictions, thus providing more platform-specific programmability at the cost of less well-controlled execution behavior. A processing environment for Java applications and applets, and the use of native code, are described more fully below.
The Processing Environment
The Java programming language is an object-oriented programming language with each program comprising one or more object classes and interfaces. Unlike many programming languages in which a program is compiled into machine-dependent, executable program code, classes written in the Java programming language are compiled into machine independent bytecode class files. Each class contains code and data in a platform-independent format called the class file format. The computer system acting as the execution vehicle contains a program called a virtual machine, which is responsible for executing the code in each class.
Applications may be designed as standalone Java applications, or as Java “applets” which are identified by an applet tag in an HTML (hypertext markup language) document, and loaded by a browser application. The class files associated with an application or applet may be stored on the local computing system, or on a server accessible over a network. Each class is loaded into the Java virtual machine, as needed, by the “class loader.”
To provide a client with access to class files from a server on a network, a web server application is executed on the server to respond to HTTP (hypertext transport protocol) requests containing URLs (universal resource locators) to HTML documents, also referred to as “web pages.” When a browser application executing on a client platform receives an HTML document (e.g., as a result of requesting an HTML document by forwarding a URL to the web server), the browser application parses the HTML and automatically initiates the download of the specified bytecode class files when it encounters an applet tag in the HTML document.
The classes of a Java applet are loaded on demand from the network (stored on a server), or from a local file system, when first referenced during the Java applet's execution. The virtual machine locates and loads each class file, parses the class file format, allocates memory for the class's various components, and links the class with other already loaded classes. This process makes the code in the class readily executable by the virtual machine.
Java applications and applets often make use of class libraries. Classes in the class libraries may contain what are referred to as “native methods.” Applications and applets may occasionally contain classes that have native methods as well. A native method specifies the keyword “native,” the name of the method, the return type of the method, and any parameters that are passed to the method. In contrast to a “standard method” (i.e., non-native method) written in the Java programming language, there is no body to a native method within the respective class. Rather, the routines of a native method are carried out by compiled native code (e.g., code written in the C or C++ programming language and compiled into binary form) that is dynamically linked to a given class in the virtual machine at runtime using a linking facility specific to the given platform which supports linked libraries.
In the Solaris™ or UNIX environment, for example, the linked library containing the binary form of the native code may be implemented as a “shared object” library written as a “.so” file. In a Windows environment, the linked library may take the form of a dynamic linked (or dynamic loadable) library written as a “.dll” file. Native code may be used to perform functions otherwise not supported by the Java programming language, such as interfacing with specialized hardware (e.g., display hardware) or software (e.g., database drivers) of a given platform. Native code may also be used to speed up computationally intensive functions, such as rendering.
A class that contains a native method also contains a call to load the respective linked library:
System.loadLibrary(“Sample”);
where “Sample” is the name of the linked library, typically stored in a file named “libSample.so” or “Sample.dll”, depending on the host operating system (e.g., UNIX, Windows, etc.). The linked library is typically loaded at the time the associated class is instantiated within the virtual machine.
The linked library of native code is compiled with stub and header information of the associated class to enable the linked library to recognize the method signature of the native method in the class. The implementation of the native method is then provided as a native code function (such as a C function) in the linked library. At runtime, when a call is made to the native method, control is passed to the function in the linked library that corresponds to the called method (e.g., via pushing of a native method frame onto the native method stack). The native code within the linked library performs the function and passes control back to the Java application or applet.
FIG. 1
illustrates the compile and runtime environments for a processing system. In the compile environment, a software developer creates source files
100
(e.g., in the Java programming language), which contain the programmer readable class definitions, including data structures, method implementations and references to other classes. Source files
100
are provided to Java compiler
101
, which compiles source files
100
into compiled “.class” files
102
that contain bytecodes executable by a Java virtual machine. Bytecode class files
102
are stored (e.g., in temporary or permanent storage) on a server, and are available for download over a network. Alternatively, bytecode class files
102
may be stored locally in a directory on the client platform.
The Java runtime environment contains a Java virtual machine (JVM)
105
which is able to execute bytecode class files and execute native operating system (“O/S”) calls to operating system
109
when necessary during execution. Java virtual machine
105
provides a level of abstraction between the machine independence of the bytecode classes and the machine-dependent instruction set of the underlying computer hardware
110
, as well as the platform-dependent calls of operating system
109
.
Class loader and bytecode verifier (“class loader”)
103
is responsible for loading bytecode class files
102
and supporting class libraries
104
into Java virtual machine
105
as needed. Class loader
103
also verifies the bytecodes of each class file to maintain proper execution and enforcement of security rules. Within the context of runtime system
108
, either an interpreter
106
executes the bytecodes directly, or a “just-in-time” (JIT) compiler
107
transforms the bytecodes into machine code,
Nguyen-Ba Hoang-Vu Antony
Powell Mark R.
Sun Microsystems Inc.
The Hecker Law Group
LandOfFree
Method and apparatus of translating and executing native... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus of translating and executing native..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus of translating and executing native... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2454017