This method is not suitable for Iceberg paths, since Java Path is for paths, but Iceberg paths are actually URIs. It mangles URIs and doesn't understand the scheme vs path distinction:

jshell> Paths.get("s3://foo/bar").toString()
$2 ==> "s3:/foo/bar"

jshell> Paths.get("s3://foo/bar/../..").normalize().toString()
$5 ==> "s3:"

jshell> Paths.get("s3://foo/bar/../../..").normalize().toString()
$6 ==> ""

URI.normalize() seems better, though it has interesting behavior where it preserves leading .. path segments at the start of the path that would go past the root:

jshell> URI.create("s3://foo/abc/../../..").normalize()
$11 ==> s3://foo/../..

Looks like using URI is still not the right way, because URI would fail with characters like space, which are supposed to be escaped with URL encoding like %20. However, it is a valid posix path.

I think what should be done is that, for path with scheme, everything after that should use Paths.get(path).normalize().toString().

This is a place where Hadoop Path behavior differs, it resolves to file:/, but that seems like an invalid resolution.

Also I am treating / as a special case, both here and in a path without a scheme. For paths with a scheme and authority, we can use scheme://authority as the root path without ambiguity. But file:// (just scheme) and (empty path) do not mean root location, only file:/// and / mean that.