[8u40] Request for Approval: 8067039: Revert changes to annotation attribute generation

[Daniel D. Daugherty]

On 12/11/14 8:56 AM, Seán Coffey wrote:
>
> On 11/12/2014 15:24, Daniel D. Daugherty wrote:
>>
>> On 12/11/14 7:52 AM, Seán Coffey wrote:
>>> Approved. Please add 9-na to the bug report.
>>>
>>> I've not sure what bug record policy is in such scenarios but I 
>>> think the
>>> 8u40 records for JDK-8029012 and JDK-8065132 need to be reverted to
>>> something like "will not fix" ?
>>
>> No, they should not. Changesets were pushed using those bug IDs and
>> it would be confusing to change the state of the bugs.
> A user goes to check status of JDK-8029012 and JDK-8065132 in 8u40 and
> sees "Fixed" - that's equally as confusing and a more normal use case 
> I would think.

I recommend checking with Joe Darcy about what the proper process is.

The problem that we've seen in JDK9 is from the Mercurial auto-updater
as the changesets are pushed to parent repos... the bug gets reresolved
as fixed... Why? Because the original changeset is again pushed to a
repo followed by the subsequent anti-delta...


> The net effect of the changesets in 8u-dev is now zero.

No argument there... as long as you are looking at the tip. If are
looking at the repo at a specific point in time like the snapshot
taken for a particular promoted build... then your answer may be
different.

Dan


>
> regards,
> Sean.
>
>> However, it
>> would be good to add a note to those two bugs stating that the
>> changes have been reverted/anti-delta'ed using JDK-8067039.
>>
>> Dan
>>
>>
>>>
>>> regards,
>>> Sean.
>>>
>>> On 11/12/2014 14:43, Eric McCorkle wrote:
>>>> Please approve JDK-8067039, which reverts JDK-8029012 and JDK-8065132,
>>>> which cause previous versions of javac in 8 not to be able to load 
>>>> some
>>>> classfiles generated by the current 8u javac.
>>>>
>>>> After discussions amongst the langtools team, it was decided that the
>>>> change should be backed out in 8u, but kept in 9 in order to work
>>>> towards a more complete solution to the underlying problem (see
>>>> JDK-8066725 and JDK-8062582 for details)
>>>>
>>>> The patch was created cleanly by reverting JDK-8029012 and 
>>>> JDK-8065132.
>>>>   The patch ran cleanly through a JPRT run.  Review was conducted on
>>>> compiler-dev, and it was approved by Jonathan Gibbons.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~emc/8067039/
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8067039
>>>
>>>
>>>
>>
>
>
>