Use of getCanonicalPath in JDT Batch compiler

[guw]

Greetings JDT team,

Is there some history why the batch compiler uses getCanonicalPath in its implementation?
https://github.com/search?q=repo%3Aeclipse-jdt%2Feclipse.jdt.core%20getCanonicalPath&type=code

I'm using the compiler in Bazel, which executed compilation in a sandbox. This use of getCanonicalPath causes the path names to be resolved within the sandbox. As a result, the errors reported by JDT are reported for the sandbox file name. In this case the IDEs are not capable of translating this back to the file within the project (IDEs don't know about the sandbox either). I checked javac and it does not use getCanonicalPath.

Thanks!

[iloveeclipse]

Git blame helps :-)

Note, your query includes much more matches as actually used by compiler.

Only matches in org.eclipse.jdt.core.compiler.batch are relevant.

• ClasspathDirectory, ClasspathJar, ClasspathJep247, ClasspathJrt want unique entries so we don't have duplicates. But I assume you don't have problems with this code, as you probably want "fix" resolving source code errors/warnings, not dependencies.
• Therefore the relevant rest should be in FileSystem, Main, EclipseCompilerImpl, EclipseFileManager:
• https://bugs.eclipse.org/bugs/show_bug.cgi?id=285466, commits e88e1c1 and 9280ea3
• https://bugs.eclipse.org/bugs/show_bug.cgi?id=220928 commit 3e46d27
• https://bugs.eclipse.org/bugs/show_bug.cgi?id=568333 commit f0f1b91
• https://bugs.eclipse.org/bugs/show_bug.cgi?id=533043 commit 9b1349b
• https://bugs.eclipse.org/bugs/show_bug.cgi?id=477291 commit c798229

You could check if you could replace matches with something like File.getAbsoluteFile().toPath().normalize() (or any better alternative that doesn't resolve links but removes all the extra "../" and "./" parts from paths) and if there will be some troubles with the (hopefully added) tests.

[guw]

Thanks a lot Andrey!

Going through the bugs makes the code look brittle. I'm afraid of touching it. I'll probably to some post processing of the compiler output to strip the sandbox paths from the reported compile output.

[guw]

@iloveeclipse Turns out ... it's not getCanonicalPath which is the problem. It's getAbsolutePath. The reason is that the compiler is executed from within the sandbox as working dir. getAbsolutePath resolves the given input arguments to the working dir of the process. getCanonicalPath would actually be better in my case.

salesforce/bazel-jdt-java-toolchain#14 in case you are curious.