Any::isNull check

[Vitaly Davidovich]

>
> If you're working with an any-T, you don't know whether its a reference or
> value.  So you still have to worry about NPE.


Wouldn't the "right" thing to do, then, be specialize the method in
question for ref vs value types differently? You'd then also ensure the
dead code for value types wouldn't be in the bytecode as well.

But don't get too worked up about the particular expression of
> Any.isNull().  This is just the short-term, expedient hack to get the
> libraries port moving, its not a serious suggestion of how things will
> eventually look.


Yeah, I know this is just a temp thing, not hung up on the API just
wondering about the use case in general.

On Wed, Dec 16, 2015 at 10:46 AM, Brian Goetz <brian.goetz at oracle.com>
wrote:

> If you're working with an any-T, you don't know whether its a reference or
> value.  So you still have to worry about NPE.
>
> But don't get too worked up about the particular expression of
> Any.isNull().  This is just the short-term, expedient hack to get the
> libraries port moving, its not a serious suggestion of how things will
> eventually look.
>
>
> On 12/16/2015 10:42 AM, Vitaly Davidovich wrote:
>
>> What's the use case of using Any.isNull when you don't know you're working
>> with reference types? I'd expect comparison would be x.equals(T.default)
>> in
>> the generic context.
>>
>> On Wednesday, December 16, 2015, Paul Benedict <pbenedict at apache.org>
>> wrote:
>>
>> When a method is specialized for values, Any::isNull can only return
>>> "false", which means if(Any.isNull(o)) can only ever have one outcome --
>>> the other code branch can be discarded by the compiler. I know it's too
>>> early to talk about optimizations :-) but will javac be smart enough to
>>> recognize this optimization? Is it on your list for the future?
>>>
>>> Cheers,
>>> Paul
>>>
>>>
>>
>