On 02/21/2014 07:40 AM, Brian Goetz wrote:
I understand why you want this, though I think you’ll find that there are still
thousands of other things “missing” from reflection.
In the Java 1.0 days, the difference between the Java language and the class
file was pretty small. So reflection served as both the class file (VM)
reflection and language reflection mechanism. But, over time, the gap has
grown wider. We’ve made the decision (though not always consistently applied)
that reflection is about serving up the class file information to Java, not
about answering questions about the Java language. So, for example, it can’t
tell that one method is a bridge for another, or easily answer questions about
inheritance or overriding. Similarly, the issues raised here are about gaps
between the class file representation of a class and the language level model.
Historically we have added some things to reflection to fill in these gaps.
However, our current strategy is to expose this through javax.lang.model, which
is designed to reflect the langauge-level view of the world, and this is what
users really want anyway. Currently the only implementation of
javax.lang.model that is available is in the compiler, exposed to annotation
processors, but we have a plan to expose one backed by core reflection which is
a more sensible way to express the information you are looking for.
The nested class situation is so tricky, I wrote a blog entry about it
complete with a diagram:
https://blogs.oracle.com/darcy/entry/nested_inner_member_and_top
The javax.lang.model API uses a NESTING_KIND enum to model these
distinctions:
http://download.java.net/jdk8/docs/api/javax/lang/model/element/NestingKind.html
As of JDK 8, we've published a proof of concept implementation of
javax.lang.model backed by core reflection as sample code:
http://hg.openjdk.java.net/jdk8/tl/langtools/file/tip/src/share/sample/language/model/CoreReflectionFactory.java
Cheers,
-Joe
