Transparent loading of resources from read-only memory for...

Details Transparent loading of resources from read-only memory for... Transparent loading of resources from read-only memory for...

1999-07-15

2003-06-24

Morse, Gregory (Department: 2122)

Data processing: software development, installation, and managem

Software program development tool

Linking

C717S118000

Reexamination Certificate

active

06584612

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a computer system, and deals more particularly with a method, system, and computer program product for transparently loading resources (such as stored bitmaps, images, fonts, and sound files) from read-only memory (“ROM”) for an application program executing on a Java Virtual Machine.
2. Description of the Related Art
Java is a robust, portable object-oriented progrannning language developed by Sun Microsystems, Inc., and which is gaining wide acceptance for writing code for the Internet and World Wide Web (hereinafter, “Web”). While compilers for most programming languages generate code for a particular operating environment, Java enables writing programs using a “write once, run anywhere” paradigm. (“Java” and “Write Once, Run Anywhere” are trademarks of Sun Microsystems, Inc.)
Java attains its portability through use of a specially-designed virtual machine (“VM”). This virtual machine is also referred to as a “lava Virtual Machine”, or “JVM”. The virtual machine enables isolating the details of the underlying hardware from the compiler used to compile the Java programming instructions. Those details are supplied by the implementation of the virtual machine, and include such things as whether little Endian or big Endian format is used on the machine running the Java program. Because these machine-dependent details are not reflected in the compiled code, the code can be transported to a different environment (a different hardware machine, a different operating system, etc.), and executed in that environment without requiring the code to be changed or recompiled—hence the phrase “write once, run anywhere”. The compiled code, referred to as Java “bytecode”, then runs on top of a JVM, where the JVM is tailored to that specific operating environment. As an example of this tailoring of the JVM, since bytecodes are generated in a canonical format (big Endian), if the JVM is running on a machine which is little Endian, then the JVM would be responsible for converting the instructions from the bytecode before passing them to the microprocessor.
The Java runtime environment includes the JVM, as well as a number of files and classes that are required to run Java application or applets. Hereinafter, the terms “JVM” and “runtime environment” will be used interchangeably unless otherwise noted.
Java applications are typically executed from a development toolkit such as the “JDK” (Java Development Kit) product from Sun Microsystems, or using the “JRE” (Java Runtime Environment) product, also from Sun Microsystems. The JRE is a subset of the JDK, providing the functionality which is required for application execution. Programs are executed from the command line when using the JRE.
A Java class called a “class loader” is used in Java environments to dynamically load classes and resources in a running program.
FIG. 1
illustrates the prior art technique of class loading using a JVM and class loader. The class loader function of the JVM allows a Java application program to be loaded incrementally, as the program executes. As is known in the art, the programmer writes a Java program, and then compiles it into Java bytecodes. Files containing the Java bytecodes are called “class files”. The programmer
100
then loads
101
the class files into a repository
110
or
111
of class files. At some later point, the application program
150
is executed by a JVM
140
on a client computer
160
. When the application
150
attempts to use a class that has not been loaded on the client computer
160
, the class loader component
130
of the JVM
140
may make a request
102
a
to a class server
120
. (The class server function
120
is typically included in standard Web servers.) This request
102
a
notifies the class server
120
to fetch
103
a
,
104
a
the class file from the class repository
110
, and return it
105
a
to the JVM
140
. Alternatively, the class loader
130
may locate the desired class in a directory of a local file system
111
. In this case, the desired class is requested
102
b
from the file system
111
and returned
105
b
to the JVM
140
. Regardless of the location
110
or
111
from which the file was retrieved, the application
150
then continues executing, using the retrieved class file. This dynamic loading of class files operates transparently to the user of the application
150
.
The Java class loader uses a predetermined search strategy when locating files, which gives precedence to particular locations. According to the Java 1.2 platform specification, the highest-priority search locations are the bootstrapped runtime and internationalization classes, named “rt.jar” and “i18n.jar”, respectively. If the desired class is not found in those locations, the next-highest priority is to look in the installed extensions, which are classes in JAR files stored in the “lib/ext” directory of the JRE. (“JAR” refers to “Java archive”, which is a file format used for distributing and archiving files used by an application.) Finally, if the class has still not been found, the class path system property setting is consulted. Any paths specified by the class path, and any paths identified in Class-Path attributes of the manifests of JAR files located using those paths, may be used to search for the desired class. (See “Understanding Extension Class Loading”, available on the Web at http://java.sun.com/docs/books/tutoriaVext/basics/load.html, for more information.) In addition, a class file may be loaded from a known location by specifying its location in the file system (with a directory and file name identification), or from a location on a Web server by specifying its Uniform Resource Locator (URL).
This prior art approach of dynamic loading is also used for retrieval and loading of resource files used by Java applications. The resources may have been separately stored in the same directory as the executable class files; they may be packaged into the same JAR file as the class files; or they may be stored in a common directory structure with the class files, but gathered into a separate subdirectory (such as an “images” or “resources” subdirectory).
Existing class loader functionality assumes the existence of a file system, and that the CLASSPATH environment variable or “java.class.path” system property will identify a location in that file system where the class loader can dynamically search for desired class files and resources. However, a proliferation of new computing devices are being developed which are intended for mobile or portable use. These devices are designed to be lightweight, compact, and highly efficient (from a cost perspective as well as an operating perspective), and thus many are designed without the overhead of disk drives and the file system software used to access disk files. (In addition, these devices are often configured with a relatively small amount of memory, on the order of several megabytes.) Examples of these devices, referred to hereinafter as “embedded devices”, include personal digital assistants (PDAs); cellular phones and screen phones; pagers; and wearable computing devices.
Resource files may be stored in the read-only memory of these embedded devices, given the absence of disk drive storage. However, the existing Java class loader mechanism preferentially searches for stored files in a file system, as previous described. Having no file system, an alternative technique must be provided for these embedded devices. This technique must efficiently locate resources needed by an application program executing on the embedded device. One technique has been described in pending U.S. patent application Ser. No. 09/373,400 titled “Access to Resource Files Stored in ROM”, which is assigned to the same assignee and is incorporated herein by reference. However, that technique requires modification of existing application code to specifically search for resources in ROM storage. While this approach is beneficial in particular situations, it may alternatively be p

Affiliated with

Also associated with

Rating

Transparent loading of resources from read-only memory for... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Transparent loading of resources from read-only memory for..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Transparent loading of resources from read-only memory for... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3129991