Ladislav Thon

Is this perhaps related to #1141? (If so, I guess we should keep this one open, as it has more details/ideas. I'd close #1141 as duplicate.)

Note to self: this might be more complex than it seems, because Jandex sometimes depends on serializing things in a topological order.

I realized we could easily use hash trees to avoid rebuilding an index if the underlying classes didn't change. During indexing, we'd compute a hash of each input file (a...

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...

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...

An alternative would be to modify `CompositeIndex` to do this. If the indices don't overlap, the behavior wouldn't change. If they do overlap, I'd argue this behavior is more useful...

And it turns out that `CompositeIndex.getKnownUsers` already implement the overlay behavior described above.

At this moment, I know the callback-based annotation transformation in Quarkus by heart, and I can confidently say that 1. it is a bad fit for Jandex, and 2. it...

FTR, I've got one more thing I _would_ like to add to Jandex that should help a lot with overlaying -- the notion of equivalence. Jandex classes often don't have...

Note to self: vast majority of use cases I've seen so far only need transforming annotations (including the use cases behind #117). There's one more interesting use case in https://github.com/quarkusio/quarkus/pull/19883...