Programs written in an interpreted programming language may be executed by a programming virtual machine. In interpreted languages, rather than generating native machine code, a compiler generates byte-codes to be used by the programming virtual machine. These byte-codes provide the control and data necessary to execute an application. Subsequently, to actually execute an interpreted programming language application, an interpreter interprets the compiled byte-codes generated by the compiler. Theoretically, any programming language may be interpreted; however the term “interpreted programming language” traditionally designates languages that are implemented through execution by an interpreter. The term “interpreted programming language” also designates languages for which no compilers are written.
A well-known interpreted programming language is Java, which will be used herein as a preferred example. However, it should be well understood to those skilled in the art that other interpreted programming languages, such as REXX, BASIC, SmallTalk, Python, Perl and the like are within the scope of this invention.
Java is a software programming language, originally developed by Sun Microsystems, that is designed to generate applications that can run on all hardware platforms without modification. Because of this, Java applications have found extensive use on the World Wide Web (WWW). Java applications can be called from within hypertext markup language (HTML) documents or launched stand alone.
As is known to those skilled in the art, a WWW server may include facilities for storing and transmitting application programs, such as application programs written in Java, for execution on a remote computer.
The Java Virtual Machine (JVM) is a virtual computer component that resides only in memory on the remote computer. For a Java application to be executed on different types of data processing systems, a compiler typically generates an architecture-neutral file format so that the compiled code is executable on any processor, so long as the JVM is accessible by the processor. The architecture-neutral file format consists of bytecode instructions that are generated by a Java compiler and are non-specific to a given computer architecture. A bytecode is a machine independent code generated by the Java compiler and executed by a Java interpreter. A Java interpreter, part of the JVM, alternately decodes and interprets an intermediary code called “bytecode”. These bytecode instructions are designed to be easily interpreted on any platform and easily translated into native machine code.
Java Web Start (JWS) provides a mechanism to run Java applications without installing anything on the remote computer except the JVM and JWS. Generally, JWS simply downloads the Java application jar files from the server whenever the Java application is launched on the remote computer. This takes advantage of the Java code's machine-independence to easily update the Java application when it is launched the next time on the remote computer.
However Java Applications often use native code, for example, code written in C or C++ programming language that is specific to a particular platform or operating system. Java applications access the native codes provided by these native methods using the Java Native Interface (JNI). Typically these native methods are provided as dynamically loaded libraries (or DLLs) to the JNI. A native method DLL is usually not portable across different operating platforms.
When Java applications use JNI and have dependency on a DLL that has dependencies on other DLLs, the JWS encounters certain limitations in launching the Java application. For example, if the Java application has any JNI code with dependencies on other libraries, the application will not start if the libraries are not in the path of the Java Runtime Environment (JRE). This applies to any main Java application but also to JWS itself (e.g. if there is any JNI code with dependencies on other libraries, JWS will also not start). JWS can load the JNI library only if the library does not have any other dependencies or if the dependencies are already installed where the JVM can locate them.
JWS does not allow the loading of the JNI library from the webstart cache even if they are available in the cache. For example, the main Java application has JNI code in the library a.dll, which has dependencies on the libraries b.dll and c.dll. JWS cannot load b.dll and c.dll even if they are in the same jar file as a.dll. For JWS to work, libraries b.dll and c.dll need to be installed in an existing directory that is already in the path of the JRE.
In such a situation, Java Web Start launches the application but the application fails to start. To circumvent this situation, an external installer program, such as InstallShield, must then be run on the remote computer. The remote computer is then connected to the server and receives the dependent libraries for installation. The Java application is then re-started. If there are updates to the libraries at the next launch of the application, they must also be manually installed.
It would be desirable therefore to provide a mechanism to install and update native code libraries and their dependencies that does not require an external installer. It would further be desirable to provide a mechanism to install and update native code libraries and their dependencies for the use of applications written in interpreted programming languages.
More particularly, it would be desirable to provide a mechanism to install and update the JNI libraries and their dependencies that does not require an external installer. It would further be desirable to provide a mechanism to install the dependencies in the JRE path using JWS as well as a mechanism for the JNI to easily update its dependencies.
The present invention provides a method and system for dynamically installing and updating such native code libraries and their dependencies from the server in order to overcome the objections described above.
USPTO Backgrounds
USPTO Backgrounds