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

[Maurizio Cimadamore]

On 19/01/15 13:50, Maurizio Cimadamore wrote:
> Hi Duncan
> thanks for the example - the field access at offset 1 is the one for
> 'isPresent' which is a boolean (regardless of how the class is
> specialized) - why should there be an annotation on it?
Sorry, you are correct, as the field is being accessed on an
Optional<any Z>, you do need the attribute.

Thanks for the report
Maurizio
>
> Maurizio
>
> On 19/01/15 13:45, MacGregor, Duncan (GE Energy Management) wrote:
>> 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.
>>>>>>>