ECJ throws false-positive "Package collides with type" on Windows (case-insensitive compiler) #985
Labels
good first issue
Good for newcomers
Comments
|
Here is a small self-contained example reproducing the issue: |
12 tasks
jjohannes
added a commit
to jjohannes/gradle
that referenced
this issue
Jun 5, 2023
...by forwarding all methods to the wrapped file manager. This gives it more robustness when running with custom compiler and file manager implementation. In particular, it avoids hitting the following issue with the Eclipse compiler: eclipse-jdt/eclipse.jdt.core#985 Signed-off-by: Jendrik Johannes <[email protected]>
jjohannes
added a commit
to jjohannes/gradle
that referenced
this issue
Jul 5, 2023
...by forwarding all methods to the wrapped file manager. This gives it more robustness when running with custom compiler and file manager implementation. In particular, it avoids hitting the following issue with the Eclipse compiler: eclipse-jdt/eclipse.jdt.core#985 Signed-off-by: Jendrik Johannes <[email protected]>
jjohannes
added a commit
to jjohannes/gradle
that referenced
this issue
Jul 6, 2023
...by forwarding all methods to the wrapped file manager. This gives it more robustness when running with custom compiler and file manager implementation. In particular, it avoids hitting the following issue with the Eclipse compiler: eclipse-jdt/eclipse.jdt.core#985 Signed-off-by: Jendrik Johannes <[email protected]>
jjohannes
added a commit
to jjohannes/gradle
that referenced
this issue
Jul 10, 2023
...by forwarding all methods to the wrapped file manager. This gives it more robustness when running with custom compiler and file manager implementation. In particular, it avoids hitting the following issue with the Eclipse compiler: eclipse-jdt/eclipse.jdt.core#985 Signed-off-by: Jendrik Johannes <[email protected]>
jjohannes
added a commit
to jjohannes/gradle
that referenced
this issue
Aug 3, 2023
...by forwarding all methods to the wrapped file manager. This gives it more robustness when running with custom compiler and file manager implementation. In particular, it avoids hitting the following issue with the Eclipse compiler: eclipse-jdt/eclipse.jdt.core#985 Signed-off-by: Jendrik Johannes <[email protected]>
jjohannes
added a commit
to jjohannes/gradle
that referenced
this issue
Sep 19, 2023
...by forwarding all methods to the wrapped file manager. This gives it more robustness when running with custom compiler and file manager implementation. In particular, it avoids hitting the following issue with the Eclipse compiler: eclipse-jdt/eclipse.jdt.core#985 Signed-off-by: Jendrik Johannes <[email protected]>
jjohannes
added a commit
to jjohannes/gradle
that referenced
this issue
Sep 19, 2023
...by forwarding all methods to the wrapped file manager. This gives it more robustness when running with custom compiler and file manager implementation. In particular, it avoids hitting the following issue with the Eclipse compiler: eclipse-jdt/eclipse.jdt.core#985 Signed-off-by: Jendrik Johannes <[email protected]>
jjohannes
added a commit
to jjohannes/gradle
that referenced
this issue
Oct 9, 2023
...by forwarding all methods to the wrapped file manager. This gives it more robustness when running with custom compiler and file manager implementation. In particular, it avoids hitting the following issue with the Eclipse compiler: eclipse-jdt/eclipse.jdt.core#985 Signed-off-by: Jendrik Johannes <[email protected]>
jjohannes
added a commit
to jjohannes/gradle
that referenced
this issue
Oct 31, 2023
...by forwarding all methods to the wrapped file manager. This gives it more robustness when running with custom compiler and file manager implementation. In particular, it avoids hitting the following issue with the Eclipse compiler: eclipse-jdt/eclipse.jdt.core#985 Signed-off-by: Jendrik Johannes <[email protected]>
jjohannes
added a commit
to jjohannes/gradle
that referenced
this issue
Apr 3, 2024
...by forwarding all methods to the wrapped file manager. This gives it more robustness when running with custom compiler and file manager implementation. In particular, it avoids hitting the following issue with the Eclipse compiler: eclipse-jdt/eclipse.jdt.core#985 Signed-off-by: Jendrik Johannes <[email protected]>
nettozahler
added a commit
to nettozahler/eclipse.jdt.core
that referenced
this issue
Oct 7, 2024
3 tasks
nettozahler
added a commit
to nettozahler/eclipse.jdt.core
that referenced
this issue
Oct 10, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When compiling two projects I'm getting false-positive error messages:
The package com.bla.x collides with a typeSuppose I have a package "com.foo" containing a class "Test.java" in project A. Project B contains a package "com.foo.test" and references project A.
If the compiler is passed an instance of "javax.tools.ForwardingJavaFileManager" it will throw the following error on compilation of "B":
The package com.foo.test collides with a typeThis is because "EclipseFileManager" uses "java.io.File.exists()" to check if a package already exists. This check however is case-insensitive on Windows so it collides with the type "com.foo.Test.java" which is a false-positive.
BTW: When passing an instance of "EclipseFileManager" instead of "javax.tools.ForwardingJavaFileManager" the code will compile fine. This is because EclipseCompiler contains several "instanceof StandardJavaFileManager" checks.
The text was updated successfully, but these errors were encountered: