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

MacGregor, Duncan (GE Energy Management) duncan.macgregor at ge.com
Fri Jan 16 15:22:48 UTC 2015


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



More information about the valhalla-dev mailing list