can API be implemented on top of reflection?

[Brian Goetz]

One of the choices we made is to stay as close to JVMS Ch4 as we can.  
There were a number of reasons, one of the more subtle ones is that if 
you try to abstract over what's in the classfile, it means that even the 
simplest transforms have to make round-trips from the native format to 
the abstracted format and back.  Whereas if we give you something that 
maps roughly 1:1 with the classfile format (with exceptions; labels and 
constant pool indexes have to be abstracted), then simple transforms 
involve less needless data motion.  Which illustrates a key, deliberate 
design priority: that while most of the API surface is about reading and 
writing classfiles, most of the interesting use cases involve 
transforming classfiles, and we want this to be as free of impedence 
mismatch as possible.

To make this concrete, symbolic information (e.g., classes) is exposed 
directly as constant pool entries -- but reflection doesn't give you 
those, so these would have to be faked.  (Obviously reflection will 
bottom out before it gives you method bodies, too.)   A more subtle 
example is that it is hard to tell, reflectively, the difference between 
not having a RuntimeVisibleAnnotationsAttribute, and having one that 
contains no annotations (same for all "listy" attributes, like method 
exceptions).  And the fakery goes on; to create a synthetic Signature 
attribute, you'd have to reverse engineer all the information that 
reflection carves into little bits.  All of which is to say that the 
ClassModel that you'd get if you tried to abstract over reflection would 
involve a lot of fakery (and fidelity loss if you tried to then 
transform it into a new classfile.)

So, its possible, but I'm not convinced that we'd like the result.

> One feature of the gnu.bytecode library (use by Kawa) is that it provides
> the same API whether the information is extracted from a .class file
> or from reflection.  If this new library in some hypothetical future
> is to replace gnu.bytecode it would be nice to preserve that 
> functionality.
>
> Based on a quick look at the API it seems like it should be possible 
> to implement
> a ClassModel on top of reflection.  That would be desirable,
> even if it's not a primary initial goal of this project.  Still, it
> would be nice to provide that as either part of the library itself
> or as a testsuite to make sure it remains feasible.
>
> Perhaps ultimately the new API could a suitable replacement for the
> reflection API, but with the lessons of the "Mirrors" ideas in the
> 2004 paper 
> (https://urldefense.com/v3/__https://bracha.org/mirrors.pdf__;!!ACWV5N9M2RV99hQ!IDvYjRq58nngngAfRsofjUK7vvaEaPCe7YoulgZOqXxMXjVzHtt9desKzRwOQSnSJCV3kYD_7gKAlshFvMXlaw$ 
> ).
>
> Of course these ideas are not new to Brian and his co-workers,
> but I thought it worth mentioning them here.