Hello OpenJDK core libraries team,
While working on malformed ZIP analysis, I noticed repeated trailing slashes in some directory entries of a JDK lib/ct.sym ZIP container. Could you please clarify whether this naming is intentional, or an incidental detail of the symbol-generation tool? In the ct.sym from a Linux runtime distribution (zulu) labelled 21.0.12_21.52.16, for example I found 20,621 ZIP entries: - 223 zero-length directory records with names such as 9/java.activation// and 9/java.base// - 2,628 ordinary single-trailing-slash directory records - 17,770 files. All 223 repeated-slash entries are at release-set/module boundaries and have a direct module-info.sig child. They cover 75 distinct module names across release sets. None of these directories is logically empty: the directory records have zero payload bytes, but all have descendants. I found no empty interior path components in the other entry names. The module-info.sig file paths themselves use a single separator. I checked CreateSymbols.java in both the OpenJDK 21 updates repository and current mainline. The source appears to explain this pattern: writeModule passes a module-info.sig filename without a slash to doWrite; doWrite uses "/" for the package portion of a filename without a slash, then appends that to a directory prefix which already ends in "/". The resulting directory-map key therefore ends in "//", while the corresponding file path does not. The directory keys are subsequently written as ZIP entries. Sources inspected: OpenJDK 21 updates https://github.com/openjdk/jdk21u/blob/bb6b279495ceff8442dbd0225756b92d466d5309/make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java#L888-L903 Current mainline https://github.com/openjdk/jdk/blob/573661580c57c9d286b36563621acfd991d97a99/make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java#L857-L867 I did not find an explanatory comment at these locations establishing whether the extra slash is deliberate. I have not built OpenJDK to independently reproduce the generated archive. The matching construction in both upstream source trees is why I am asking here rather than assuming this is specific to the distributor. No failure in javac or in OpenJDK's own ZIP readers is being reported. Is the repeated trailing slash intentional or relied upon by any ct.sym consumer? Gruss Bernd
