In KT-50198, Spock generates a method named `$spock_feature_0_0` which
is annotated with `org.spockframework.runtime.model.FeatureMetadata`.
The problem is that for some reason (probably a bug in Spock or some
kind of version mismatch), this annotation lacks value for the method
`dataVariableNames`, which has no default value.
If an annotation lacks a non-default value, it's OK for the JVM, but not
OK for Java reflection. Specifically, `Annotation.equals` for annotation
proxy classes created at runtime checks that values are equal for each
annotation method. If there's no value for some annotation method
without a default value, it fails with NPE.
kotlin-reflect used `Annotation.equals` in `ReflectJavaAnnotation`,
however there was no intention to perform structural equals on
annotations; equals/hashCode were implemented only to make stuff like
`LazyJavaAnnotations.annotationDescriptors` work, which is a hash map
where `JavaAnnotation` (`ReflectJavaAnnotation` in kotlin-reflect) is
the key.
This commit changes equals/hashCode to use identity instead, since this
is cheaper, and safer because of cases like the one described above.
This is also consistent with other implementations, e.g. PSI-based
`JavaAnnotationImpl` which naturally checks if the underlying PSI
elements are the same, without any kind of structural equality.
I'm not entirely sure why this appeared as a regression in 1.5.30, but
the most likely candidate is the signature enhancement refactoring,
after which we (supposedly) started to load more annotations on
declarations coming from Java, just in case they are annotated with some
nullability annotations.
No test added because to replicate the issue, we basically need to
generate an incorrect annotation proxy class _at runtime_, which is
difficult.
#KT-50198 Fixed
Alexander Udalov
56fe62b7fb