Possible bug inspecting com.google.common.collect.AbstractMapBasedMultimap

[colin-young]

Tested with ClassGraph 4.8.141. See attached repro code.

typeSignatureParamTypes.size() > typeDescriptorParamTypes.size() for method com.google.common.collect.AbstractMapBasedMultimap$RandomAccessWrappedList.<init>

The error is reproducible with guava-28.2 and does not appear with guava-31.0.1. I'm assuming ClassGraph shouldn't error out even if there is some issue with the class being inspected.

Project
Log Files

I found a single reference to a similar issue here: openrewrite/rewrite#1312

[lukehutch]

This is a very strange situation. Here is one example of a method that exhibits this problem:

Class:

com.google.common.collect.AbstractMapBasedMultimap$RandomAccessWrappedList

Constructor method descriptor (has 4 parameters):

void <init>(com.google.common.collect.AbstractMapBasedMultimap, java.lang.Object, java.util.List, com.google.common.collect.AbstractMapBasedMultimap$WrappedCollection)

Method signature for the same constructor (has 3 parameters):

void <init>(K, java.util.List<V>, com.google.common.collect.AbstractMapBasedMultimap<K, V>$WrappedCollection)

I'll keep digging...

[lukehutch]

What seems to be going on here is that the compiler added an implicit synthetic or bridge parameter to the beginning of the parameter list for the type descriptor, but not for the type signature. Unfortunately it's impossible to detect which of these parameters are synthetic or bridge parameters, because method parameter modifiers are only added to a method's attributes in JDK 8+, and only when the code is compiled with the commandline -parameters flag. Therefore the type descriptor for methods is basically junk.

I'll change ClassGraph to use the method signature whenever it is available, ignoring the method descriptor, only falling back to the method descriptor if the method is non-generic (has no method signature).

This won't solve the problem for every case, and it will be basically impossible to get this right in every case where the compiler has done something egregious like this, because of the critical omission of information about whether extra parameters have been prepended.

[lukehutch]

This should be fixed in 4.8.143. Thank you for the bug report, and for providing a repro project!