JStart

Introduction

The conventional way to launch a Java application is to use a shell script (batch file on win32) to invoke the Java VM loader program, while providing it with the rather large number of parameters it typically requires. However, this has a number of disadvantages:

• Platform-specific scripting code. Different scripts are required for win32 and unix variants.
• Dependence on environment variables. Some scripts require that the system administrator set global environment variables in order to make the script work. This can be highly inconvenient and somewhat fragile.
• Weak OS handling of scripts. Unix has strong support for shell scripts; indeed, quite a lot of OS functionality is implemented in this way. However, this is not the case on win32. Here, launching a batch file generates a DOS box; exact behaviour depends on the version of win32 being used, with win9x being especially problematic [Microsoft no longer supports win9x, so Sun don't support it either; YMMV.]. There are ways to get around this, but the whole thing feels rather amateurish to Windows users.
• Process-agility. When launching a Java app from another app, the launcher app often wishes to retain a degree of control over the launched app. To achieve this, the launcher uses some kind of "handle" object, which it obtains from the OS at launch time, and which refers to the process of the launched app. However, where the launched process is only a script, which in turn launches the java loader as another process and then quickly terminates, the handle becomes useless. This kind of process-agility can cause big problems, especially where the launcher is written in Java.
• Configurational and launching problems. Java launcher apps have serious difficulty in launching scripts on win9x (the Java process launcher can only launch standard windows EXE's, and the win9x command processor is a .COM image).

JStart addresses these issues by replacing the scripts with a conventional executable, which reads parameters from a separate configuration file. JStart then uses the Java Invocation API to start the VM inside the JStart process itself.

Actually this is only currently true on win32; the unix JStart is actually a shell script which invokes the ordinary java bootloader. This is for compatibility: the "bootloader" on unix is sometimes itself a complex script which does Strange Things and is best left alone. Due to the semantics of process invocation on unix, this doesn't cause problems, although it would on win32.

Win32/x86 and Linux/x86 (recent distros) are supported. Java 1.4 - Java 6 only. We intend to port to Solaris/SPARC and Mac OS X when resources permit; interested hackers would be needed for ports to other platforms. It is conjectured that the Linux version of JStart should work as-is on other flavours of unix, and on OS X.

Usage

On unix, java must be available on the system PATH. The Java installation process (whatever that is for your version of unix) will usually see to it that this happens. If not, get your sysadmin to provide a suitable symlink.

Syntax: jstart [-version] [-f bootname] [args]

• -version: Prints the version of JStart and then exits. This must be the only parameter supplied.
• -f bootname: Load parameters from the file, which is located in the same folder as the executable, and whose name is bootname.boot. The format of this file is described in the next section. If this option is omitted, bootname is taken as the name of the executable itself. If, only in this "implicit" case (and not when an explicit -f parameter is supplied), no matching boot file is found, then the executable name is converted into lowercase, and this version is used as the bootname. This is a compatibility feature for case-insensitive filesystems.
• args A set of space-delimited command-line arguments. These are passed through verbatim to the Java app. They come after any arguments specified in the configuration file.

The boot file format

JStart requires a set of parameters, which are contained in a .boot file. This file is a standard ASCII text file, with either CR/LF or LF line termination (DOS or unix, respectively). There are no limits (apart from memory) upon line lengths within this file.

Valid line formats are as follows.

• Whitespace. The line contains nothing except whitespace.
• Comment. Comment lines start with a # character.
• -title string : On win32, the title for the console window. Only one must be specified.
• -noconsole : On win32, the Java console is destroyed just before invoking the main method of the specified class. On unix, this has no effect. YMMV with apps which send output to the console, since there isn't one.
• -vm variant : specify which variant of the VM to use. For Sun JVM's, the valid options are client (the default) or server.
• -classpath path : the path specified by path will be added to the class path. Use unix-style forward slash as the directory marker, rather than win32-style backslash. Use one -classpath entry for each path (thus, you don't need to worry about whether to use unix-style ":" or windows-style ";" path separators).
• -runclass [package[.subpackage]].classname The class whose main method will be invoked. Exactly one must be specified.
• -cpclassload Use the Checkpoint loader. Checkpoint applications will usually need this, others won't. More details below.
• -arg string : specify a command-line argument. These are supplied to the java app in the order in which they appear in the file. Arguments which appear here precede any supplied as additional arguments on the JStart command line.
• Anything else is assumed to be a VM option, and will be passed through to the VM. The format for these is as specified for the ordinary Java loader program; e.g. -Dname=value for properties, -Xstring for VM-specific extensions etc.