hg: valhalla/valhalla: [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers.

[Remi Forax]

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Karen Kinnear" <karen.kinnear at oracle.com>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Mercredi 27 Juin 2018 04:11:37
> Objet: Re: hg: valhalla/valhalla: [lworld] Withdraw support for the __Flattenable and __NotFlattened field modifiers.

> FTR, I'm fine with this too for LW1.
> 
> I think the highest priority for LW1 is to guide some users into
> a smooth and simple user experience, and see whether it
> really works.
> 
> For this to work gaps in functionality are tolerable (statics,
> constructors?).
> 
> Excess (half-baked) functionality should be factored
> under a flag so users won't "bump into it" without knowing
> they are moving out of the central experience we want
> to test.  That includes integration with generics and
> nullability control, also those extra modifiers.

Playing with the prototype, i've found that disabling value types as type argument make a lot of codes to not compile, hard to do something fun when a simple ArrayList, Comparable, Stream or Optional doesn't work. I wonder if it's not better to let people to use generics even if the behavior of LW10 will be different ? 

> 
> If we can get constructors working we can put __WithField
> and __DefaultValue under experimental flags also.
> 
> — John

Rémi

> 
> On Jun 26, 2018, at 8:47 AM, Karen Kinnear <karen.kinnear at oracle.com> wrote:
>> 
>> Srikanth, Tobias,
>> 
>> Yes please to push this patch to move these modifiers under the experimental
>> flag. this is a much better approach.
>> 
>> LW1 is a really tight deadline right now and we don’t want to cause extra work.
>> My apologies for missing the implications.
>> 
>> thank you both,
>> Karen
>> 
>>> On Jun 26, 2018, at 7:23 AM, Srikanth <srikanth.adayapalam at oracle.com> wrote:
>>> 
>>> 
>>> The attached patch would cause the flattenability modifiers to be accepted with
>>> their erstwhile syntax and semantics when javac is invoked with
>>> -XDallowFlattenabilityModifiers
>>> 
>>> I'll wait to hear from Karen and push/discard accordingly.
>>> 
>>> (I am likely away Thursday/Friday, I will be available on Wednesday. Posting a
>>> patch here, so if it is required in my absence it can be availed. It passes all
>>> langtools tests)
>>> 
>>> Thanks!
>>> Srikanth
>>> 
>>> On Tuesday 26 June 2018 03:38 PM, Srikanth wrote:
>>>> 
>>>> 
>>>> On Tuesday 26 June 2018 03:32 PM, Tobias Hartmann wrote:
>>>>> Hi Srikanth,
>>>>> 
>>>>> On 26.06.2018 11:37, Srikanth wrote:
>>>>>> I did have an express go from Karen to "nuke" these source level modifiers
>>>>>> before proceeding. But in
>>>>>> light of what you say, I'll take a look and see what is involved in pushing
>>>>>> these under an option
>>>>>> instead.
>>>>> Thanks for looking into it but we should probably wait for Karen to comment on
>>>>> that. I guess I
>>>>> missed the discussion/decision of fully removing these modifiers (I thought we
>>>>> just don't want to
>>>>> support them for LW1).
>>>> 
>>>> Sounds good to me. I'll keep a patch ready in any case and after hearing from
>>>> Karen decide to push or discard.
>>>> 
>>>> I believe the consensus in the VM is to move away fromACC_FLATTENABLE on fields
>>>> to using the ValueTypes attribute.
>>>> 
>>>> Your concern below about the code rot is valid.
>>>> 
>>>> Srikanth
>>>>> 
>>>>>> Even with that many of the tests would need "massaging" but I guess it won't
>>>>>> shut you out from
>>>>>> retaining the support for non-flattened value type fields.
>>>>> Yes, I'm fine with modifying the tests, I'm just concerned that without testing
>>>>> the implementation
>>>>> of non-flattenable fields in the JVM, the code will start to rot very soon.
>>>>> 
>>>>> Thanks,
>>>>> Tobias
>>>> 
>>> 
>>> <flat.txt>