Bug ID: JDK-6211008 Direct execution of JAR files on Linux

Type: Enhancement
Component: deploy
Sub-Component: deployment_toolkit
Affected Version: 6

Priority: P3
Status: Resolved
Resolution: Fixed
OS: windows_xp
CPU: x86

Submitted: 2004-12-21
Updated: 2017-05-16
Resolved: 2005-06-22

JDK 6
6 b42Fixed

On Solaris and Windows a jar file may be directly executed.

On Solaris, this is because the kernel exec mechanism can recognize a jar file by various magic numbers and the like.  Hence, the name of the file can be anything; it just needs to be marked executable.

On Windows, this is accomplished by the typical .3 suffix binding mechanism. ".jar" is bound to the default jvm.  Hence, the name must end in ".jar", but this isn't an issue on Windows.

The Linux kernel should behave like Solaris and recongnize a jar file and exec the  appropriate JVM.  Even the most casual observer should note that this requires a change to the Linux kernel, and that's what makes it hard: we need to engage Linus and make this happen.  Based on the Solaris experience, the implementation is fairly trivial - about 100 lines of fairly well isolated code. The effort is getting permission to integrate it.

Note, that without implementing the "default java on Linux" project, this doesn't have a chance.  The Linux community would not accept an implementation which forced a Sun JVM.  (Just explicity calling out the dependency.)

###@###.### 2004-12-21 04:10:36 GMT

SUGGESTED FIX A webrev and engineering testcases can be found at: webrev: http://j2se.east/deployment/www/webrevs/mr144506/1.6.0/6211008/ testcase: http://j2se.east/deployment/www/tests/1.6.0/6211008/testcase.txt ###@###.### 2005-05-27 20:30:45 GMT

27-05-2005

EVALUATION This feature will only be installed when Java is installed on Linux using the RPM packages. It will not be available when Java is installed from a tarball, or the self-extracting installer. This feature will take advantage of the binfmt_misc capabilities that are integrated in the Linux kernel since version 2.4.13. binfmt_misc registers an interpreter with a particular file extension or magic number. More information on binfmt_misc is available on the website: http://www.tat.physik.uni-tuebingen.de/~rguenth/linux/binfmt_misc.html Java RPM packages will add the file /etc/init.d/jexec during the installation. Linux is similar to any System V Unix in that it uses links under the various rc[0-6].d directories to start and stop a service during system initialization. Unfortunately, no two Linux distributions seem to be quite alike in the final implementation of this. However, most distributions offer one or more tools to help in the installation of init scripts and the creation of the run level links. The Java RPM packages will initially support the Red Hat, and Linux Standards Base (LSB) tools for installing and removing init scripts. Documentation from the web, and inspection of several lab systems shows the Red Hat tools are used on all version of Red Hat since at least RHEL AS 2.1, Fedora, and Debian. The LSB tools are used for all UnitedLinux/SuSE derived distributions, including the Java Desktop System (JDS). Each tool set basically works in the same way. Once an init script is dropped into /etc/init, the tool is invoked, which uses special comments in the init script to create the appropriate run level links, automatically assigning an appropriate S[0-9][0-9] or K[0-9][0-9] prefix. During uninstall, another tool is used to remove these links. The Java RPM packages will never create any of these links directly. The Java RPM packages will include an init script that contains the necessary comments to support both the LSB and Red Hat tools. The script will contain logic to start/stop the binfmt_misc service, and register the interpreter for the JAR binary type. The package's post-install scriptlet will contain logic to determine which if any tool set is available. If the LSB or Red Hat tool set is detected, it will be invoked, installing the proper run level links, and then the init script itself is started. If neither tool sets is detected, the init script will not be registered. By default, the Java RPM packages will register the jexec to start in run levels 1, 2, 3, 4, and 5. (These are all the interactive run levels on Linux.) Once registered, most, if not all Linux distributions provide CLI and GUI tools that allow a privileged user to change what run levels a service is started or stopped in. Note: Unlike Solaris, it is necessary under Linux to register a start link for a run level, even when a previous run level has already started the service. For example, on Solaris an entry in rc2.d would imply the service also is started in run level 3. However, Linux requires entries in both. The /etc/init.d/jexec file will handle the start and stop commands. The start command will initialize the binfmt_misc virtual file system, and register the interpreter for the JAR binary type. Initialization of binfmt_misc occurs as follows: 1) if the file /proc/sys/fs/binfmt_misc/register already exists, then initialization is complete 2) if the directory /proc/sys/fs/binfmt_misc does not exist, then binfmt_misc is not supported on the system, initialization is complete, and there is nothing to register 3) mount binfmt_misc to /proc, as in: mount -t binfmt_misc none /proc/sys/fs/binfmt_misc 4) if the file /proc/sys/fs/binfmt_misc/register does not exist, then binfmt_misc initialization failed, and there is nothing to register Registration of the JAR binary interpreter occurs as follows: 1) if the file /proc/sys/fs/binfmt_misc/jexec already exists, then something has already been registered in the namespace 2) with the exception of the files 'register' and 'status', ensure each file in /proc/sys/fs/binfmt_misc does not contain the PK-Zip magic number; if any file already contains this number, something has already been registered 3) register the jexec interpreter for the PK-Zip magic number using the following command: echo ':jarexec:M::PK\x03\x04::/usr/java/default/lib/jexec:' \ > /proc/sys/fs/binfmt_misc/register The jexec program is a simple launcher. It's main purpose is the verify that the PK-ZIP file detected by binfmt_misc is actually a JAR file. This is necessary because binfmt_misc is limited to detecting a files magic number in a static location within the first 127 bytes of the file. Unfortunately the location of the JAR magic number is not static, or even garunteed to be in the first 127 bytes of the file. The Jar magic number is stored in one of the members of extra field data list in the local file header of the first file. ###@###.### 2005-05-27 20:30:45 GMT

27-05-2005