Browse Prior Art Database

Improved Method for Starting an Embedded Application Disclosure Number: IPCOM000014843D
Original Publication Date: 2001-Jan-01
Included in the Prior Art Database: 2003-Jun-20

Publishing Venue



Described is an improved method by which an application can start an embedded applicatoin like a Java Virtual Machine (JVM). The improved method reduces hard-coded dependencies between the application and the JVM, thus enabling applications to exploit new function sooner without code changes, and making maintenance and tuning more efficient. This disclosure addresses two sources of dependencies between applications and the JVM that that can be improved. This disclosure proposes a way to resolve the two dependencies. First, applications have many dependencies on the internal structure of the JVM they want to start, which makes startup code more complicated and puts restrictions on the way JVMs can be structured to suit various configurations. For example, currently the application must set up a path variable for two directories, a classpath variable for another, and will have a hard-coded dependency on the name of the dll containing the startup api. Any of the paths or names can be changed from release to release, for example, because a new debug version is developed, or because two different versions are required due to hardware or operating system dependencies. While the hard-coded dependency cannot be completely eliminated without some convention on the part of the application, the number of dependencies can be reduced and the problem of changability can be eliminated by putting a startup api (a new one in the case of the JVM) in a dll separate from parts of the JVM that may have dependencies, guaranteeing the name of the new dll across releases, and including version information in the JVM startup parameters, so that the startup api can load the appropriate version of the JVM at runtime. In addition the structural dependency can be further reduced if applications by convention use an environment variable, or some other external configuration method, to provide the path to find the jvm, and possibly a second environment variable for the name of the dll containing the startup api. Another useful convention would be to require applications to do an explicit lookup of the api name in the dll. The second dependency is that the startup parameters passed into the the JVM from the application are passed in a program structure, with the result that the format of the parameters and even which ones are supported are hard-coded dependencies in the application. Another problem is that the extemal representation of the these parameters will vary across different applications that exploit the embedded JVM. The result is that it is very difficult for service people to know what parameters have been passed to the JVM at startup, to know where they actually came from, to know how to change them for tuning or debugging purposes, or for customers or service people to exploit new function that has parameter dependencies. It is instead proposed to provide the startup parameters to the JVM via a parameters file. For example, the startup api could accept a string containing a file name, or a path and file name, as one of the function arguments. The file would contain those parameters that do not require program addresses or other runtime determined hex values, but there are other methods. Additionally, the file could have a human readable format. The format could be such as to allow comments to be inserted between parameters, or to allow parameters for different components to reside in the same file. One mechanism might be to use HTML style tags to identify the section of the file containing the JVM parameters. Note that these mechanisms are not limited to starting a JVM, but can be used for any embedded application that is started by another application.