Why does Eclipse use a native launcher ?

Question

Eclipse the IDE is one of the best examples of a huge desktop application written in Java.

Most Java applications I've seen usually rely on a batch or shell script to build a string with the class path of the application, and launch the JVM with the class path as an env variable.

Eclipse, on the other hand, relies on a native launcher. Why is that ? What does this launcher do that scripts don't ?

I remember reading an article about a year and a half ago that explained that "we're better off with a native launcher", but id did not explain the inner workings of the launcher.

Answer 1

Some of these are windows specific some are general.

1. Your shell integration is much improved compared to a batch script in the natively available scripting language of your target platform.

2. There is no need to launch an additional process to execute the script (this can be a big deal if you are scripting the IDE itself as part of your build/test/deploy cycle.

3. The executable headers normally define the 'bitness' of your program. Thus the executable can explicitly indicate it is allows/disallows 32 or 64 bit execution.

4. Executables on windows may be cryptographically signed.

5. Many malware/firewall guard programs maintain per executable white lists. As such it is much nicer when firing up eclipse (and it checks itself for updates on the web) for the first time to be presented with the pop up "Eclipse is trying to access the internet" rather than a generic "javaw.exe is trying to access the internet". It also allows the user finer grained control over this behaviour.

6. The process will show up on ps/task manager as "you_app_name" rather than java -jar "your jar file". This makes it easier to track/manage errant processes. Something not uncommon in a development setting.

Answer 2

The Equinor launcher uses JNI to start the Java VM in the same process as the launcher. Using JNI also allows us to use SWT widgets in the splash screen.

---

Actually, you can still have a script, since the launcher executable, eclipse.exe, has been broken into 2 pieces since 3.3M5:

• 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.

As explained here, you can start Eclipse 3.3 without the native launcher,

java -jar plugins/org.eclipse.equinox.launcher_1.0.0.v20070319.jar

Note that the name of the jar-file is now version dependent causing naive scripts, that invoke the jar using the exact filename, to break once the jar-file gets updated.

Instead you may want to look for a file matching org.eclipse.equinox_*.jar. Thankfully the Eclipse-wiki contains appropriate scripting templates that are useful in this case.
If you want to avoid modifying existing scripts, you can also search for the Equinox Launcher plug-in, copy it into the Eclipse main directory and rename the copy into startup.jar.

Answer 3

The other answers have been highly technical, but in my opinion, i think its for far simpler reasons: User experience.

The end user doesn't have to fuss with anything to make it work. (Yes, you CAN fuss with it if you want to use a different VM or pass args to the vm, etc, but you don't HAVE to).

There's nothing more annyoing to a user than to install a program, then try to run it, only to get a dos box that says "enter the path to your java vm", or worse, you double click it and nothing happens because you have to go edit a batch file to make it work.

This is 2009, not 1996. No users (not even developers!) should have to edit batch files to make a program run the first time.