Data processing: software development – installation – and managem – Software program development tool – Testing or debugging
Reexamination Certificate
2001-03-08
2004-11-30
Zhen, Wei (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Testing or debugging
C717S163000
Reexamination Certificate
active
06826746
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to computer software development tools and more particularly to a method and system for debugging a Java application that includes native method dynamic load libraries (e.g., C or C++ code).
2. Description of the Related Art
Traditional programming methodologies are organized around actions and logic. Programs developed using traditional software design methodologies are usually easily represented by flow diagrams and could be viewed as a procedure of steps which receive input, processes the data, and produces output.
Object Oriented Programming (“OOP”), however, is organized around objects and data. OOP approaches programming from a perspective centralized on providing objects, each object having an interface through which it may be used or by other programs and objects to perform a “method” or set of methods.
One of the earliest object-oriented computer languages was Smalltalk[™]. More recent and perhaps more widely used object-oriented languages are C++ and Java.
The Java programming language is especially adapted for use in distributed applications, such as on corporate networks and the Internet. Additionally, Java applications have found extensive use on the World Wide Web.
Java developers often “extend” a Java application by linking their own Java code with native method dynamic load libraries (“DLL”). A “native method” DLL is usually a function written in another programming language, such as “C” or “C++”, which is not portable across different operating platforms without recompilation.
When the Java application includes linked native method DLL's, a problem arises in debugging the application. In particular, while “tools” for debugging Java code, on the one hand, and tools for debugging C/C++ code, on the other hand, are well-known, the art lacked the ability to simultaneously debug a piece of software that included both types of code.
As a result, some available methods addressed the problem of debugging Java applications having linked native method DLL's by using a “brute force” approach by using distinct debug routines that are run separately. This approach required the Java application with the linked native language DLL's to be executed twice, one for each debug routine, thereby substantially increasing the time necessary to debug the Java application.
The system and method disclosed in U.S. Pat. No. 5,901,315 to Edwards, et al., provided a solution to this problem at the time of its availability and in keeping with currently available companion Java development tools. This system and method provided for debugging a target application which comprised Java code having linked native method DLL's which was carried out in a computer having an operating system, a system debug application programming interface (“API”), and a Java virtual machine (“JVM”) having a Java debug API.
According to the Edwards system and method, the JVM was first launched under the system debug API, and the Java application was then run under the JVM. Because the JVM that runs the target application itself runs under the system debug API, simultaneous control of the target application via the system debug API and the Java debug API was enabled. Thus, the method allowed the debug of the target application by simultaneously debugging the Java code and the native method dynamic load libraries. Events generated during the debug process were characterized as being initiated from the Java code or the native method DLL's, as the case may be. The preferred embodiment of the Edwards debugger comprised a graphical user interface (“GUI”) front end, a debug engine back end, and a “probe” or daemon. The GUI provided an interface through which the user made requests and viewed the status of the application being debugged. The debug engine performed the debugging work by controlling the probe to manipulate the target application through the JVM, and to report events to the debug engine.
The probe was preferably implemented as two distinct processes, a first “daemon” process that performed native method debugging, and a second “probe” process that performed the Java method debugging. The first process also preferably controlled the second process across the system debug API and communicated therewith via a socket connection to facilitate the simultaneous debugging of the Java and C/C++ code comprising the target application.
According to another feature of the Edwards method, the front and back end components of the debugger were supported on a first computer, while the first and second “processes” were supported on a second computer. The first and second computers could then be connected over a computer network such as a TCP/IP connection to facilitate remote debugging of the target application. The Edwards system and method was implemented in a programming tool product from International Business Machines (“IBM”) under the name Interactive Code Analysis Tool (“ICAT”).
The current ICAT for Java utilizes a GUI to permit source-level debugging of Java applications on Microsoft's Windows[™] NT 4.0 and Windows2000. Using ICAT, application developers can set breakpoints, execute and step their applications, and examine the application's stack and variables all with the click of a mouse. If desired, the debugger can be operated remotely; that is, ICAT resides on one system, and the probe resides on the system containing the application. Communication between the two systems is via a TCP/IP connection. The ICAT probe is written in Java, and it interacts with the JVM as needed to control the application being debugged. Essentially, ICAT starts a Windows process, which is the JVM running the probe. ICAT then communicates with the probe via TCP/IP. If ICAT is being run remotely, a daemon is run on the target system which interacts with the probe.
For versions of the JVM before version 1.3, the ICAT probe utilized Sun Microsystems' sun.tools.debug Application Programming Interface (“API”) in order to control the application being debugged. The sun.tools.debug API is easy to use, but it is missing a number of functions that the ICAT customarily provided for other debuggers for other programming languages.
Beginning with version 1.3 of the JVM, several new debugger interfaces were provided. Further, support for the sun.tools.debug API was no longer supported. The new Sun product is called the “Java Platform Debugger Architecture” (“JPDA”), and it has three components:
(1) the Java Virtual Machine Debugging Interface (“JVMDI”), which is a low-level native interface which defines what support a JVM must provide in order to allow an application to be debugged;
(2) the Java Debug Wire Protocol (JDWP), which allows communication between a debugger virtual machine and a target virtual machine; and
(3) the Java Debug Interface (JDI), which is a high-level interface, which uses JDWP and JVMDI.
New JPDA features include the ability to exclude classes while stepping modify Java variables, use deferred breakpoints, create watchpoints, display thread names, attach to running processes, and set breakpoints at arbitrary bytecode addresses. JPDA also allows for capturing output from applications for display by the debugger and permits sending input from the debugger to applications. Further, JPDA is believed to be more stable than the sun.tools.debug API.
There are some known disadvantages to using JPDA. Many functions that the probe performs are more complicated to implement with JPDA, especially exception filtering. Also, the ICAT function which allows users to load classes is not officially supported in JPDA.
In as much as the existing ICAT does not support JPDA, and whereas JPDA provides improved functionality and stability for Java application program development, testing, and debugging, there is a need in the art for a system and method such as ICAT which supports JPDA and its new functionality.
REFERENCES:
patent: 5548717 (199
Evans David H.
Gay Christopher James
Scherk Anthony Paul
Frantz Robert H.
International Business Machines - Corporation
Mims Jr. David A.
Tang Kuo-Liang J.
Zhen Wei
LandOfFree
Debugger probe for object oriented programming does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Debugger probe for object oriented programming, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Debugger probe for object oriented programming will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3323412