Java and native application window integration

Abstract

A system for adding functionality to a graphical user interface of a non-Java based, or native, application, using the Java programming language is provided. A Java window, or dialog, is configured to be accessible by a native application. While the native application is executed in a first thread, a Java dialog is launched in a second thread. Execution of the native application in the first thread is then continued. The Java dialog next calls the native application and registers itself with the native application. Also, the native code can control the Java dialog like other dialogs supported by the native code. A command for a Java dialog from a native application is routed to an invisible dialog. The invisible dialog passes that command to the Java dialog through a native interface connection. A very seamless integration between the Java and native code thus occurs. The graphical user interface operates and visually appears as if controlled from a single source of code.

Description

[0001] 1. Field of the Invention[0002] 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.[0003] 2. Description of the Related Art[0004] 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.[0005] Unfortunately, the output of these compilers was usually understood on...

AI Technical Summary

Problems solved by technology

Unfortunately, the output of these compilers was usually understood only by the target platform.

Despite its best intentions, JNI may be inadequate in some environments.

As is further developed, below, the mechanism provided by JNI for interaction between native code and Java-based code is inadequate.

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.

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.

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.

The result is a very seamless integration on a graphical user interface between the Java-based code and the native code.

Images