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

Chen Liang liach at openjdk.org
Sat Apr 19 01:58:54 UTC 2025


On Thu, 17 Apr 2025 20:51:10 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:
> 
>   Review remarks

Unfortunately, I don't think there is a convenient way to make a jar  with jtreg tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/24604#issuecomment-2816458196


More information about the core-libs-dev mailing list