Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Workbench restart incorrectly handles workspace paths containing spaces

Abierto
#4,273 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
56/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
java
Área
desktop

Línea de trabajo

Start by reading Workbench#restart(boolean useCurrentWorkspace) and compare how it builds the -data argument with Workbench#setRestartArguments(String workspacePath), as described in the issue. Reproduce by restarting with a workspace path containing a space, then check the restart arguments and workspace-selection behavior. Done when restart retains the current workspace for paths containing spaces; the issue does not name a test or file.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug

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

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.
Lenguaje dominante
Java
Estrellas
124
Forks
269
Merge medio
1 d 19 h
PR fusionados (30 d)
63

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de eclipse-platform/eclipse.platform.ui

Todos los issues de eclipse-platform/eclipse.platform.ui

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.