Any::isNull check

[Brian Goetz]

I think we're just spinning in "I could imagine ..." territory now.  Try 
porting a real codebase (like Collections) and I think your perspective 
will change.

On 12/16/2015 11:31 AM, Vitaly Davidovich wrote:
>
>     If you mean that the developers should write two versions of each
>     method, one for nullable and one for not, that would be
>     ridiculous.  Duplicating N lines of code because one line of a
>     method has to do a null check would be terrible.  (Spend a half
>     hour trying to port the Collections code with that approach, and
>     ask yourself if you can honestly ask people to code that way.) 
>
>
> Not of each method.  In Paul's case he made it sound like there's some 
> substantial dead code to be eliminated in case of value types, making 
> it sound like there's more than just one or two lines of difference.  
> The other approach is to take the one or two lines in a bigger method 
> that differ for value vs ref type and move just them into 2 
> specialized methods, one for ref and other for value types.
You mean, like the Any.isNull() method Paul was asking about?

This solution sounds appealing until you try it.  Asking people to split 
out tiny peeled methods sounds unintrusive.  In the first 30 seconds, it 
even feels clever.  Thereafter, it feels burdensome.

> Given current limitations in inlining heuristics, removing dead 
> bytecode outright before JIT sees it is a big win.  Right now, lots of 
> people end up splitting methods in awkward unnatural ways just to 
> avoid hitting these issues.

When you say "people", be aware you really mean "the 0.001% of users for 
whom it makes a big enough difference to put up with it" (as this is the 
world you live in.)  I care about those people too, but I care more 
about the code written by the other 99.999% of Java programmers.  So, 
I'm focusing first on "what's the right expression of the code" and then 
"what's the right classfile representation".

Going back to work now.