Browse Prior Art Database

Externalization of Java virtual machine runtime properties

IP.com Disclosure Number: IPCOM000126147D
Original Publication Date: 2005-Jul-04
Included in the Prior Art Database: 2005-Jul-04
Document File: 2 page(s) / 51K

Publishing Venue

IBM

Abstract

Disclosed is a system for providing a Java* virtual machine with a list of system classes at start-up time while simultaneously satisfying the requirements to have flexibility in the list of system classes and providing additional information relating to those system classes. The disclosure describes a look-aside file that describes information normally hard-coded into the virtual machine launcher program which can be used to provide additional information about the system files such as source code location.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Externalization of Java virtual machine runtime properties

Java's* system classes are distiguished by being loaded by the boot class loader. The known implementations of Java Virtual Machines (JVMs) hard-code a list of system Java archive (JAR) files in the virtual machine launcher program. The problem with this known approach is that any change to the list of system classes requires recompiling the launcher program which in turn requires a C development environment. In addition, the hard-coded JAR files in the launcher program do not provide additional information about the system classes that is useful to a Java developer.

    The core idea of this disclosure is to externalize the list of JAR files that comprise the system classes into a text file that can be read by both the JVM and Java development tools. The text file is kept in a well-defined location that can be found relative to the Java installation directory. The advantages of this approach include: - the information required by JVM and Java development environment is co-located thereby making it easier to manage and maintain, - the information about the system classes can be arbitarily extended,

- modifications to the list of system classes is as simple as editing a text file,

- application installations can add extensions to the system classes without requiring additional parameters to every JVM invocation.

Detailed description

    The current state of the art is to encode the JAR files into the C launcher program, using something like the code that follows:

/* Define bootclaspath for 1.4.2 and above */ jclBootstrapClassPath[0] = "classes.zip"; jclBootstrapClassPath[1] = "vm.jar"; jclBootstrapClassPath[2] = "core.jar"; jclBootstrapClassPath[3] = "charsets.jar"; jclBootstrapClassPath[4] = "graphics.jar"; jclBootstrapClassPath[5] = "security.jar"; jclBootstrapClassPath[6] = "ibmpkcs.jar"; jclBootstrapClassPath[7] = "ibmorb.jar"; jclBootstrapClassPath[8] = "ibmorbapi.jar"; jclBootstrapClassPath[9] = "ibmjcefw.jar"; jclBootstrapClassPath[10] = "ibmjssefips.jar"; jclBootstrapClassPath[11] = "ibmjgssprovider.jar"; jclBootstrapClassPath[12] = "ibmjsseprovider.jar"; jclBootstrapClassPath[13] = "ibmjaaslm.jar"; jclBootstrapClassPath[14] = "ibmjaasactivelm.jar"; jclBootstrapClassPath[15] = "ibmcertpathprovider.jar"; jclBootstrapClassPath[16] = "server.jar"; jclBootstrapClassPath[17] = "xml.jar"; jclBootstrapClassPath[18] = NULL;

    This shows how the entries on the bootclasspath ar hard-coded, and the use of particular fie names is assumed. This becomes a real problem when dependencies are placed upon third-party JAR files, who in turn may rename files (such as to include version numbers) which requires recompiling the source code for the launcher. Typically source code is unavailable for the launcher. The usual

Page 2 of 2

workaroun...