hg: valhalla/valhalla: 8222634: [lworld] Javac sometimes emits incorrect ('Q') descriptors for fields.

[Srikanth]

Hi Karen,

Yes, please, raise a ticket ideally with a snippet that shows the 
problem and the expected behavior in terms of generated code.

Thanks!
Srikanth

On 17/04/19 8:55 PM, Karen Kinnear wrote:
> Srikanth,
>
> Many thanks for the quick turnaround on fixes. Your timing helps a great deal as we try to get an LW2 EA
> ready since you are at the start of the chain.
>
> So in addition to the ValueType?[42] array syntax you are working on, we had one more issue with
> the new syntax update:
>
> “withfield” handling:
> Old __Withfield syntax supported the model that it could be used in any nestmates of the declaring class,
> and would explicitly generate just the single bytecode “withfield”.
>
> The updated syntax “MyValue1.f1 = Foo;”
>    appears to be using different restrictions:
>    javac appears to be restricting it to constructors which convert to factories
>    and therefore is generating defaultvalue followed by with fields.
>
> The intent was to have the new syntax also just generate a single “withfield” bytecode with the
> nestmate restrictions.
>
> As Frederic reminded us, the use model use case is iterators, e.g. for a Cursor inlined class.
>
> Does this make sense to you? Do you need me to file a JBS for this?
>
> thanks,
> Karen
>
>> On Apr 17, 2019, at 10:09 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>
>> Great.  Note that null-default is for L20, not L10, so perhaps we should work that in a dependent branch?
>>
>>> On Apr 17, 2019, at 10:02 AM, Srikanth <srikanth.adayapalam at oracle.com> wrote:
>>>
>>>
>>>
>>> On 17/04/19 6:43 PM, Brian Goetz wrote:
>>>>>> (1) Compile time null assignment to values should be tolerated (?)
>>>>>> (2) Compiler does not tolerate the following:
>>>>>> MyValue1?[] vBoxArray = new MyValue1?[42];
>>>>> On (1) can I get a quick confirmation that this is what we want ? I did see some discussion regarding javac not proactively catching these and letting the VM report an NPE. But I seem to have missed the rationale behind that decision against failing early.
>>>> On (1), I think this should be done on the basis of value set inclusion.  For reference types, null-default value types, and the nullable-projection of zero-default value types (V?), null is a member of the value set; for primitives, and for zero-default value types, it is not.  I think the compiler should not allow assignment of a value that is not a member of the value set.
>>> Perfect. I must have misread a private communication from one of the contributors that ATM I am unable to locate, but your outline clarifies the questions I had.
>>>
>>> javac does not yet have a notion of null default value types. Other than that the tip behavior should match what describe above. I have half a dozen smallish tasks to wrap the various loose ends and also test the V? implementation more and after that I will start on the null default value types.
>>>
>>> Thanks
>>> Srikanth
>>>> We need better terminology….I said value and null too many times in the above paragraph.