Java automation, testing, and analysis

Details Java automation, testing, and analysis Java automation, testing, and analysis

2000-10-04

2004-06-22

Das, Chameli Chaudhuri (Department: 2122)

Data processing: software development, installation, and managem

Software program development tool

Testing or debugging

C717S116000, C717S118000, C717S166000, C717S128000, C717S147000, C717S148000

Reexamination Certificate

active

06754889

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to the field of automation, testing, and analysis of computer programs, and specifically to the field of automation, testing, and analysis of a JAVA™ application running inside a JAVA™ virtual machine.
2. Description of Background Art
For JAVA applications to execute in a WINDOWS™ environment, the JAVA application must be executed by a JAVA virtual machine. JAVA is an interpretive language that is compiled to an intermediate format that can then be executed upon a multitude of different operating systems and processors. A JAVA virtual machine provides the communication/translation layer between the hardware, operating system, and the JAVA application being executed by the JAVA virtual machine. This design enables JAVA applications to be executed by any operating system for which the JAVA virtual machine is compiled. Typically, the JAVA application runs on what is termed a sandbox or blackbox, and therefore the JAVA application has little or no access to the underlying operating system. Conversely, the interface provided by the JAVA virtual machine also limits operating system access to the JAVA application. This limits the ability of a monitoring program executing in the operating system to access the underlying code of an executing JAVA application to monitor the performance of the JAVA application. Monitoring programs typically access the code of an executing program by analyzing the windows created by the executing program. For example, if the monitoring program and executing program are both WINDOWS-based, a monitoring program may use WINDOWS provided information about the window displayed for the executing program. The window information allows a monitoring program to modify and monitor the executing program. JAVA also uses windows within its own internal environment. For every JAVA window, a WINDOWS window object is created. However, the JAVA windows do not appear as windows to the WINDOWS operating system. For example, a displayed button that a user can press in a WINDOWS environment is a window in WINDOWS, and thus a program can monitor and access the program creating the button. Within the JAVA environment, a JAVA button appears in JAVA as a JAVA object. However, a button created by a JAVA application appears to WINDOWS as a painted object, i.e., it does not appear as a window. This is true for all windows displayed by a JAVA application. Therefore, to gain access to the information regarding a JAVA window, a calling program must determine which of the window objects being maintained by WINDOWS correspond to the JAVA windows. To do that, the calling program must gain access to the JAVA virtual machine.
There are three conventional 3 methods of obtaining access to the JAVA environment maintained by a JAVA virtual machine:
1. For a MICROSOFT™ Corporation JAVA virtual machine (including Internet Explorer), a program desiring to obtain access to a JAVA virtual machine uses a software hook provided by MICROSOFT through a registry setting.
2. For early versions of SUN™ machine (this includes virtual machines created by IBM™, BORLAND™ or SYMANTEC™), SUN provides an accessibility hook that allows a calling program to access the JAVA virtual machine by setting variables in a properties file. For example, the awt.properties file contains a setting called AWT.assistive_technologies=<some JAVA class> that can be used to load extra JAVA code when the JAVA virtual machine initializes.
3. For SUN's virtual machine after version 1.1.7, a calling program will have the option to use a software hook provided by SUN through setting an environment variable or through a command line option.
Each of these methods has flaws which makes it a less ideal solution for a calling program that needs access to the JAVA virtual machine.
MICROSOFT's and SUN's Virtual Machines (Using Software Hooks)
For MICROSOFT's virtual machine, the calling program sets the registry to enable the calling program to be called when a JAVA application starts. For the SUN virtual machine, the calling program sets the necessary environment variable that will enable the calling program to be called when a JAVA application starts. To allow the calling program's support files to be loaded, the calling program must set the CLASSPATH to point to the calling program's JAVA support files. CLASSPATH is the WINDOWS statement that tells JAVA where to find programs. This method does not require a user to modify any files to enable access to the virtual machines. However, if the CLASSPATH or registry settings are modified by other programs, the calling program will not be able to access the JAVA virtual machine. As many programs override the CLASSPATH and PATH settings, this solution may be impractical. Moreover, the calling program is dependent upon MICROSOFT and SUN for providing the software hook to allow access to the JAVA virtual machine. Finally, for SUN's 1.2. x and 1.3. x VM's, a calling program must copy supporting JAVA code to the ext of the JVM to obtain less restrictive system permissions.
SUN's Virtual Machines (Using SUN's Accessibility)
If the calling program is using SUN's virtual machine or a virtual machine compatible with SUN's virtual machine, the calling program must modify the awt.properties file in the ‘lib’ directory of the JAVA virtual machine. This will tell the interpreter to call the calling program when loading a JAVA application. The calling program also sets the CLASSPATH to point to the calling program's JAVA support files to enable the support files to be accessed by the JAVA virtual machine. This method also does not require the user to modify any files if the user is using only one JAVA virtual machine. However, similar to the above method, if the CLASSPATH is modified by other programs, the calling program will be unable to access the JAVA virtual machine. Additionally, the calling program is dependent on SUN for providing the accessibility hook, and if the user has more than one JAVA virtual machine installed on his computer, the user must write special batch files to set the location of the JAVA virtual machine he wants to use and make changes to that JAVA virtual machine's awt.properties file, a cumbersome process for most users.
Therefore, a system, method, and apparatus are needed to enable a calling program to reliably and effectively gain access to a JAVA virtual machine.
SUMMARY OF THE INVENTION
The present invention provides a system and method for enabling injection of non-native code into a JAVA environment. In a preferred embodiment, the method provides a software hook for detecting the loading of a JAVA interpreter, and then creates a connection that communicates with an executing JAVA application. In one embodiment, the present invention provides a method that loads in a customized CLASSLOADER module, wherein the customized CLASSLOADER module identifies a location of non-native code, and then loads in the non-native code identified by the customized CLASSLOADER module. In a further embodiment, in an environment that maintains a default security manager, a method in accordance with the present invention loads a custom security manager into memory by the CLASSLOADER module, and prior to loading in the CLASSLOADER module, performs the steps of disabling the default security manager, and, after loading in the CLASSLOADER module, modifying the default security manager to enable functionality performed by the non-native code. In a further embodiment, the method comprises the steps of determining whether the JAVA environment is created by NETSCAPE NAVIGATOR, responsive to determining that the JAVA environment is created by NETSCAPE NAVIGATOR, setting a NETSCAPE internal CLASSPATH to point to a customized CLASSLOADER module, loading in a customized CLASSLOADER module, wherein the customized CLASSLOADER module identifies a location of non-native code; and loading in the non-native code identified by the customized CLA

Affiliated with

Also associated with

Rating

Java automation, testing, and analysis does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Java automation, testing, and analysis, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Java automation, testing, and analysis will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3352133