JDK-8263432 : javac may report an invalid package/class clash on case insensitive filesystems
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 11,17
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-03-11
  • Updated: 2025-01-24
  • Resolved: 2021-04-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 17
11.0.13-oracleFixed 17 b20Fixed
Related Reports
Duplicate :  
Description
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.
Comments
Fix Request (11u): Yes, the external 11u project should get the fix as well. It should get backported for parity with 11.0.13-oracle. Doesn't apply cleanly. Review: https://github.com/openjdk/jdk11u-dev/pull/184
03-08-2021

[~darcy] thanks for the update!
29-07-2021

[~headius], Jan backported this change to Oracle's 11.0.13. The external 11u project may choose to apply the fix as well. HTH
29-07-2021

Is there any workaround possible on JDKs earlier than Java 17? In order to finish the modularization of JRuby, we need a way to compile without changing these packages/classes and 17 is not even released yet.
18-05-2021

Changeset: 0a4c3382 Author: Jan Lahoda <jlahoda@openjdk.org> Date: 2021-04-27 08:55:59 +0000 URL: https://git.openjdk.java.net/jdk/commit/0a4c3382
27-04-2021