Path.of(uri) returns an empty string for union filesystem URIs, breaking IEnvironment MODLIST file information

[Barteks2x]

Due to this issue, it's impossible to get the file path of a mod from IEnvironment MODLIST, as it always returns an empty string. Path.of(uri) is used in ServiceLoaderUtils.fileNameFor()

[marchermans]

This should be fixed by: #26 triaging as such on that PR.

[Barteks2x]

Is there otherwise a good workarund for actually getting the path in 1.18.x?

[LexManos]

The core issue is that it is NOT returning an 'empty string' it is returning a Path object with a toString of "", as does a ZipPath for the root of a zip file. So it all depends on exactly what you're trying to use the 'string' version for.

[Barteks2x]

It's IEnvironment.Keys.MODLIST that has a toSstring version of it, and there is not much i can do about it. I would be perfectly fine with it being a Path instance.

[LexManos]

Okay, i have no idea what cpw's intention for that "file" entry ever was.
Just having the filename is not useful in the slightest. For normal paths you'd get "lwjgl-1.2.3.4.jar".. where is that located?
I propose either:
A) Changing ServiceLoaderUtils.fileNameFor to do uri -> uri.toString().split("!/")[0]) instead of uri -> Path.of(uri).getFileName().toString()
Or
B) Adding a new 'uri' entry to MODLIST that is just uri.toString()
That would solve your usecase without the breaking changes nessasary in the other PR.

My main concern is actually understanding your useecase.
What EXACTLY are you doing and WHY?
Code, Explanations, You know the drill Barteks, you've been around long enough.

[Barteks2x]

I didn't have the time and motivation to actually write down a proper response here (a job sucking out all my energy and time).

I've been using this in my already very hacky tool that allows loading optifine in dev environment to actually get the location of optifine jar. I already have a hacky workaround that works and since it won't be fixed in one version, the hack will have to stay anyway so getting this fixed won't change much for me.

I reported it mostly because I saw it being broken when it's clearly what wasn't intended.

[cpw]

Fixed in modlauncher - where the problem really was. The behaviour of Paths is fine.