The Eclipse launchers have been rewritten for 3.3 M5. This page describes the new layout of the launcher and startup code.
See the Equinox Launcher Plan page for the initial proposal for this work.
The launcher executable, eclipse.exe, has been broken into 2 pieces: the executable, and a shared library (eg: eclipse_1006.dll). The executable lives in the root of the eclipse install. The shared library is in a platform specific fragment, org.eclise.equinox.launcher.[config], in the plugins directory.
Moving the majority of the launcher code into a shared library that lives in a fragment means that that portion of the launch code can now be updated from an update site. Also, when starting from java, the shared library can be loaded via JNI in order to display the splash screen.
There is no longer a startup.jar in the root of eclipse. This code has been moved to a plugin org.eclipse.equinox.launcher in the plugins directory. Eclipse can still be started directly with java using, for example:
java -jar plugins/org.eclipse.equinox.launcher_1.0.0.v20070208a.jar
It is also possible to copy to copy this bundle into the root and name it startup.jar. In this case it would be possible to start with java -jar startup.jar.
Finding a VM, Using JNI Invocation or Executing Java
It turns out that writing a JNI launcher for multiple vms on multiple platforms is easier said than done. JNI launching does not currently work on all platforms for all vms. Because of this, the launcher can start the Java Virtual Machine either in process through the JNI Invocation API, or in a seperate process by execing the java launcher. Which method is used depends on how the vm was found.
On most platforms, we use JNI launching unless a -vm argument was given that points directly to a java executable.
More specifically, a virtual machine and launch method is chosen as follows:
No -vm specified
When no -vm is specified, the launcher looks for a virtual machine first in a jre directory in the root of eclipse and then on the search path. If java is found in either location, then we look for a jvm shared library (jvm.dll on window, libjvm.so on *nix platforms) relative to that java executable.
- If a jvm shared library is found we load it and use the JNI invocation api to start the vm.
- If no jvm shared library is found, we exec the java launcher to start the vm in a new process.
-vm specified on command line or in eclipse.ini
Eclipse can be started with "-vm <location>" to indicate a virtual machine to use. There are several possibilities for the value of <location>:
- java.exe/javaw.exe: <location> is a path to a java launcher. We exec that java launcher to start the vm in a new process.
- jvm.dll or libjvm.so: <location> is a path to a jvm shared library. We attempt to load that library and use the JNI Invocation API to start the vm in the current process.
- directory: <location> is a directory. We look in that directory for a java launcher or the jvm shared library. If we find the jvm shared library, we use JNI invocation. If we find a launcher, we attempt to find a jvm library in known locations relative to the launcher. If we find one, we use JNI invocation. If no jvm library is found, we exec java in a new process.
- gtk.linux.ppc, gtk.linux.x86_64, and motif.aix.ppc: Getting JNI to work on these platforms has been problematic for older vms. For these platforms, we exec java unless the -vm argument directly specifies a jvm shared library. Or, if the -vm argument specifies a directory in which no java executable was found but a jvm shared library was found.
- MacOSX: On the mac we are always launching via the JNI invocation API. We use "/System/Library/Frameworks/JavaVM.framework/Versions/Current/JavaVM" as the jvm library. When a -vm argument is given, we parse it for the version of java to specify to JavaVM.
Command line arguments
There are several new arguments that can be specified to the eclipse launcher:
- -library <path/to/eclipse shared lib>. This indicates the path to the eclipse shared library to use. By default, the launcher looks in the plugins directory for the matching org.eclipse.equinox.launcher.[config] fragment with the highest version. The shared library is found in that fragment.
- -startup <path/to/launcher.jar>. This indicates the path to the launcher jar. By default, the launcher looks in the plugins directory for the org.eclipse.equinox.launcher bundle with the highest version and uses it. If this bundle is not found, then the launcher will revert to old behaviour and look for startup.jar in the root.
- -showsplash <path/to/splash.bmp>. If the splash.bmp is specified to the launcher, then the splash screen can be displayed before the java vm is even started. If no splash screen is specified, then once java is started, the Main class will find the splash.bmp as before and call back to the launcher to display it.
- -suppressErrors. If this is specified, then the launcher will no display a message box with errors if a problem was encountered. This allows the launcher to be used in unattended tests without blocking on an error.
The splash screen can now contain SWT widgets. For M5, the progress bar and text on the splash screen (including the build id) are done using SWT. The launcher itself only displays a static bitmap.
Getting an early splash screen
The launcher can display the splash screen before even starting the java virtual machine. This requires that 1) the vm is started using JNI invocation, and 2) the location of the splash bitmap is specified to the launcher (usually in the eclipse.ini file).
Currently to specify the location of the bitmap, the full path to the bitmap (including version of the containing plugin) is required. We hope to simplify this so that only the plugin-id is needed to find the splash bitmap, see bug 173103.