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

Chen Liang liach at openjdk.org
Thu Apr 17 20:51:10 UTC 2025


On Thu, 17 Apr 2025 16:44:02 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review remarks
>
> src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java line 105:
> 
>> 103: 
>> 104:     protected void skipEntry(ClassFileError ex, String fileName) {
>> 105:         skippedEntries.add(String.format("%s: %s", ex.toString(), fileName));
> 
> The second parameter is not always a straightforward filename, consider to rename it, perhaps `entryPath`?

Indeed. Renamed to `entryPath`. Also adjusted this to accept `Throwable`, so we can skip an entry due to either IOException or ClassFileError.

> src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java line 237:
> 
>> 235:                               skipEntry(ex, e.toString());
>> 236:                           } catch (IOException ex) {
>> 237:                               throw new UncheckedIOException(ex);
> 
> Just to point out this was leading to ClassFileError in the old implementation, new implementation will relay the IOException, which I think is proper.

I have updated this to skip as well - if the outer structure is malformed, we should not have reached this far and would have encountered IOException earlier.

> src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java line 339:
> 
>> 337:                         });
>> 338:             } catch (UncheckedIOException ex) {
>> 339:                 throw ex.getCause();
> 
> IOException used to skip entry with message and continue, the new behavior would change. I am not certain this is behavior compatible.
> I doubt IOException would be recoverable on different entry, but it might in rare cases?

Yep, I think skipping for IOE is correct. If IOE is serious enough that no element is accessible, it should usually be thrown earlier.

> src/jdk.jdeps/share/classes/com/sun/tools/jdeps/DependencyFinder.java line 176:
> 
>> 174:         FutureTask<Set<Location>> task = new FutureTask<>(() -> {
>> 175:             Set<Location> targets = new HashSet<>();
>> 176:             archive.reader().processClassFiles(cf -> {
> 
> I prefer the naming convention with forEach for operation to iterate through rather than have a `process` on a reader. Perhaps named like `forEachClassFile`?

Done in the update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24604#discussion_r2049625074
PR Review Comment: https://git.openjdk.org/jdk/pull/24604#discussion_r2049626124
PR Review Comment: https://git.openjdk.org/jdk/pull/24604#discussion_r2049626614
PR Review Comment: https://git.openjdk.org/jdk/pull/24604#discussion_r2049625262


More information about the core-libs-dev mailing list