> If anything it's more readable, since your code isn't littered with redundant type info.

I fail to see the redundant type info.

Example 1:

int maxWeight = blocks.stream() .filter(b -> b.getColor() == BLUE) .mapToInt(Block::getWeight) .max();

"int" is not redundant type info here.

Example 2:

List<String> list = new ArrayList<>(); // (1)

var list = new ArrayList<String>(); // (2)

Many would say List<String> in (1) is redundant but I would argue otherwise. The intention of List<String> in (1) is to reference to the underline ArrayList through List interface. (1) is trying to encourage programming to an interface while (2) just completely destroys the practice by inferring the type for list variable to be ArrayList<String>. That means subsequent method invocations after (2) can be methods from ArrayList not List.

If you can explain the value of restricting a local initialized with a new instance being inferred to be an interface type, you'll have a point. You won't be able to, because there is literally no point since the constructor must be statically referenced anyway, but I'd love to see you try.

Have you never Map<Shard, ListenableFuture<RpcEndpointResult>>? And then mapped it through various asynchronous transformations? Good god, the type soup.

There is a point where typing becomes verbose and decreases readability. If the compiler can infer, it should. It'll save time, money, and sanity.

You fail to see that type inference is optional. So yes for readability's sake, in your first example I wouldn't omit the "int", but in simpler cases you CAN omit if you want. And that's just nice, end of story.

What are the bad practices being promoted by this? How does it qualify as dumbed down? Simply ranting about things that, charitably, you don't seem to understand, does not make the rants valid.

As the sibling comment indicates, and I wish to amplify with precision, if you are using the static constructor reference to initialize the local, declaring the local reference to be of a super type is cargo cult nonsense, not a best practice. The concrete type is already locally known, nothing is gained via the abstraction.

The best practice is that the type of the variable is of the interface, not the implementation except in some special cases.

So stop using constructors and start using static factory methods. The return type of a static factory method can be the interface type.

Yeah, let's UML the hell out of everything to be enterprisey and be Martin Fowler-approved! This is what turned off a lot of people before!

Sorry, did "static factory" sound scary? How about "use a function to create your objects" instead?

So instead of doing this:

    Foo foo = new Foo("bar");

You can do this:

    Foo foo = Foo.of("bar");

Yeah, but how about the implementation?

This is complete nonsense if you're using a static constructor and not a factory. There's zero point to doing this for a local, statically constructed type. It's not a best practice.

If you were using a factory, var would infer the factory signature's type, which would normally be the interface.

No, it's not a complete nonsense, no. People abusing Java with overengineering and using factories and other enterprisey design patterns for everything made a lot of people leave the Java land!

> People abusing Java with overengineering and using factories and other enterprisey design patterns for everything made a lot of people leave the Java land!

Actually, people left Java land because they couldn't express what they needed to without using complicated design patterns.

A "static factory" is just a static method. You know, a function. Nothing over-engineered or enterprisey about using functions to allocate objects.

Why state the obvious?

> Why state the obvious?

So you think using functions is enterprisey and over-engineering things?

Read my other reply to you on the subject! The API might be a small syntactic change, but the concepts and the implementation behind those for noobs are not. They learn OOP and constructors and then you tell them - they suck, use factories via static methods.

Yes, but that's a fault in Java the language. Keeping Java bad doesn't solve that problem.

I agree. A little native support for wide-spread best practices would only be a good thing for Java.

I agree. "var" as proposed is dumbing down Java. If there's an intelligent way to infer the interface, not the implementation, then I'd accept it, but otherwise, it's the JavaScriptification if Java given most IDEs can autocomplete this and let you correct if they assume wrongly.