[Nestmates] RFR 8187567: [Nestmates] Enable nestmate changes in javac by default

[Maurizio Cimadamore]

Thanks David.

I've approved the three reviews I've seen related to test disabling - 
but I realize you have already pushed them. That's ok.

Thanks for filing the test bugs to keep track for follow up activity.

Maurizio



On 21/09/17 05:29, David Holmes wrote:
> I'm preparing to push these changes. I've now performed the following 
> test runs:
> - hotspot
>    - runtime
>    - tier_1
>    - tier_2_runtime
>    - tier_2_runtime_platform_agnostic
>    - tier3_runtime
> - jdk
>    - tier1
>    - tier2
>    - tier3
>
> I've created four bugs in relation to tests that need modification:
>
> JDK-8187698 [Nestmates][Testbug] Test 
> java/lang/invoke/AccessControlTest.java needs updating for nestmates
>
> JDK-8187655 [Nestmates][Testbug] 
> jdk.lambda.separate.ClassToInterfaceConverter needs updating for 
> changed invocation rules
>
> JDK-8187645 [Nestmates] Update Pack200 and tests, to recognize and 
> process new Nestmate attributes
>
> JDK-8187607 [Testbug] Atomic*FieldUpdaterTest.checkPrivateAccess uses 
> nested classes
>
> and four corresponding sub-tasks (sent out for review here) to either 
> add the tests to the ProblemList.txt file, or else disable specific 
> failing subtests.
>
> I plan to push all these together as the final set of nestmate changes 
> before we transition to the new consolidated repo layout.
>
> Thanks,
> David
>
> On 15/09/2017 7:02 PM, David Holmes wrote:
>> On 15/09/2017 6:15 PM, Maurizio Cimadamore wrote:
>>> Looks great.
>>
>> Thanks for taking a look Maurizio!
>>
>>> The only thing we might need (not now, maybe later) is a 'reverse' 
>>> javac flag that forces generation of accessor and/or invokevirtual 
>>> on private in case you want to generate classfile with latest 
>>> version number but with old properties.
>>
>> Yes. If we need it I'll add it. It is a pity the -XDxxx can't be more 
>> like the hotspot -XX:+xxx and -XX:-xxx flags to allow for 
>> enable/disable.
>>
>> Cheers,
>> David
>>
>>> Cheers
>>> Maurizio
>>>
>>>
>>> On 15/09/17 08:12, David Holmes wrote:
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8187567
>>>> webrev**: http://cr.openjdk.java.net/~dholmes/8187567/
>>>>
>>>> ** 
>>>> test/runtime/Nestmates/privateConstructors/TestInvokeSpecial.java 
>>>> contains additional changes for 8187536. They will be checked in 
>>>> separately.
>>>>
>>>> While nestmates will ultimately be associated with a future 
>>>> source/target version of the JDK and an updated classfile version 
>>>> (see JDK-8187302) we want to be able to enable them by default 
>>>> as-if executing in that future release.
>>>>
>>>> The primary changes are confined to javac and are very 
>>>> straight-forward:
>>>> - generate the nestmate attributes in the classfile
>>>> - use virtual invocation bytecodes for private method invocations
>>>> - don't generate private accessors
>>>>
>>>> With this change in place we can update the hotspot nestmate tests 
>>>> to not provide explicit "@compile" directives. We also add a test 
>>>> to verify that invokeinterface is rejected for private interface 
>>>> methods in pre-nestmate classfile versions (v52 works fine for this).
>>>>
>>>> We can now build the JDK with the new nestmate features enabled, 
>>>> and run tests without needing to provide additional javac options.
>>>>
>>>> I also added a missing testcase in 
>>>> test/runtime/Nestmates/privateMethods/TestInvoke.java (just to 
>>>> ensure there's no unexpected difference with this$0 usage).
>>>>
>>>> Thanks,
>>>> David
>>>