Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Equinox Startup Issues

Revision as of 14:00, 13 February 2007 by Aniefer.gmail.com (Talk | contribs) (Create a new startup.jar)

Overview

As per bug 173742, some users are having issues when surrounding the move of the startup.jar from the root of the Eclipse install to the plugins/ directory. The purpose of this page is to outline the reasons for the move, the problems that people are having, and proposed solutions to these problems.

Background

One of the major downfalls of the Eclipse Update story is that it is not completely updateable; users are not able to use update manager to update between major releases. This was because the startup.jar was not a real bundle and not versioned. By moving the startup.jar code to the plugins/ directory and making it a bundle, the update manager can now update this code in future releases of Eclipse.

The Equinox launchers were also designed to address the startup experience with respect to the splash screen. Bug 154088 was the plan item for this work. See also the wiki page on Splash Screen Improvements.

This work was previously outlined in Equinox Launcher and Equinox Launcher Plan as well as in messages sent to the mailing lists and outlined weekly in the Eclipse Architecture Meeting Minutes. It was first released to the Eclipse SDK builds in the first integration build after Eclipse 3.3 M4. (the integration build from December 19, 2006)

Problem: Startup.jar

Clients which scripts which started Eclipse directly from Java (java -jar startup.jar) must now be altered to point to the new JAR location.

Proposed Solutions

Bring back the old startup.jar

Revert from having a launcher bundle to having a startup.jar in the install root.

Create a new startup.jar

Write a new "thin" startup.jar which looks for the launcher bundle in the plugins/ directory and then calls it.

Issues Requiring Investigation: "Find the real launcher bundle and call it", actually means, create a new classloader containing the launcher bundle and use reflection to invoke its main method. This introduction of an extra classloader means the following issues must be considered:

  • osgi.parentClassloader. OSGi is started in a StartupClassLoader. The parent of this classloader depends on the property osgi.parentClassloader.
  • Security. The launcher jar sets up the security manager when one is used.

Both of these issues must be fully understood before creating a thin startup.jar. If either of them require handling in the thin jar, then this jar is no longer thin and becomes almost as large as the real launcher bundle. This then undoes the benefits of moving the launch code to the plugins directory and has the added drawback of duplicating code. In which case we would be better off reverting to the old way or doing nothing.

Do nothing

The story going forward would be that people who have products based on Eclipse and are starting Eclipse via Java directly would have to either modify their scripts to point to the correct launcher JAR, rename it to have a name they prefer (without version number), or copy the launcher JAR to the Eclipse install root and rename it to be startup.jar.

Other Issues

Running the launcher exe headless and unattended [RESOLVED]

The launcher exe could display a dialog and block a headless unattended application. This has been resolved with bug 172685.

Eclipse.exe does not propagate exit code

In some cases the launcher exe does not propagate the exit code from java. This is easily fixed and is tracked by bug 173900.

Running the launcher exe on a machine without a WS

The eclipse launcher will not run on a machine that does not contain the appropriate window system libraries (ie gtk, motif). This is not new and was true of the old eclipse launchers as well.

There are 2 possible solutions to this:

  1. Create a console launcher that does not depend on a WS: bug 173962
  2. Refactor the eclipse launcher to find and load the ws libraries dynamically instead of having them statically linked.

Eclipse.exe does not provide normal console stream [Windows]

On Windows, The eclipse launcher is linked as a GUI application, and hence does not get the normal console streams. This also causes us problems with the -console option. See for example bugs 167310 and 168726.

The only solution I am aware of is to link as a console application, which would be bug 173962.

On the other platforms, the console stream problem was caused by eclipse running as 2 processes (eclipse and java). This should be resolved when launching using JNI invocation to start the java vm.

Links

  1. Equinox Launcher
  2. Equinox Launcher Plan
  3. Splash Screen Improvements
  4. Bug 173742:Please reinstate a unified way to launch using Java
  5. Bug 154088:[Workbench] [IDE] Improve the launching experience
  6. Bug 172685: [Launcher] need option to suppress error dialogs
  7. Bug 173962: [launcher] create a console friendly eclipse.exe
  8. bug 173900: [Launcher] Launcher should propagate java return code

Back to the top