RFR: 8341608: jdeps in JDK 23 crashes when parsing signatures while jdeps in JDK 22 works fine [v3]

[Jaikiran Pai]

On Mon, 21 Apr 2025 14:59:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> When jdeps was migrated from old classfile to ClassFile API, the parsing semantic changed - error checks are now made lazily, and nested crashes from malformed signature or other problems is now latent, after a `ClassModel` instance is available. (The old error check existed only for constructing a `ClassModel`)
>> 
>> To address this issue, I have updated the way of iterating class files to be handler/consumer based like in the ClassFile API. This has the advantage that when one invocation of the handler fails of a `ClassFileError`, other invocations for other class files can proceed, and the exception handler has sufficient information to report a useful message indicating the source of error.
>> 
>> For the particular example of examining a proguard processed `dummy-scala.jar`, here is the new output of `jdeps dummy-scala.jar`:
>> 
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 59, expected an identifier: Lscala/collection/immutable/TreeMap$TreeMapBuilder<TA;TB;>.;: scala/collection/immutable/TreeMap$TreeMapBuilder.class (dummy-scala.jar)
>> Warning: com.sun.tools.jdeps.Dependencies$ClassFileError: Unexpected character ; at position 49, expected an identifier: Lscala/collection/parallel/mutable/ParArray<TT;>.;: scala/collection/parallel/mutable/ParArray.class (dummy-scala.jar)
>> 
>> 
>> Now, jdeps shows the bad class files. Inspection into the files reveal that proguard incorrectly deleted the simple class names with trailing `$`, for example, the original signature of the broken ParArray was `Lscala/collection/parallel/mutable/ParArray<TT;>.ParArrayIterator$;`, so the `ParArrayIterator$` part was incorrectly dropped by proguard.
>> 
>> Testing: langtools/tools/jdeps.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a test

test/langtools/tools/jdeps/MalformedClassesTest.java line 28:

> 26:  * @bug 8341608
> 27:  * @summary Tests for jdeps tool with jar files with malformed classes
> 28:  * @library lib /test/lib jdk.jdeps

I am not too familiar with the `jdk.jdeps` style usage of `@library` here. Does the test still function without that `jdk.jdeps` entry? I briefly looked up the documentation of `@library` https://openjdk.org/jtreg/tag-spec.html#tags and it isn't clear to me what jtreg does with such a declaration.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24604#discussion_r2052629495