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

[Karen Kinnear]

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.
>> 
>