more band aid coming - Object methods on 'any' tvars

[MacGregor, Duncan (GE Energy Management)]

Here’s my little optional class and the output from javap. As you can see
there is no annotation for the getField at offset 1 in public T get(), but
there is for the getField() in public boolean isPresent().

Duncan.

On 19/01/2015 11:26, "Maurizio Cimadamore"
<maurizio.cimadamore at oracle.com> wrote:

>Hi Duncan,
>I've come back to this, and don't seem to be able to reproduce the
>problem; can you please post a bigger snippet that reproduces the issue?
>
>Thanks
>Maurizio
>
>On 16/01/15 15:22, MacGregor, Duncan (GE Energy Management) wrote:
>> Thanks for that, I can now write a sensible optional class and it
>>behaves
>> as expected.
>>
>> One bug I have found is that getField is not always being correctly
>> specialised in all cases. Specifically a final boolean field used in an
>>if
>> statement such as
>>
>> if (!isPresent) { throw... } else { return otherField; }
>>
>> Was not marked for specialisation and caused a byte code verification
>> error, but using a method to get the field value worked perfectly.
>>
>> Duncan.
>>
>> On 16/01/2015 12:29, "Maurizio Cimadamore"
>> <maurizio.cimadamore at oracle.com> wrote:
>>
>>> I've just pushed a compiler/specializer patch that adds support for
>>> T.default.
>>>
>>> This is internally handled as an 'aconst_null' which has a
>>> BytecodeMapping entry attached to it (in case T is an 'any' type-var).
>>> The specializer will then replace the aconst_null with the proper
>>> XYZconst_0.
>>>
>>> Again, to keep things simpler at this stage, stuff like 'int.default'
>>> will not work (parser will reject that). This should still be enough to
>>> get you going with the experiments.
>>>
>>> Happy coding!
>>>
>>> Maurizio
>>>
>>>
>>> On 15/01/15 11:35, Maurizio Cimadamore wrote:
>>>>> That is how I was intending to implement it, but if I don¹t want to
>>>>> subclass then I need have a type something like
>>>>>
>>>>> Class Optional<any T> {
>>>>> 	final T value;
>>>>> 	final boolean hasValue;
>>>>> }
>>>>>
>>>>> And that means I need to set value to something, even for the empty
>>>>> case.
>>>>> Hence the need for defaults.
>>>> Right - I hear you.
>>>>
>>>> Maurizio
>>>>> Duncan.
>>>>>
>