<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 13, 2016 at 10:57 AM, Alex Buckley <span dir="ltr"><<a href="mailto:alex.buckley@oracle.com" target="_blank">alex.buckley@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1er" class="a3s" style="overflow:hidden">I know what you mean, but the fact that I can write @A(Test.I.class) today means making it consistent would be a serious source incompatibility.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is it correct that the following is currently rejected?<br>
<br>
class Test<T> {<br>
   class I {}<br>
   static final Class<?> C = I.class;<br>
}<br>
<br>
error: non-static class Test.I cannot be referenced from a static context<br>
</blockquote>
<br></span>
Good question. This program should not be rejected. No JLS rule prohibits I.class in a static context. Static contexts pertain mostly to object creation and constructor invocation, but a class literal is a rather different kind of expression. Again, the program compiles and runs without error if the source code mentions Test.I.class rather than I.class.</div></blockquote><div><br></div><div>I had wondered if that was deliberate, because `Test.I` makes the erasure explicit and `I` does not. But I suppose the class literal makes that explicit anyways.</div><div><br></div><div>And I don't think it would be a significant incompatibility, for what it's worth. I only found a single example of this in our codebase, and ecj already rejects @A(I.class).</div></div></div></div>