Workbench restart incorrectly handles workspace paths containing spaces

[AdarshKulkarni54]

Let's make sure issue is not already fixed in latest builds first.

• I verified I can reproduce this issue against latest Integration Build of Eclipse SDK

Steps to reproduce

From a fresh installation and clean workspace and configuration area:

• Start the application with a workspace whose path contains a space, for example:
  ~/eclipse-workspaces/My Workspace
• Restart the application

I tried

• Restarting the application with a workspace path containing a space - the workspace selection dialog is shown again.

I expected: the application to restart using the current workspace without showing the workspace selection dialog again.

But got: The Choose a workspace dialog is displayed again after restart when the workspace path contains a space.

Root Cause (so far analysis from my end)

The issue appears to be caused by the different ways in which the -data argument is constructed during restart and workspace switching.
When restarting, Workbench#restart(boolean useCurrentWorkspace) tries to construct the restart arguments using the current instance location. During this process, the instance location URL is converted to a URI.

When the workspace path contains a space, for example:

/path/to/My Workspace

the URL-to-URI conversion results in a URISyntaxException.

Consequently, the -data argument is not correctly added to the restart arguments, which causes the application to start without the expected workspace information and display the Choose a workspace dialog again.

Interestingly, switching workspace follows a different code path.

When switching workspaces, Workbench#setRestartArguments(String workspacePath) is called internally. This method does not perform the same URL-to-URI conversion and sets the -data argument using the workspace path directly. Therefore, workspace paths containing spaces are handled correctly in that case.
In other words, there are currently two different approaches for setting the -data argument:

• Restart: uses the instance location URL and converts it to a URI.
• Switch workspace: uses Workbench#setRestartArguments(String workspacePath) and sets the workspace path directly.

This difference appears to be the reason why switching workspaces works correctly while restarting fails for workspace paths containing spaces.

I have only reproduced this with spaces so far. It is possible that other special characters in the workspace path may cause the same issue, but I have not tested those cases yet.

Impact on Eclipse RCP applications

This is particularly problematic for Eclipse RCP applications that use a custom IApplication implementation and do not provide a workspace selection dialog to users, as there may be no opportunity for the user to manually select the workspace again after the restart.

Our application has custom logic to set the instance location when it is not already set, which currently works around the problem.

However, this may still cause issues for RCP applications that rely on the -data argument to establish the instance location. For example, persisted instance-scope preferences may not be read from the expected location if the instance location is not correctly set.

This does not appear to be as noticeable when using the Eclipse IDE itself, but it can affect Eclipse RCP applications with custom application startup logic.

Questions

Is this a known issue, or is the current behavior intentional?
In particular, I would like to understand why restart and workspace switching use two different approaches to construct the -data argument.

Should Workbench#restart(boolean useCurrentWorkspace) use the same path-handling mechanism as Workbench#setRestartArguments(String workspacePath) so that workspace paths containing spaces and other valid special characters are handled consistently?

Tested under this environment:

• OS & version: Windows 11
• Eclipse IDE
  • Version: 2026-06 (4.40.0)
  • Build id: 20260604-0653

Community

• I understand reporting an issue to this OSS project does not mandate anyone to fix it. Other contributors may consider the issue, or not, at their own convenience. The most efficient way to get it fixed is that I fix it myself and contribute it back as a good quality patch to the project.