@s.luhmirins

goto

in Java?

That just looks like a labeled return to me

I am pretty sure I have seen and maybe even tried

goto

in Java. It could also be Pascal way back in school 🙂

goto

is a reserved word in Java, sure. But using it is an error.

I think they reserved it either because it could cause confusion if an identifier was named "goto", or to maybe implement

goto

in the future

same as

const

🙂

ok, I am just going crazy then

I don't know...

goto

as a construct is in general seen as bad...but most constructs we have today are just limited and more specific forms of

goto

anyway

I've seen java decompilers doing some crazy stuff with labelled breaks to translate goto's that are present in the Java Bytecode back to Java

Many obfuscators use gotos to make translation into Java impossible 🙂

I've really come to appreciate how kotlin does const.

In kotlin it's automatic. Either you declare var or val

In Java it's an after thought..

You have to flood everything with final and not many do because it's not a necessary part of the declaration

In kotlin it's just so simple and a natural part of the process

And in Java, you should probably never use

final

except on fields anyway.

Because in Java you won't receive any benefit from those additional chars, But in Kotlin there are smart-casts, which works pretty cool when all the world are immutable.

What I really hate is that final != const as well. Any final variable can be mutated through reflection.

@cedric what's wrong with using

final

elsewhere? I've used it in local scopes and it was useful, in my opinion

@kevinmost It’s useless for parameters and locals in my experience because bugs coming from reassigning such variables are pretty much nonexistent. First of all, because you hardly ever reassign and second, reassigning hardly ever causes a bug.

So it’s noise.

I agree for params. I think it's useful for locals sometimes:

final String myVar;
if (someCondition) {
  myVar = val1;
} else if (someOtherCondition) {
  myVar = val2;
} else {
  throw new IllegalStateException("...");
}
// use myVar and know it was properly initialized

it’s a lot better asking for permission, than automatically granting it to everyone.

It leads to fewer possible side effects as well

(yes, for this example you could have used a ternary and done it in one line, but what if you wanted to do more complicated stuff in each case?)... actually no you couldn't use a ternary here, because you can't throw at the end

For this particular case, yes, I’d agree

final

is useful there. Fortunately, it’s pretty rare to initialize locals this way

why would final be useful there?

I guess to guarantee that it cannot be null.

@evanchooly because you get a compiler error if you try to use

myVar

and it's possible that it wasn't initialized

it could be null, you just have to set it yourself to that explicitly 🙂