Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JEP 286: Local-Variable Type Inference

openjdk.java.net

Post reply on HN
Print view View original

91–100 of 132 posts

Re: JEP 286: Local-Variable Type Inference

#91

Post by skippytheroo »

plesner wrote: post #23

In their list of risks there's one missing: it makes changing the return type of a method to a subclass a subtly breaking change. Say some api defines a method, Collection getNames() { ... } and in your code you do var names = getNames(); if (...) names = Collections.emptySet(); Now, if the api later changes getNames() to be List getNames() { ... } your code breaks. That's one of the advantages of only allowing this…

It will be caught as a compiler error. Since you would typically have the method signature declare that it returns the most general type it should be a non-issue. It's really no different from breaking code today by changing a method signature in an API.

Re: JEP 286: Local-Variable Type Inference

#92

Post by skippytheroo »

acjohnson55 wrote: post #80

The reaction here is indicative of why I'm starting to consider whether maybe it's best that Java stays Java. Sure, I'd personally be really annoyed typing super redundant type declarations everywhere. But then again, I wouldn't have to, because I'd simply use Scala, because it's more expressive. But a lot of people clearly love good old verbose Java. Java has been super slow to adopt things that are more or less the…

The reaction from some reminds me that some Java programmers will always resist change. Java's current feature set is the one true way (tm) and any features other languages have are bad, that is until they are officially added to Java and are then suddenly considered part of the one true way (tm) and further evidence of the language designers' wisdom.

Re: JEP 286: Local-Variable Type Inference

#94

Post by wmu »

nsxwolf wrote: post #88

I've never liked this language feature very much. I'm the one that's doing the inference when I read the code.

I totally agree, type inference speed writing a code, nothing more.

For easy cases reading such code is OK (var path = "/usr/bin/whatever" - obvious), but with a more complex code it becomes awful.

I'm a C++ programmer, and quite often I have to dig through dozens of headers to find out what this magic "auto" really means.

Re: JEP 286: Local-Variable Type Inference

#95

Post by ygra »

jkot wrote: post #62

I hope they will give it second though. In Java 'var' or 'val' are not reserved keywords. It was difficult to migrate existing code when 'enum' was introduced. 'const' is reserved but nothing for variable, perhaps 'new' or some symbols.

They will be made into reserved type names. Since classes with those names violate naming conventions anyway they should be quite rare.

Re: JEP 286: Local-Variable Type Inference

#96

Post by nikolay »

oldmanjay wrote: post #70
nikolay wrote: post #51

Earlier quoted context omitted.

Optional, alright, but promoting bad practices. If people like dumb-down languages, there are plenty of them already!

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.

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

Re: JEP 286: Local-Variable Type Inference

#97

Post by skippytheroo »

incepted wrote: post #81
mindcrime wrote: post #69

Earlier quoted context omitted.

Same here. Groovy rocks my world and is the main reason I've barely even looked at Java 8.

If Groovy rocks your world, wait until you meet Kotlin...

If Kotlin rocks your world, wait until you meet the Scala.

Re: JEP 286: Local-Variable Type Inference

#98

Post by vorg »

mindcrime wrote: post #69
biehl wrote: post #36

Earlier quoted context omitted.

My experience is similar, however more like: Groovy === happy developers

Same here. Groovy rocks my world and is the main reason I've barely even looked at Java 8.

Apache Groovy has some long-standing governance issues, e.g. the groovy-lang.org DNS is owned by a single individual. Other languages such as Kotlin and Scala have more, er, responsible governance.

Re: JEP 286: Local-Variable Type Inference

#99

Post by gabriele »

ygra wrote: post #39
gabriele wrote: post #20

I expect this breaking a few things in fields injection (a la Spring @Autowired[1]) if implemented. [1] https://docs.spring.io/spring-framework/docs/current/spring-...

How would type inference for local variables mess with fields?

according to Spring's documentation[1]:

@Autowired is fundamentally about type-driven injection

If you replace:

    @Autowired
    FooDao fooDao;
with something like:

    @Autowired
    var fooDao;
I'm pretty sure type-driven injection breaks.

[1] https://docs.spring.io/spring/docs/current/spring-framework-...

Re: JEP 286: Local-Variable Type Inference

#100

Post by icebraining »

wmu wrote: post #94
nsxwolf wrote: post #88

I've never liked this language feature very much. I'm the one that's doing the inference when I read the code.

I totally agree, type inference speed writing a code, nothing more. For easy cases reading such code is OK (var path = "/usr/bin/whatever" - obvious), but with a more complex code it becomes awful. I'm a C++ programmer, and quite often I have to dig through dozens of headers to find out what this magic "auto" really means.

That's because C++ combines type inference with a gnarly compilation process. In a language like Java, editors will support it and you'll just be able to "mouse over" (or press a key combo in Vim/Emacs) and it'll tell you the inferred type.
Post reply on HN