But is javax.lang.model a plan for JDK 9?
To give some idea of the pain in this area, here is the code I ended up with:
if (type.isInterface() || type.isAnnotation() || type.isPrimitive() ||
type.isArray() || type.isEnum() || type.isSynthetic() ||
Modifier.isAbstract(type.getModifiers()) || type.isAnonymousClass() ||
type.isLocalClass() || (type.isMemberClass() &&
Modifier.isStatic(type.getModifiers()) == false)) {
// error
}
Its pretty laughable really. I just wanted to say "is it a normal class".
FWIW, the KindType does not distinguish between static and inner
member classes either, which was the part that took most of my time to
figure out.
Stephen
On 21 February 2014 15:40, Brian Goetz <brian.go...@oracle.com> 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.
>
>
> On Feb 21, 2014, at 2:27 AM, Stephen Colebourne <scolebou...@joda.org> wrote:
>
>> On 21 February 2014 08:14, David Holmes <david.hol...@oracle.com> wrote:
>>>> Would it be reasonable to add the following methods:
>>>> - isNestedClass()
>>> This would be !isTopLevelClass() but otherwise
>>> isAnonymousClass() || isLocalClass() || isMemberClass()
>>>> - isInnerClass()
>>> isAnonymousClass() || isLocalClass() || (isMemberClass() && !static)
>>>> - isTopLevelClass()
>>> ! (isAnonymousClass() || isLocalClass() || isMemberClass())
>>> and for completeness:
>>> - isStaticNestedClass() == isMemberClass() && static
>>
>> I think the next step is a JIRA unless anyone objects.
>> Stephen
>
