[lworld] Dropping jdk.incubator.mvt and MVT change in MethodHandle and reflection

[Karen Kinnear]

> On Feb 27, 2018, at 12:33 PM, mandy chung <mandy.chung at oracle.com> wrote:
> 
> Hi Karen,
> 
> On 2/27/18 9:20 AM, Karen Kinnear wrote:
>> Mandy,
>> 
>> Many thanks for doing these changes!
>> 
>> I had a couple of questions on the source changes:
>> 
>> 1) java/lang/invoke/MethodType.java
>>   leadingReferenceParameter()
>> 
>> The way we are modeling this, a value type is a reference. It sometimes requires
>> special handling - like arrays or interfaces do - but it is still a subtype of java.lang.Object, so still a reference.
>> 
>> I am not sure of the uses of leadingReferenceParameter - but I would expect it to
>> only throw an exception for primitives.
> 
> This patch is the first pass to clean up lworld branch.   leadingReferenceParameter change is simply reverting back to the default branch version.   I will have to look into how MethodHandle and VarHandles work with values in the next pass.   I did change core reflection to throw IAE when setting fields in values as they are immutable.   Basically I try to do this in a few patches. 
Totally makes sense to do this in multiple steps.

I think the leadingReferenceParameter change is not just a reversion - I think you added a
|| type.isValue() - which I think is incorrect.

> 
>> 2) java/lang/invoke/MethodHandles.java
>> 
>> There should be no constructor for value types. 
>> I believe Srikanth is ensuring that in javac, and the jvm will be ensuring that at runtime.
>> So maybe that means that no constructor will be found.
>> 
>> Would it make sense for findConstructor to check for isValue and throw NoSuchMethodException
>> directly? Or does that fall out of the ResolveOrFail call?
Thank you to John for the correction - my bad - value types have no <init>, they do have constructors.
So ignore my comment here.
> 
> I leave MethodHandle support in the next iteration.   Sorry I should have made this clear in my message.   Are you okay with dropping MVT first and handle MHs and tests subsequently?
Absolutely - doing this incrementally is a good way to go.

thanks,
Karen
> 
> 
> Mandy
>> It would be good to have an explicit test for this if you are collecting test cases.
>> 
>> thanks,
>> Karen
>> 
>> 
>> 
>>> On Feb 23, 2018, at 11:45 AM, mandy chung <mandy.chung at oracle.com> <mailto:mandy.chung at oracle.com> wrote:
>>> 
>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/lworld-drop-mvt <http://cr.openjdk.java.net/~mchung/valhalla/webrevs/lworld-drop-mvt>
>>> 
>>> This is the first pass to remove jdk.incubator.mvt module and
>>> MVT support in MethodHandle and reflection.  I have also added
>>> Class::isValue method to determine if it's a value class.  Fields
>>> of a value class are immutable and Field::setXXX methods will
>>> throw IAE if the declaring class is a value class.
>>> 
>>> Mandy
>>> 
>