Java and native application window integration

Details Java and native application window integration Java and native application window integration

1999-04-30

2004-01-06

Zhen, Wei (Department: 2122)

Data processing: software development, installation, and managem

Software program development tool

Programming language

C717S118000, C717S119000, C709S241000

Reexamination Certificate

active

06675371

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention relates to integrating Java-based dialogs with native dialogs in an application program and, more particularly, to resolving inadequacies of a native interface.
2. Description of the Related Art
In the pre-Java programming paradigm, an application program was typically written in a high-level programming language, such as C, C++, or Visual Basic. Before compiling the program, or converting it into a machine-readable format, the application developer was forced to decide the environment in which the application was to be used, known commonly as a platform. The platform is made up both of the CPU that runs the application software and the operating system upon which the application software is loaded. A platform-specific compiler was then selected to convert the high-level program into a binary file suitable for that platform to run the program.
Unfortunately, the output of these compilers was usually understood only by the target platform. So, even though the application was written using a portable, high-level source code, with the goal of platform independence, each compiler outputted platform-specific code. The end result, for most application developers, was that a decision about which platform was being supported had to be made before any code was written.
Then, a new programming language, Java, emerged, along with a new programming paradigm. Java is a programming language, developed in the 1990s by Sun Microsystems of Palo Alto, Calif. A program written in Java compiles to a file, known as a bytecode file. A bytecode file can run wherever a Java virtual machine resides; thus, the bytecode is not specific to any physical machine. Sun describes the Java virtual machine, or JVM, as an abstract machine or “soft” computer that can be implemented in either hardware or software, to reside on top of existing platforms.
Unlike compilers under the old paradigm, there is only one specification for the Java Virtual Machine. (Virtual machines are available from a great many vendors, including Sun, Netscape, IBM, etc. Those virtual machines which adhere to the original virtual machine specification are known as “pure Java” VMs.) So, an application developer who uses the Java language can rest assured that the application runs on any Java-capable platform: that is, any platform upon which a Java virtual machine resides. (Slight differences may appear on the GUI, but these are visual, not functional, differences.) This portability makes Java particularly suited for use on the Internet.
The Java virtual machine is also flexible in how it is implemented. The Java virtual machine may be installed onto a machine as a distinct application program, may be embedded within the operating system that resides upon the machine, or may be part of an application program which uses a Java virtual machine. Many browsers and operating systems today are touted as “Java-capable” because they include a Java virtual machine.
The presence of this new programming paradigm presents both new opportunities and new concerns. For one thing, an enormous installed base of application programs, written in other high-level programming languages under the old paradigm, are still being used and maintained. However most Java-aware developers understandably want to develop new applications, or add functionality to existing applications, using Java. The “write-once, run anywhere” promise of Java bytecode eliminates the need for the developer to rewrite an application for each possible platform. Thus, it may be sensible for developers to write all new code in Java where possible.
When developing new applications, it may be possible to write the application entirely in Java. For adding new functionality to an existing application, however, some mechanism for allowing newly developed, Java-based bytecode to interact with the legacy, or native, application software, is required.
A software development kit, known as the Java Development Kit, or JDK, provides several programs to assist Java developers. The Java Virtual Machine, described above, is one of its many components. Additionally, the development kit includes an application programming interface known as the Java Native Interface, or JNI. As named, JNI provides a mechanism for interfacing between native software programs and newly developed Java-based bytecode.
The JNI allows code that runs inside a Java virtual machine (bytecode) to inter-operate with applications written in other high-level programming languages. Developers who program through the JNI enable native code to interact with Java code, including: creating, viewing, and updating Java objects, calling Java methods, loading and obtaining class information, handling exceptions, and the like.
Despite its best intentions, JNI may be inadequate in some environments. For example, the Win32 application programming interface, or API, permits application developers to maintain different windows, or dialogs, in a graphical user interface, or GUI. As is further developed, below, the mechanism provided by JNI for interaction between native code and Java-based code is inadequate. For one thing, the Java-based dialog is visually distinct, making its appearance on a user interface with other native dialogs look out-of-place. Second, calls to methods through the JNI causes the native code to block. This blocking nature of JNI causes a stoppage of message handling in the native dialogs, thus making the application appear to be locked up or non-responsive. Third, the native code is limited in its ability to manipulate a Java-based dialog under the JNI specification. For example, the native code cannot control any of the Java-based dialogs that it created.
The choices for resolving the limitations imposed by the JNI are very unattractive. First, the developers could completely rewrite the existing native code in Java, eliminating the need to use the JNI at all. Such an approach is generally not feasible because of the large amount of code that must be rewritten. Second, a development team could restrict all Java coding to non-GUI elements. Under such a limited environment, JNI would be sufficient. However, GUIs are a large part of most applications, requiring developers to maintain multiple versions of user interface code for each platform supported. Furthermore, if the native code is never phased out, the high level of portability that makes Java-based development attractive remains elusive.
Ultimately, these unattractive choices severely restrict the benefits of JNI and effectively divert developers from adding new features to native applications using Java.
SUMMARY OF THE INVENTION
Briefly, the illustrative system provides a method for adding functionality to a user interface of non-Java based, or native, applications, using the Java programming language. Further, the illustrative system provides a method for Java-based and non-Java-based windows, or dialogs, to communicate in an application program on a graphical user interface.
To add functionality to the user interface of the native application, new dialog support is written in the Java programming language. Under the standard protocol, a call to the Java Native Interface (JNI) blocks and waits for the function call to complete, then accepts a return value. In the system illustrated herein, however, the JNI calls do block, as normal, but, once a Java thread is created, control immediately returns to a separate thread where the native application can run. Following the creation of the Java thread, message passing between the thread and the native application is implemented, to “register” the Java dialog with the native application.
Following the registration, the Java-based dialog performs its intended function as a thread separate from the native code. When the native code receives the information for registering the Java dialog, it determines the handle of the Java dialog and then creates its own “invisible” dialog. The invisible dialog is subsequently used for all message passing to the Java d

Affiliated with

Also associated with

Rating

Java and native application window integration 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 and native application window integration, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Java and native application window integration will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3229546