Downsides of using Java var keyword

Question

A presenter just cited that changing to var is useful syntactic-sugar (aligning variable names). I thought I'd check and found...

    List<String> list = new ArrayList<>(); // IMO this is safer future-proof coding
    list.add("HELLO WORLD");

... generates bytecode with an invokeinterface dispatch ...

 11: invokeinterface #12,  2           // InterfaceMethod java/util/List.add:(Ljava/lang/Object;)Z

Converting to Java 10+ var ...

    var list = new ArrayList<>();
    list.add("HELLO WORLD");

... generates bytecode with an invokevirtual dispatch ...

 11: invokevirtual #12                 // Method java/util/ArrayList.add:(Ljava/lang/Object;)Z

Should I be concerned with, say, bulk upgrading a whole application's sourcecode with var? E.g. Will sensitive sections be slower (or faster?! given invokeinterface involves more steps?) Aside from that, are there other non-technical impacts (I saw an interesting comment about the clarity of offline code review for example)

The reason for that difference is that the assumed type of your `var` is `ArrayList` rather than `List`. As long as you don't *need* your variable type to be `List` in this case, there's no reason it should cause any problem. If you *do* need your variable to be of type `List`, then it's not a suitable case for `var`. — khelwood, Sep 03 '20 at 21:45
I don't like `var`, but I'm probably an old grouch. 1. In the case of `List` vs. `ArrayList`, you are not declaring the same type, and are no longer coding to an interface. 2. For simple code, `var` saves little. For complicated code, `var` makes each maintenance programmer manually verify the type instead of just having it spelled out in black and white. 3. Since `var` doesn't actually declare the type, I feel this makes literate programming harder. (There's probably other reasons, but those are off the top of my head.) — markspace, Sep 03 '20 at 21:47
... but then I don't see that much is to be gained by changing already written code to use `var` instead of declaring variable types: all those keystrokes used typing in all the variable types have already been performed. — khelwood, Sep 03 '20 at 21:53
Mmm, but bulk transform to Java 7 diamond syntax was welcomed by all. There can be merit in freshening old code. — drekbour, Sep 03 '20 at 22:00
Diamond Operator didn't really change the semantics of the code; `var` did, a little bit, if you're concerned about programming against interfaces; however, you shouldn't use `var` in polymorphic code. "Manifest type declarations for locals are often perceived to be unnecessary" - is the main motivation of [JEP 286](https://openjdk.java.net/jeps/286). — Giorgi Tsiklauri, Sep 03 '20 at 22:17
Can you elaborate what you are concerned about? The code is still invoking the same method. The change with a real impact is not even visible there, as you now have `List — Holger, Sep 04 '20 at 08:19
I added some elaboration but I'm asking abut my unknown unknowns! When someone tells me this is a no-op free upgrade, I tend to want details. — drekbour, Sep 04 '20 at 08:36
Differences between `invokevirtual` and `invokeinterface` are elaborated in [this Q&A](https://stackoverflow.com/q/51112973/2711488). In short, there is no practical difference to the execution. — Holger, Sep 04 '20 at 21:23

score 7 · Answer 1 · answered Sep 03 '20 at 22:05

The reason the bytecode differs is because the var declaration infers the type ArrayList rather than List. It's equivalent to you writing ArrayList<String> list = new ArrayList<>(); explicitly. So if you wouldn't worry about changing List to ArrayList in your variable declaration, you shouldn't worry about changing it to var either.

score -2 · Answer 2 · answered Sep 03 '20 at 21:59

This is java, not PHP :) So, I wouldn't worry if I were you. The only thing that could happen is that it will not compile and you need to 'revert' the var to typed variable.

The only issue var creates is a headache during code review.

IMHO, at least.

Downsides of using Java var keyword

2 Answers2