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

Jeremy Manson jeremymanson at google.com
Wed Apr 27 13:24:50 UTC 2016


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>
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/84fb9bcd/attachment.html>


More information about the compiler-dev mailing list