Right.  Because isEmpty() is declared final, it should be able to be inlined by the complier and later by the JIT without any larger analysis work being required.  Since the expression is so trivial, it should be a really good candidate for the inlining.  4 loads and 2 compares is bordering on the cost of the method call enter/exit, so it really should inline.

But, in reality, I wasn't thinking too much about performance here.  I just selected the expression and did Refactor > Extract Method in Eclipse and moved on.  The getType() method isn't very fast to begin with.  Its coded more for readability than it is for speed.  I think there may be some redundant compares occurring for some code paths.  If I cared a lot about the performance of this function I would probably redo how some of these compares occur.

I did the extraction of the method because I was planning on using isEmpty() inside patience diff.  But I later concluded that was foolish.  The place I wanted it was part of the critical path of patience diff, but I proved to myself that at that point in the code isEmpty() is always false.  Therefore the call was unnecessary and I backed out of it.  But I forgot to undo this refactoring.