Suppress default behaviour of IApplication exit codes 23 and 24?

[pvberkel]

The launcher documentation indicates two predefined exit codes (23-EXIT_RESTART and, 24-EXIT_RELAUNCH) the IApplication implementation can return to trigger an automatic restart of the application by the launcher. My question is if there is a way to suppress this specific handling of these exit codes and allow these exit code to be used by the application for its own purposes. A command line argument for instance?

If not, could such an argument be introduced in the next Eclipse version?

Kind regards.

[laeubi]

Maybe you should a bit more describe your use-case, e.g. what do you mean by "allow these exit code to be used by the application for its own purposes". In general an application can return an Object to the caller what can be anything.

If you want to control the exit code of your jvm you should be able to simply call System.exit(...)

[pvberkel]

Dear Mr Läubrich,

Thank u for your reply. I will try to give a more extensive description of our use-case without getting lost in the details.

The use-case is a set of applications which can be run as part of the Eclipse Workbench but also as stand-alone application using the Eclipse launcher and even as a java application. The arguments to the application determine how it is executed. For example, without user interactions or GUI.

When an application is executed in stand-alone mode, using the Eclipse launcher, or as a standard java application, the exit code is used by, for instance, scripting to determine what the application did. This is done using the normal Integer exit code.

When executing as a standard Java application the application indeed uses System.exit(…) to exit the application. However, when running inside the Eclipse Laucher we would like to exit via a normal return to the launcher. This because calling System.exit(…) terminates the JVM resulting in a “JVM terminated message”. We already use the command-line argument --launcher.suppressErrors to prevent this dialog from halting the application (waiting for the user to close it) preventing any progress of our automation. This does however not prevent the message from being printed to the terminal. This is the reason we would like to use the normal return to the Eclipse launcher passing any exit-code the application returns not having to filter out the exit codes 23 and 24 to which the Eclipse launcher assigns special meaning.

Kind regards.

[dhendriks]

Some extra information. In the Eclipse ESCET project, the issue we have is in our use of the Eclipse Equinox IApplication interface. When from the start method we return the exit code of the application, this works as expected for most exit codes. However, if we return exit code 23 or 24, we trigger the documented behavior:

	/**
	 * Starts this application with the given context and returns a result.  The content of 
	 * the context is unchecked and should conform to the expectations of the application being 
	 * invoked.  This method can return the value {@link IApplicationContext#EXIT_ASYNC_RESULT} if 
	 * the application will deliver its results asynchronously with the 
	 * {@link IApplicationContext#setResult(Object, IApplication)} method; otherwise this method must not exit 
	 * until the application is finished and is ready to exit.
	 * <p>
	 * Applications can return any object they like.  If an <code>Integer</code> is returned
	 * it is treated as the program exit code if Eclipse is exiting.
	 * </p>
	 * <p>
	 * Note: This method is called by the platform; it is not intended
	 * to be called directly by clients.
	 * </p>
	 * @return the return value of the application
	 * @see #EXIT_OK
	 * @see #EXIT_RESTART
	 * @see #EXIT_RELAUNCH
	 * @see IApplicationContext#EXIT_ASYNC_RESULT
	 * @param context the application context to pass to the application
	 * @exception Exception if there is a problem running this application.
	 */
	public Object start(IApplicationContext context) throws Exception;

	/**
	 * Exit object requesting platform restart
	 */
	public static final Integer EXIT_RESTART = Integer.valueOf(23);

	/**
	 * Exit object requesting that the command passed back be executed.  Typically
	 * this is used to relaunch Eclipse with different command line arguments.  When the executable is
	 * relaunched the command line will be retrieved from the 
	 * {@link IApplicationContext#EXIT_DATA_PROPERTY eclipse.exitdata} system property.  
	 */
	public static final Integer EXIT_RELAUNCH = Integer.valueOf(24);

The handling of exit codes 23 and 24 seems to be here:

• equinox/features/org.eclipse.equinox.executable.feature/library/eclipse.c

  Line 701 in ad0953a

  case RESTART_LAST_EC:

• equinox/features/org.eclipse.equinox.executable.feature/library/eclipse.c

  Line 712 in ad0953a

  case RESTART_NEW_EC:

It probably makes sense for the Eclipse IDE to be able to restart, but if we implement our own applications based on IApplication we don't want this restart functionality. We just want the application exit code to be the exit code of the launcher.

There doesn't seem to be a way to disable the special handling of the restart exit codes. @pvberkel proposed to add a new option to the launch to disable this special handling. I think this is a good idea.

[laeubi]

For me it seems that either System.exit(...) would be the way or use negative return codes, or return codes > 24 ... should this not be enough for most use-cases?

[laeubi]

I have no concerns, but be aware that there are maybe more places that rely on that codes.

[dhendriks]

The idea would be to add an option to the launcher to disable this behavior, but keep it enabled by default. It would thus be backward compatible in all places that rely on the current behavior. But, with the new option, we could disable it for our use case.

I'm thinking of adding -norestart disables the restart behavior of exit codes 23 and 24.

[laeubi]

@dhendriks I think the best would be to propose a PR for the change so one can see the impact of the proposal, in general such option sounds like something that could be useful but I'm not expert at the launcher code.

[dhendriks]

OK, thanks. I'll try to find some time to make a PR for it. Should I create an issue from this discussion first?

[laeubi]

The PR is usually enough for documentation but you can link the discussion there of course.

[dhendriks]

Just to keep things linked together: There is now a pull request at #595.