RFR 8154270: javac wrongly rejects some class literals as annotation element values

[Jonathan Gibbons]

Yes, I verified that as well, so we're good to push the patch.

-- jon

On 04/27/2016 06:24 AM, Jeremy Manson wrote:
> FWIW, it is correct for new files we contribute to have Google 
> copyright.  As Liam points out, we've done that before in multiple 
> places.
>
> It doesn't make any difference to the GPL or Oracle's ability to 
> relicense.
>
> Jeremy
>
> On Thu, Apr 21, 2016 at 4:59 PM, Liam Miller-Cushon <cushon at google.com 
> <mailto:cushon at google.com>> wrote:
>
>     Thanks for the review! The updated patch is attached.
>
>         * since the issue can be exposed in two ways (reflection and
>         separate compilation), I'd like to see two tests; you have one
>         for reflection - having also the other for separate
>         compilation would be great (since that area tends to get
>         neglected)
>
>
>     To confirm, do you mean the "javac -implicit:none Other.java"
>     example in the original thread? I added that to the test.
>
>     I also thought about testing against a bad class file, but that
>     doesn't exercise anything in the patch and I don't have a good way
>     to generate a class with the problem (ASM won't write classes with
>     this issue, and now javac won't either).
>
>         * I'm not a lawyer - and I'm not sure whether the copyright
>         header in your test is correct ;-)
>
>
>     Oops. Any concerns with using the same header (except for the
>     date) as this:
>     http://hg.openjdk.java.net/jdk9/dev/jdk/file/c0f3840e225a/test/java/util/zip/EntryCount64k.java?
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160427/101164bc/attachment.html>