Unable to launch Eclipse launch config if name contains spaces

[iloveeclipse]

Regression in 4.35 via #1565.

1. Create new launch configuration to start Eclipse (default name New_configuration)
2. Try to start Eclipse - works.
3. Duplicate launch config to get a name New_configuration (1) (note the space)
4. Try to Start Eclipse - fails with error

An error has occurred.  See the log file
/data/runtime-Java_21/.metadata/.plugins/org.eclipse.pde.core/New_configuration%20(1)/1740652776602.log

Log file contains this:

ESSION Thu Feb 27 11:39:36 CET 2025 ------------------------------------------
!ENTRY org.eclipse.equinox.launcher 4 0 2025-02-27 11:39:36.619
!MESSAGE Exception launching the Eclipse Platform:
!STACK
java.io.FileNotFoundException: Could not find framework under /data/git/equinox/bundles/org.eclipse.equinox.launcher/bin/plugins
        at org.eclipse.equinox.launcher.Main.getBootPath(Main.java:990)
        at org.eclipse.equinox.launcher.Main.basicRun(Main.java:585)
        at org.eclipse.equinox.launcher.Main.run(Main.java:1481)
        at org.eclipse.equinox.launcher.Main.main(Main.java:1454)

Reverting e62be0b fixes the launch.

[iloveeclipse]

Note, the encoding of the -dev attribute was broken before and not fixed by reverting e62be0b. I'm looking at commit that broke this, looks like this one: 04785c9

[akurtakov]

I'm looking into it. Reverting a series of commits is not what I aim at .

[iloveeclipse]

I'm looking into it. Reverting a series of commits is not what I aim at .

It is one commit + one change from other commit. Should be safe.

[iloveeclipse]

See #1631.

[akurtakov]

@iloveeclipse I am unable to reproduce the problem on Linux . Do you see it on windows?

[merks]

FYI, I see a problem here where the launcher simply doesn't decode a properly encoded URI:

[iloveeclipse]

@iloveeclipse I am unable to reproduce the problem on Linux . Do you see it on windows?

Linux

[iloveeclipse]

Note, PDE creates two directories with different names but deletes only one. To reproduce, one has manually delete all existing directories.

[iloveeclipse]

FYI, I see a problem here where the launcher simply doesn't decode a properly encoded URI:

I'm not sure this is the place to fix, because launcher cant know whether /data/runtime-Java_21/.metadata/.plugins/org.eclipse.pde.core/New_configuration%20(1)/ or /data/runtime-Java_21/.metadata/.plugins/org.eclipse.pde.core/New_configuration (1)/ is the "right" path - both are possible and valid values.

I believe the problem is in PDE where the paths entered in the UI and paths passed to the launcher differ.

[merks]

It's really quite the disaster area. The launcher main is so terrible with all the confusion and hacks around things that are URLs or maybe they are file paths, or maybe goodness knows maybe both, neither, some abomination in between that is not even a valid URI this is kind of a semi-bogus URL.

I found that this fixes the problem as far as I've been able to reproduce it.

[iloveeclipse]

I found that this fixes the problem as far as I've been able to reproduce it.

I can confirm the PR with the fix above fixes this issue.

[iloveeclipse]

Thanks Ed.

[laeubi]

By the way is there any chance to add a regression test so we notice such thing earlier and don't need manual testing?

[merks]

By the way is there any chance to add a regression test so we notice such thing earlier and don't need manual testing?

What's the standard answer to that type of question? 😬

In any case, that code, I'm sorry to say, is kind of a disaster area.

Unless all places create properly encoded URIs in the first places and all places converting those to file system paths decode those properly I think it will never work 100% correctly, e.g., don't try this at home boys and girls:

When I see a lot of file:D:/..., file:D:\..., and file:/D:/... then I know the problem of encoding correctly is pervasive which means all bets are off for proper decoding because the code is rife with hacks that deal with the not-properly-encoded case(s) so much so that the properly-encoded case didn't actually work.

So not only do there need to be tests, there needs to be significant rework to stamp out the sources of bad data...

[laeubi]

I think a test that uses a space in the path would be a very first step.