Does it actually help? After 10 years of java I don't really remember any case where defining local variable as final would catch an error. Though maybe these cases are easy to forget.

From my experience in 20 years of Java, it prevents the reusage of local vars, which mostly is wrong.

   Person p = ....
   p = doSomething(p)
   ...
   p = doSomethingElse(p)

is hard to reason about when it should be

   Person p = ....
   ... lots of code
   Person updated = doSomething(p) 
   ... lots of code
   doSomethingElse(updated)

Which is easier to read and understand. So you might have had bugs that would have been prevented with final, but you didn't attribute to final.

I remember bugs that were caused by the exact opposite. If p is superceded by updated then it's not a good idea to have both hanging around in the local scope.

You shouldn't be able to doSomethingElse(p) when you actually mean to doSomethingElse(updated).

So basically, what rust prohibits.

I don't know Rust very well at all, but I believe that Rust would only prohibit that if p and updated were referencing the same thing. If updated was a modified copy of p then I don't think Rust would help. But I could easily be wrong on that.

What would help is splitting the function up so that you don't have multiple named variables representing multiple versions of the same thing in the same scope:

   Person doSomethingAndDots() {
     Person p = doSomething(...)
     ...
     return p 
   }

   main() {
      doSomethingElse(doSomethingAndDots())
   }

If the transformation function consumes p, rather than taking a reference to it, Rust will stop you from using the variable again afterwards.

Rust explicitly allows shadowing, that way you can have it both ways. An immutable variable that can't be reassigned but you can still reuse names.

That is to ease the pain of unwrapping nested types and error-checking intermediate steps so you don't have to come up with new names for each intermediate.

I really like being able to declare immutable variables with ‘let’ in Swift. Java should add the immutable option too. Although, ‘val’ makes more sense considering Kotlin and Scala use it.

For me, it is not about catching errors, it is about documentation.

In the codebase I work on most, all variables that can be marked final are marked final. That means that whenever I see a non-final variable, I know that something tricky is happening and I need to be extra careful in reading the code.

This is my reasoning as well. Also I am currently returning Optionals from any method that can result in a null.

The problem is that java.util.Optional has no special syntactic support compared to the way optionality is supported in Kotlin for example. And it is barely used in the standard libraries. And many/most 3rd parties libraries don't use it. Thus you end up with multiple styles in your code base: in places checking for null, in other places extracting the value from an Optional. And the type system/language doesn't prevent an Optional reference itself being null.

The Optional class is typical of the halfassery that has accompanied many improvements to Java over the years. From java.util.logging to generics to streams, I'm invariably irritated by compromises particularly as they've decided that maintaining backward compatibility is now a secondary concern.

I've run out of patience in the direction Java has taken and I've been a user since 1.0.4 - I'm going to try Kotlin for my next project.

Also, if you're interoperating with Kotlin, a nullable reference works better than an Optional. A Kotlin nullable reference compiles down to a reference with intellij's @Nullable annotation, and a Kotlin non-nullable reference compiles down to a reference with intellij's @NotNull annotation.

It also works in the opposite direction: a Java parameter or return value annotated as @Nullable (doesn't have to be intellij's, the Kotlin compiler understands several annotation libraries) will appear as a nullable reference to Kotlin code, and a @NotNull or @Nonnull annotation makes it appear as a non-nullable reference.

Coming from functional languages, I really really tried to make optional work in our code base. However, it's inability to interact with checked exceptions or even slightly unusual control flow make it a real pain. It feels like fighting the language. My current suggestion is to pick a nullability annotation, and then wire it through your compiler and IDE, so it tells you if you forgot null checks, or made a superfluous null check on something annotated non-null.

I was surprised by the responses about Optionals. Will have to look into it. As an alternative I have been looking to use the following to guarantee that certain methods cannot/will not return null (below). Maybe that is the better way to go?

return Optional.ofNullable(applications).orElseThrow(NullPointerException::new);

return Optional.ofNullable(applications).orElse(new Application());

var is inside jdk10... http://openjdk.java.net/jeps/286

I think they meant the separate keywords to distinguish "var" and "final var". Personally I like just reusing the final keyword, which for once would actually mean the very same thing in the very same place, with "var" just taking place of the type name. More familiarity, less surprises.

The problem is that "val" or "const" is not.

Besides the 6 extra chars, the difference between “final var foo = ...” and “val foo = ...”?

I would argue it's not about the extra characters, it's about enforcing explicit mutability.

In Scala, where var/val both exist, each time you declare a variable you are forced to think about its mutability. But if you only have "var", with the _option_ of tacking "final" to it, then a programmer can simply forget to make that decision, because the language allowed them to.

Those "6 extra chars" mean more noise for human on the screen, it can lead to line wrapping or in other way harm the formatting, and last but not least it does not make it easier to promote good coding practices.

If the final keyword hadn't existed before I'd agree, but it does exist, does exactly what you'd expect it to here, and I'd argue that since it's consistent with how it used to work, is actually easier to understand and grasp. Local type inference is a new feature. Locals that can be assigned once is not and people are already familiar with how such locals are declared. And there's no ambiguity which variant is the correct one, e.g.:

    var i = 0;
    final var i = 0;
    int i = 0;
    final int i = 0;
    val i = 0;

One of the options there is a very odd one. And if there was "val", would "final var" be disallowed?

None of course, but I think that's the point of the complaint. For a feature supposed to increase convenience, it didn't go as far as it could have. Still, I'm glad var is in there. (Now, my employer just needs to get off of Java 8...)

be carful with adopting java9 and java10. they won't live that long...

var seems like a bad idea to me. One of the things I like about Java is (strong?) typing. Recently learning C# and was put off by 'var'. Why is it a good idea?

'var' in C# and Java doesn't change strong or static typing at all. It's just type inference. Your code is still statically typed, the compiler and IDE will catch errors. It's just that it's smart enough to infer the types of redundant things instead of making you type it.

So instead of typing:

  AbstractConcreteFactoryFactory factory = new AbstractConcreteFactoryFactory();

You can just type it only once:

  var factory = new AbstractConcreteFactoryFactory();

It drastically decreases mental/physical overhead of typing the dang code out without in any way affecting typing.

C# is a huge breath of fresh air compared to java largely because of useful type inference. It's easy to make compilers do more work now.

Rust is doing type inference with drastically stronger types, for example.

Variables declared with var are still strongly typed. Just because the keyword exists in JavaScript, it doesn't mean it has the same semantic meaning.

    var p = new Person();
    
    p = 1234; // This will trigger a compile time error

depends, writing something like:

`Simple<List<Map<String, Demo>, OtherList<Map<Int, String>>` is a little bit painful.

I use scala and basically most often at least public Methods should (in scala you can omit even that, however some functional libraries need a return type) have a explicit type, which most often is enough.

I'd advise spending an afternoon trialing Kotlin. It works side by side with existing Java code, has good IDE support (*assuming Jetbrains), and gets you var/val along with a lot of other goodness (data classes, extension methods, etc). At worst you'll have a nice demo for your next tech all-hands.