I haven't looked at Jandex but knowing the authors I don't think it would be easy to find a good argument to hide its API.

There is a good reason, the reason being that we have our own API (reflite) on top of it. I am not saying that we are not using Jandex under the hood, but I think mixing our own API with the Jandex API as we do now, seems a tad messy to me.

Seems you all committed to use it, then I'd say "so be it": let's embrace it, but then why encapsulate it?

Because we decided to have this reflite thing now. As Steve is saying, the alternative is to put the functionality into Jandex directly which I think is another valid approach (maybe even the better one). It would also show how hard it is to get this information via processing byte code instead of reflection.

While I understand the desire here, I am very leery about duplicating all of Jandex after already duplicating all of the ClassLoader. To me, this seems like an awful lot of memory overhead, so there ought to be some very real and very clear reasons for doing this that outweigh the memory concerns.

Is the question not, whether the memory is allocated during actual runtime (compared to just during bootstrapping). For me it sounds very much like pre-mature optimization in favor of a cleaner API.

So in the interim I think what I did is actually the best. Hardy, is it just a matter of the names? There are some things we could do to alleviate that:

• Convert Map<DotName,AnnotationInstance> returns associated with reflite objects as Map<Name,AnnotationInstance> instead
• Expose a JavaTypeRepository#getAnnotations(Name) method that delegates to IndexView#getAnnotations(DotName)

Definitely a step into the right direction. Also adding JavaTypeRepository#getAnnotations seems like a good idea regardless.