[Nestmates] RFR (S): 8194906: [Nestmates] Finalize javac and other tool changes
david.holmes at oracle.com
Mon May 14 00:42:22 UTC 2018
On 10/05/2018 6:31 AM, Karen Kinnear wrote:
> Share your concern: disableVirtualizedPrivateInvoke flag - if we want it
> - would be a backward compatibility flag - i.e.
> only supported for cases that JDK10 supports - so invocations of private
> methods in the caller’s class - not for general
> nestmate private methods. We chose not to go the invokespecial path for
> that for a reason.
Right. I'm going to push this as-is as I need to finalize things before
the official mainline RFR is released later today. Further discussions
on this will take place in that RFR on java-compiler-dev.
>> On May 8, 2018, at 9:43 PM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>> On 8/05/2018 7:14 PM, David Holmes wrote:
>>> In preparation for putting out the mainline RFR for nestmates I've
>>> made a few updates to the javac support as Maurizio and I have
>>> discussed (generally) in email in the past:
>>> webrev: http://cr.openjdk.java.net/~dholmes/8194906/webrev/
>>> - move test location
>>> - remove disableAccessors/disablePrivateAccessors flags and rely on
>>> nestmate support for disabling private accessors
>>> - add disableProtectedAccessors as an experimental flag
>>> - remove virtualizePrivateAccess flag
>>> - add disableVirtualizedPrivateInvoke flag
>>> The disableVirtualizedPrivateInvoke flag allows us to easily switch
>>> back to issuing invokeSpecial instead of
>>> invokeVirtual/invokeInterface for private method invocations. This
>>> can be useful for running tests in a "legacy" mode without having to
>>> disable all nestmate support (by running with --release 10 for example).
>> For example, I just added:
>> to the webrev. But I'm having some doubts about the utility and wisdom
>> of doing this. If you generate invokespecial you have to obey all
>> invokespecial access rules, which won't be the case in general if
>> accessing nestmate private methods. It works for the above test, but
>> there are others in java/lang/invoke that fail.
More information about the valhalla-dev