Jandex 3.6.0
Today, we announce the release of Jandex 3.6.0. This release contains a number of improvements and bug fixes.
The following methods:
-
IndexView.getAnnotationsWithRepeatable() -
AnnotationTarget.annotationsWithRepeatable() -
AnnotationTarget.declaredAnnotationsWithRepeatable() -
Type.annotationsWithRepeatable()
require an annotation name on the input, together with an index that is used to obtain the annotation class. The annotation class is used to figure out if the annotation is repeatable and if so, to obtain the name of the container annotation.
Very often, when these methods are called, the user knows that the annotation is repeatable and has access to the name of the container annotation. For these cases, this release adds overloads that, instead of an index, accept a name of the container annotation directly.
BREAKING CHANGE: This change adds one method to the IndexView interface, which is sometimes implemented by user code.
It should be relatively straightforward to implement, similarly to the existing implementation of getAnnotationsWithRepeatable().
A class JandexKotlin was added that contains a small number of helper methods that are common when working with Kotlin code.
The ClassInfo class intentionally doesn’t provide equality (as in, doesn’t override equals()).
While this seems questionable, there is a good reason for it: if you have a composite index representing multiple JARs (each sub-index of the composite corresponding to one JAR), those JARs may contain duplicate classes.
To be able to faithfully represent such case, equality cannot be based just on a class name, and ClassInfo currently doesn’t contain any other information that would help distinguish classes with the same name but coming from different JARs.
Hence, equality of ClassInfo is just identity.
However, ClassInfo didn’t override hashCode() either.
The default hashCode() implementation is not deterministic, which is bad for various reproducibility efforts (including CompositeIndex).
Therefore, since this release, ClassInfo does override hashCode() (but not equals()!).
The hash code is based on the class name, which leads to collisions in case of duplicate classes, but those are relatively rare, so this shouldn’t be an issue.
Creating an EquivalenceKey for array types was fixed in case the array type contained type annotations on the array dimensions.
One more case of invalid type annotation paths generated by the Kotlin compiler was found, and this release adds a workaround. Thanks Liam Miller-Cushon for the bug report!
If you experience any troubles, or if you have any ideas for Jandex improvements, please file an issue.
