Difference between revisions of "Equinox Startup Issues"
(→Eclipse.exe does not propagate exit code)
|Line 67:||Line 67:|
Revision as of 11:22, 26 June 2007
- 1 Overview
- 2 Background
- 3 Problem: Startup.jar
- 4 Possible Solutions
- 5 Other Issues
- 6 Links
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.
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)
Clients with scripts which started Eclipse directly from Java (
java -jar startup.jar) must now be altered to point to the new JAR location.
It is still completely possible to start eclipse using
java -jar <launcher>. The only change is that
<launcher> is no longer called startup.jar and it is no longer in the root. No longer being in the root is not a significant issue. The problem is that the name now contains a version number which could change if the eclipse install is updated.
The story going forward would be that people who wish to start with 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 (this is equivalent to the rename without version number).
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.
The following is more information on the issues above.
- The thin startup.jar will be the only thing on the app classpath assuming it is launched with a simple "java -jar startup.jar" command. This means anyone accessing the system classloader (ClassLoader.getSystemClassLoader) will no longer get a classloader that contains the classes from org.eclipse.equinox.launcher. The osgi.parentClassloader sets the parent of the StartupClassLoader and the parent classloader that is used for all bundle classloaders. Currently the values supported are "fwk", "app", "ext" and "boot". The value "boot" is the default. If the value of "app" is used then the parent classloader will only be able to access the content in the thin startup.jar. Clearly this is a corner case, we should never encourage the use of the application classloader for anything inside eclipse anyway.
- There are a few things to consider for security. The thin startup.jar should do all of its work before calling the Main class in org.eclipse.equinox.launcher. The equinox launcher Main class may setup a security manager. If a class from the thin startup.jar attempts to perform a priviledged operation then it may get a security exception. The thin startup.jar should also use a simple URLClassLoader that is not extended by a class in the thin startup.jar. This ensures that the classloader used to load the equinox launcher always has AllPermission because URLClassLoader is from the boot classpath.
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 [RESOLVED]
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:
- Create a console launcher that does not depend on a WS: bug 173962
- 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.
- Equinox Launcher
- Equinox Launcher Plan
- Splash Screen Improvements
- Bug 173742: Please reinstate a unified way to launch using Java
- Bug 154088: [Workbench] [IDE] Improve the launching experience
- Bug 172685: [Launcher] need option to suppress error dialogs
- Bug 173962: [launcher] create a console friendly eclipse.exe
- bug 173900: [Launcher] Launcher should propagate java return code