Browse Prior Art Database

Constructing Fully Resolved *Java CLASSPATH Prior To Java Class Execution

IP.com Disclosure Number: IPCOM000021978D
Original Publication Date: 2004-Feb-18
Included in the Prior Art Database: 2004-Feb-18
Document File: 4 page(s) / 84K

Publishing Venue

IBM

Abstract

Execute some work prior to creating the classloader and executing the Java class, so that we can be certain that any and all external class references have been resolved. Only after completing this task can we be certain that regardless of what path we traverse in the executed class we will not encounter a Java.lang.ClassNotFoundException or Java.lang.NoClassDefFoundError.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 4

Constructing Fully Resolved *Java CLASSPATH Prior To Java Class Execution

A program is disclosed that resolves runtime dependencies for a *Java application. When executing a Java class, a user cannot be certain that they have resolved all of its external class references. The current process is that an attempt is made to execute the class, if a runtime exception, Java.lang.ClassNotFoundException or other such exceptions, is caught then the user must search the filesystem for the missing class, modify the classpath and try again. This trial-and-error approach is a tedious and time-consuming task, and it cannot be assumed that a successful execution implies a complete resolution of external classes; rather the only certainty is that the specific path that was executed has been fully resolved.

    The idea is to execute some work prior to creating the classloader and executing the Java class such that the user can be certain that any and all external class references have been resolved. Only after completing this task can the user be certain that regardless of what path is traversed in the executed class, a Java.lang.ClassNotFoundException or other related runtime exception will not be incurred.

    Five basic steps comprise our solution. First, utilize the Static External Class References Detector (SECRED) technology to determine all external class references for a particular class. Second, compare that list with the system and user-specified classpaths to determine what classes need to be resolved. Third, utilize the Java Archive Resource Locator (JARL) technology to search a specified set of directories for the missing classes. Fourth, Construct the classloader with the now fully-qualified classpath, and finally, execute the Java class with our constructed classloader.

    There are several advantages to completing this work prior to execution. First, a user does not need to know anything about a Java class in order to execute it, the only information needed is where their referenced classes live. Second, a user can be certain that all runtime dependencies have been resolved, therefore any runtime exceptions caught are most likely not due to environment and system settings. Finally, users will not be limited...