You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've found 22 usages of Set<ClassInfo> directly in jandex classes org.jboss.jandex.Index and org.jboss.jandex.CompositeIndex. Given the fact that ClassInfo does not implement equals/hashCode it would make sense to refactor these classes, esp. the CompositeIndex where multiple ClassInfo instances representing the same java class may appear.
The text was updated successfully, but these errors were encountered:
Those may actually be correct, because in absence of equals/hashCode, a HashMap essentially degenerates into an IdentityHashMap, which may be desired, especially in case of CompositeIndex. That said, I didn't look too deep, reviewing all the places is certainly a good idea.
may be desired, especially in case of CompositeIndex
Could you be more specific?
TBH I find the fact that a CompositeIndex may contain multiple ClassInfos (same or different) of the same FQCN and the CompositeIndex.getClassByName(DotName) method just returns the first one found very confusing...
I have the same feelings about CompositeIndex containing multiple equivalent but different classes, but I can't tell whether that was an intentional decision or not, and at this point, can't even rule out that there are people depending on it :-)
I mean, I agree it should be investigated, but I'm not 100% convinced yet that they all may safely be eliminated.
I've found 22 usages of
Set<ClassInfo>
directly in jandex classesorg.jboss.jandex.Index
andorg.jboss.jandex.CompositeIndex
. Given the fact thatClassInfo
does not implement equals/hashCode it would make sense to refactor these classes, esp. theCompositeIndex
where multipleClassInfo
instances representing the same java class may appear.The text was updated successfully, but these errors were encountered: