On Wed, 4 Mar 2026 19:38:52 GMT, Chen Liang <[email protected]> wrote:
>> ## Summary >> >> Follow-up to [JDK-8341608](https://bugs.openjdk.org/browse/JDK-8341608), >> which addressed `ClassFileError` propagation in jdeps but did not fix the >> underlying signature parsing. >> >> `SignaturesImpl.classTypeSig()` throws `IllegalArgumentException` when >> parsing a class type signature that contains an empty identifier after the >> inner class separator `.`. >> >> ## Problem >> >> The Scala compiler emits class type signatures such as: >> >> >> Lcoursierapi/shaded/scala/collection/immutable/TreeMap$TreeMapBuilder<TK;TV;>.; >> >> Here the `.` after the type arguments is followed directly by `;` with no >> inner class name. While this violates JVMS §4.7.9.1 (which requires an >> identifier after `.`), such signatures exist widely in published Scala >> artifacts on Maven Central and cannot be recompiled. >> >> Running `jdeps` against JARs containing these signatures crashes with: >> >> Exception in thread "main" >> com.sun.tools.jdeps.Dependencies$ClassFileError >> Caused by: java.lang.IllegalArgumentException: >> Unexpected character ; at position 78, expected an identifier >> >> ## Fix >> >> In `classTypeSig()`, the identifier after `.` is now optional when an outer >> type is already present. On the first iteration (no outer type), an >> identifier is still strictly required. >> >> ## Test >> >> Added `LOuter<TK;TV;>.;` to `goodTypeSignatures` in `SignaturesTest`. > > Please follow the https://openjdk.org/guide "Requesting a Change" section: > >> If you want to request a change to the JDK, but don’t have the intention to >> implement/contribute to the change yourself, you should always report it at >> [bugreport.java.com](https://bugreport.java.com/). > >> Before you file an issue, make sure you have read [Things to consider before >> proposing changes to OpenJDK >> code](https://openjdk.org/guide/#things-to-consider-before-proposing-changes-to-openjdk-code) >> and [Why is my change >> rejected?](https://openjdk.org/guide/#why-is-my-change-rejected) below. @liach Sorry about this — please disregard this PR for now. I wasn't familiar with the contribution process and jumped ahead by opening a PR directly. I'll read through the guide and come back through the proper channels. That said, I'd like to describe the issue I'm seeing. JDK-8341608 added ClassFileError handling in ClassFileReader.forEachClassFile(), but DependencyFinder.parse(Archive, Finder, String) — used by DepsAnalyzer.transitiveDeps() — lacks the same protection. When jdeps encounters a malformed class file during transitive dependency analysis (e.g. `jdeps --print-module-deps -cp "lib/*" app.jar`), it crashes with an uncaught ClassFileError instead of skipping it gracefully. ------------- PR Comment: https://git.openjdk.org/jdk/pull/30041#issuecomment-4001338013
