-
Bug
-
Resolution: Fixed
-
P3
-
11, 17
-
b20
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8269801 | 11.0.13-oracle | Jan Lahoda | P3 | Resolved | Fixed | b02 |
JDK-8271929 | 11.0.13 | Martin Doerr | P3 | Resolved | Fixed | b02 |
Based on:
https://twitter.com/headius/status/1369375537756536834
javac may report a non-existing package/class clash on case insensitive filesystems. Please see the attached diff showing a testcase.
The internal cause is roughly as follows. To implement the package/class clash check as per JLS 7.1, javac creates "phantom" packages with the same names as the classes and checks if these packages exist (this is not completely correct, as it checks if javac has seen any files inside the given directory before, but does not itself list the directory). Overall, javac was prepared for the phantom packages, so things were mostly working. But, for modules, an extension happened: every package created (phantom or not) gets registered to its enclosing ModuleSymbol, and when ModuleSymbol.getEnclosedElements() is called, the package is completed (i.e. its directory is listed) and if it contains any class, it is returned. The order of events, per my understanding so far, is this: the phantom package for the org.jruby.runtime.CallSite package is created, the package/class clash check is performed and passes. Then annotation processing calls ModuleSymbol.getEnclosedElements(), the phantom package is listed from the filesystem, and contains some source files, so appears non-empty/existing (due to the case insensitive filesystem, a different directory is listed in fact). Then another round of annotation processing happens, and the package/class clash check is performed again. This time, the package appears to exist, and hence the check fails.
https://twitter.com/headius/status/1369375537756536834
javac may report a non-existing package/class clash on case insensitive filesystems. Please see the attached diff showing a testcase.
The internal cause is roughly as follows. To implement the package/class clash check as per JLS 7.1, javac creates "phantom" packages with the same names as the classes and checks if these packages exist (this is not completely correct, as it checks if javac has seen any files inside the given directory before, but does not itself list the directory). Overall, javac was prepared for the phantom packages, so things were mostly working. But, for modules, an extension happened: every package created (phantom or not) gets registered to its enclosing ModuleSymbol, and when ModuleSymbol.getEnclosedElements() is called, the package is completed (i.e. its directory is listed) and if it contains any class, it is returned. The order of events, per my understanding so far, is this: the phantom package for the org.jruby.runtime.CallSite package is created, the package/class clash check is performed and passes. Then annotation processing calls ModuleSymbol.getEnclosedElements(), the phantom package is listed from the filesystem, and contains some source files, so appears non-empty/existing (due to the case insensitive filesystem, a different directory is listed in fact). Then another round of annotation processing happens, and the package/class clash check is performed again. This time, the package appears to exist, and hence the check fails.
- backported by
-
JDK-8269801 javac may report an invalid package/class clash on case insensitive filesystems
- Resolved
-
JDK-8271929 javac may report an invalid package/class clash on case insensitive filesystems
- Resolved
- duplicates
-
JDK-8265826 [macos] javac generates a duplicate class error if a module-info.java file is present
- Closed
- links to
-
Commit openjdk/jdk11u-dev/b878e3f8
-
Commit openjdk/jdk/0a4c3382
-
Review openjdk/jdk11u-dev/184
-
Review openjdk/jdk/3069
(2 links to)