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

[Maurizio Cimadamore]

This is now fixed with latest push.

Thanks
Maurizio

On 19/01/15 13:52, Maurizio Cimadamore wrote:
> 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.
>>>>>>>>