Develop Reference

how to suppress this warning on the `var` keyword?

The message is:
Warning:(ROW, COLUMN) java: as of release 10, 'var' is a restricted local variable type and cannot be used for type declarations or as the element type of an array
Am using Lombok 1.18.12 from Java 11 targeting version 7, that's how come those var are in there.
How to suppress? What to throw in #SuppressWarnings(...)?
[...]
var excepted = false;
[...]

Just don't use lombok's var, and use the one built into java. That, or, downgrade to java8.
Lombok's var does effectively the same thing as java10+'s 'var', except lombok allows compound assignments and does not allow non-denotable types (java10 var allows non-denotables, but doesn't allow compound). These are two exotic concepts you're unlikely to need :)

Why var in JAVA 10 can not be initialized to null?

I was playing around new features that have been introduced in JAVA 10, where in I found quite interesting fact that you can't declare a variable with null.
As soon as you write below piece of code,
var a = null;
It throws an error :
variable initializer is null
Now, as we all know that we can't declare a primitive type to null, so the below statement doesn't make any sense.
int a = null;
That means, if a developer is initializing a var with null, it definitely wants to put an Object in it, instead of a literal val. If that's the case, my questions here is
Why doesn't compiler consider it to be an Object var and instead
throws an error.
On the other hand, if you write below statement, it works perfectly fine :
var a = (Object)null;
What is the reason to declare a var with null
Consider below case where I want to initialize var and want to use it outside condition blocks:
var a = null;
if(some condition) Initialize with some arguments
else Initialize with some other arguments
//Use a variable here
So, in this case, as we want scope of a to be outside of conditional blocks we have a requirement to intialize it will null outside if block, which is not possible using var.

There are (at least) three possible type inference strategies the compiler could apply to var o = null:
pick Void
pick Object
look for a later initialization and pick that type
All of them are technically feasible, so the question emerges, which one makes the most sense for developers.
Clearly, Void is pretty useless and I would argue that Object is not much more useful, either. While correct, picking either of these types is unlikely to help the developer write better and more readable code.
The last option, looking for an initialization, was not adopted on purpose to avoid so-called action-at-a-distance errors:
var parent = null;
// imagine some recursion or loop structure, so this makes more sense
processNode(parent); // expects a parameter of type `Node`
parent = determineParent(); // returns a parameter of type `Node`
If the compiler inferred Node for parent because determineParent() returns it, this would compile. But the code is fragile because changes to the last line, might lead to a different type chosen in the first line and hence to compile errors on the second line. That's not good!
We're used to the fact that changing a type's declaration can lead to errors down the road but here the change (line 3), its effect (line 1), and consequent error (line 2) can be pretty far apart, this making it much more complicated for developers to understand or, better, predict what happens.
By keeping the type inference rules simple, developers have it easier to form a simple but correct mental model of what's going on.
Addendum
There are doubts whether option 3, inferring the type from a later initialization, is indeed technically feasible. My opinion (that it is) is based on my understanding of JEP 286, specifically:
On the other hand, we could have expanded this feature to include the local equivalent of "blank" finals (i.e., not requiring an initializer, instead relying on definite assignment analysis.) We chose the restriction to "variables with initializers only" because it covers a significant fraction of the candidates while maintaining the simplicity of the feature and reducing "action at a distance" errors.
Similarly, we also could have taken all assignments into account when inferring the type, rather than just the initializer; while this would have further increased the percentage of locals that could exploit this feature, it would also increase the risk of "action at a distance" errors.

What I am asking how can we extend the scope in that case. So for example, if I want to initialize a variablee inside a condition block but want to expand the scope so that the same variable can be used outside the block, what can be done in case of var.
The answer is that you either use:
var a = (RealType) null;
or (to be sensible about it) you use a conventional typed declaration:
RealType a = null;
The var form is just a convenience to avoid having to write a specific type. It simply doesn't work when you initialize with null. Inferring Object as the type of a is not useful behavior in the vast majority of cases.
For example, if (hypothetically) a var could be assigned with a null:
var a = null;
if (something) {
a = someMethodReturningRealType();
}
a.someRealTypeMethod(); // Compilation error ... because the inferred
// type is java.lang.Object. Oops!!
And this is the correct way to write the code:
RealType a = null; // Just use a classic variable declaration
if (something) {
a = someMethodReturningRealType();
}
a.someRealTypeMethod();
My example is just to share where all we may need to declare a var as null. And it seems there is no clear way to do that.
No. You do not need to do it. You want to do it ... but "want" and "need" are not the same thing.
Moreover, this is a very basic Question as if we can do Object x = null; why cant we can do var x = null;
Because the JLS forbids it. That's it. End of story.
If you don't like it, fine. But this is not a discussion forum. And we are not the people who need to be convinced anyway.

One could think the question isn't that far-fetched looking at the handling of genric types.
Let's examine it using List<T> list; as an example. If you do not specify the generic type (List list;) the compiler will handle it with the raw type. You can then add everything to the list - of course null. Applying the concepts of raw type and type erasure to var could allow you to declare var o; and assign later on everything to o. But since using the raw type is discouraged it is obvious that it wasn't choosen how var should work.
Regarding the case List<?> list; and applying it to var o = null; you could think of something like this: ? o. But this leads to nothing. In case of List<?> list; the only option that remains is add(null);. Following the theoretical example and trying to be consistent with present concepts this would mean ? o can only be initialized this way:? o = null;. So your intention to decalre a var and initialize it later would syntactically be possible, but symantically it makes no sense as it would be initialized always the same way with null. So it wouldn't provide any additional value but add complexity.

From an Oracle JDK 10 page:
you cannot just use the var syntax to declare a variable without a
value
You cannot initialise a var variable to null either. Indeed it is not
clear what the type should be as it’s probably intended for late
initialisation.
So basically, you have to be specific as to the datatype you want, the compiler cannot just assume you want Object or any other type.
So the following will all fail compilation:
var x;
var x = null;
var x = () -> {}

When you declare a variable with the keyword var, it's just a shortcut for writing. At the compilation, the keyword will be replace by the type of this variable. In order to know what is the type of the variable, the initialization must be explicit. If you initialise your variable with null, the compiler can't know what is the type of the variable and so can't replace var. So it's forbidden.

You cannot initialize a var variable to null. By assigning null, it is not clear what the type should be, since in Java, any object reference can be null. In the following example, because there is no predefined data type for a null value, the compiler is not able to interpret a type 'test', which would cause a complication error.
var test=null;
//Compilation error because compiler cannot infer type for local variable count since any Java object reference can be null

This is explicitly listed as an illegal initialization of a local variable in JLS Sec 14.4.1:
It is a compile-time error if T is the null type.
...
var g = null; // Illegal: null type
Null is a type in Java:
There is also a special null type, the type of the expression null
However, it is impossible to declare a variable of this type (e.g. you couldn't write null g; or Null g; in a way that would refer to that type), and even if you could, the only possible value it could have would be null:
The null reference is the only possible value of an expression of null type.
So there's no point in allowing you to declare a variable of this type.

From the Java 10 Local Variable Type Inference page:
You cannot initialise a var variable to null either. Indeed it is not clear what the type should be as it’s probably intended for late initialisation.
| Error:
| cannot infer type for local variable x
| (variable initializer is 'null')
| var x = null;
| ^-----------^
null is not a type, so the compiler can't infer the type of the RHS expression.

var is used as a lazy type. When you do var a = new Foo();, the compiler knows that a is of Foo type, this will enable you to call members of Foo using a at compile time.
var a = null; tells the compiler nothing. If the compiler treats a as Object class, then there is no purpose in using var type - you could have easily used Object a = null;.
Update
I think you are thinking this is working like the var in Javascript, which is absolutely wrong.
From one of your comments somewhere else:
What I am asking is at time of compilation, compiler can simply change
the type to Object (Upcast) on the safer side and if in program ,
variable has been initialized by some specific class Object, then
compiler can change it that specific type.
This clearly means that you are looking for a var capability that is just like what the Javascript is doing.
Why is it wrong in Java? Consider this:
var a = null; // Compiler makes 'a' an Object
if (checkSomething()) {
a = new Foo(); // Compiler makes 'a' a Foo
}
else {
a = new Bar(); // Compiler makes 'a' a Bar
}
test(a); // Should this be allowed???
public void test(Foo foo) {}
Should the compiler allow this? No. You will only know what type var is only at runtime. The compiler can never guess what this is at compile-time.
This is why var can never totally replace the traditional way of defining an explicit type. Always remember, var is just a syntactic sugar.

Infer variable type in Java / Eclipse, like C#'s "var"

I like "var" from C# and "def" from Groovy, and I find writing out types in Java to be a pain.
Say I'm writing code like:
List<LongTypeName> results = new ArrayList<LongTypeName>();
or
Map<TypeNameOne,TypeNameTwo> someLookup = fetchMeMyLookup();
What's the easiest way to get this done in Java + Eclipse?
I'm especially interested in the case where I'm not 100% sure what the type will be when I start the line.
My current strategy is to always declare variables as "int", then go back to the start of the line and do "ctrl-1", and accept the type that Eclipse has inferred. Is there any better alternative?
What I would love is to be able to type "def" or "var" and have Eclipse auto-correct this to the correct type as soon as it can figure it out.
(Maybe I should just be programming in Groovy)

Type new ArrayList<LongTypeName>();
Type Ctrl+2+L to create a new local variable
Both type type are 'active' - you can tab through them an cycle through selections. In this example, the name proposals are list and arrayList and the type proposals are all possible interfaces and superclasses of ArrayList<String>, : List<String, Collection<String> etc.

Type:
someLookup = fetchMeMyLookup();
Then click on someLookup and hit Ctrl+1 for the quick fix of "Create local variable someLookup"

Java 10 has introduced type inference for local variables.
You may now use the special (reserved) type name var, e.g.:
var results = new ArrayList<LongTypeName>();
var someLookup = fetchMeMyLookup();
See JEP 286 for details.

What is the equivalent of the C# 'var' keyword in Java?

One use of the var keyword in C# is implicit type declaration. What is the Java equivalent syntax for var?

There is none. Alas, you have to type out the full type name.
Edit: 7 years after being posted, type inference for local variables (with var) was added in Java 10.
Edit: 6 years after being posted, to collect some of the comments from below:
The reason C# has the var keyword is because it's possible to have Types that have no name in .NET. Eg:
var myData = new { a = 1, b = "2" };
In this case, it would be impossible to give a proper type to myData. 6 years ago, this was impossible in Java (all Types had names, even if they were extremely verbose and unweildy). I do not know if this has changed in the mean time.
var is not the same as dynamic. variables are still 100% statically typed. This will not compile:
var myString = "foo";
myString = 3;
var is also useful when the type is obvious from context. For example:
var currentUser = User.GetCurrent();
I can say that in any code that I am responsible for, currentUser has a User or derived class in it. Obviously, if your implementation of User.GetCurrent return an int, then maybe this is a detriment to you.
This has nothing to do with var, but if you have weird inheritance hierarchies where you shadow methods with other methods (eg new public void DoAThing()), don't forget that non-virtual methods are affected by the Type they are cast as.
I can't imagine a real world scenario where this is indicative of good design, but this may not work as you expect:
class Foo {
public void Non() {}
public virtual void Virt() {}
}
class Bar : Foo {
public new void Non() {}
public override void Virt() {}
}
class Baz {
public static Foo GetFoo() {
return new Bar();
}
}
var foo = Baz.GetFoo();
foo.Non(); // <- Foo.Non, not Bar.Non
foo.Virt(); // <- Bar.Virt
var bar = (Bar)foo;
bar.Non(); // <- Bar.Non, not Foo.Non
bar.Virt(); // <- Still Bar.Virt
As indicated, virtual methods are not affected by this.
No, there is no non-clumsy way to initialize a var without an actual variable.
var foo1 = "bar"; //good
var foo2; //bad, what type?
var foo3 = null; //bad, null doesn't have a type
var foo4 = default(var); //what?
var foo5 = (object)null; //legal, but go home, you're drunk
In this case, just do it the old fashioned way:
object foo6;

If you add Lombok to your project you can use its val keyword.
http://projectlombok.org/features/val.html

JEP - JDK Enhancement-Proposal
http://openjdk.java.net/jeps/286
JEP 286: Local-Variable Type Inference
Author Brian Goetz
// Goals:
var list = new ArrayList<String>(); // infers ArrayList<String>
var stream = list.stream(); // infers Stream<String>

With the release of JDK 10 on March 20, Java now includes a var reserved type name (not a keyword—see below) as specified in JEP 286. For local variables, the following is now valid in Java 10 or higher:
var map = new HashMap<String, Integer>();
The var reserved type name in Java is nearly identical to the var keyword in C# in that both allow for implicit typing (see below for important differences). var in Java can only be used for implicit type inference in the following contexts (as enumerated in JEP 286: Goals):
local variables with initializers
indexes in the enhanced for-loop
locals declared in a traditional for-loop
Therefore var cannot be used for fields, return types, class names, or interface names. Its rationale is to remove the need for including long type names when declaring and defining local variables, as stated in JEP 286 (authored by Brian Goetz):
We seek to improve the developer experience by reducing the ceremony
associated with writing Java code, while maintaining Java's commitment
to static type safety, by allowing developers to elide the
often-unnecessary manifest declaration of local variable types.
var Scoping in Java
It should be noted that var is not a keyword in Java, but rather a reserved type name. As quoted from JEP 286:
The identifier var is not a keyword; instead it is a reserved type
name. This means that code that uses var as a variable, method, or
package name will not be affected; code that uses var as a class or
interface name will be affected (but these names are rare in practice,
since they violate usual naming conventions).
Note that since var is a reserved type name and not a keyword, it can still be used for package names, method names, and variable names (along with its new type-interference role). For example, the following are all examples of valid uses of var in Java:
var i = 0;
var var = 1;
for (var i = 0; i < 10; i++) { /* ... */ }
public int var() { return 0; }
package var;
As quoted from JEP 286:
This treatment would be restricted to local variables with
initializers, indexes in the enhanced for-loop, and locals declared in
a traditional for-loop; it would not be available for method formals,
constructor formals, method return types, fields, catch formals, or
any other kind of variable declaration.
Differences Between var in Java & C
This is one notable difference between var in C# and Java include the following: var can be used as a type name in C# but cannot be used as a class name or interface name in Java. According to the C# documentation (Implicitly Typed Local Variables):
If a type named var is in scope, then the var keyword will resolve to
that type name and will not be treated as part of an implicitly typed
local variable declaration.
The ability to use var as a type name in C# creates some complexity and introduces some intricate resolution rules, which are avoided by var in Java by disallowing var as a class or interface name. For information on the complexities of var type names in C#, see Restrictions apply to implicitly-typed variable declarations. For more information on the rationale behind the scoping decision for `var in Java, see JEP 286: Scoping Choices.

I have cooked up a plugin for IntelliJ that – in a way – gives you var in Java. It's a hack, so the usual disclaimers apply, but if you use IntelliJ for your Java development and want to try it out, it's at https://bitbucket.org/balpha/varsity.

It will be supported in JDK 10. It's even possible to see it in action in the early access build.
The JEP 286:
Enhance the Java Language to extend type inference to declarations of local variables with initializers.
So now instead of writing:
List<> list = new ArrayList<String>();
Stream<> stream = myStream();
You write:
var list = new ArrayList<String>();
var stream = myStream();
Notes:
var is now a reserved type name
Java is still commitment to static typing!
It can be only used in local variable declarations
If you want to give it a try without installing Java on your local system, I created a Docker image with JDK 10 installed on it:
$ docker run -it marounbassam/ubuntu-java10 bash
root#299d86f1c39a:/# jdk-10/bin/jshell
Mar 30, 2018 9:07:07 PM java.util.prefs.FileSystemPreferences$1 run
INFO: Created user preferences directory.
| Welcome to JShell -- Version 10
| For an introduction type: /help intro
jshell> var list = new ArrayList<String>();
list ==> []

A simple solution (assuming you're using a decent IDE) is to just type 'int' everywhere and then get it to set the type for you.
I actually just added a class called 'var' so I don't have to type something different.
The code is still too verbose, but at least you don't have to type it!

As of Java 10, the equivalent is ... var.

You can take a look to Kotlin by JetBrains, but it's val. not var.

Java 10 did get local variable type inference, so now it has var which is pretty much equivalent to the C# one (so far as I am aware).
It can also infer non-denotable types (types which couldn't be named in that place by the programmer; though which types are non-denotable is different). See e.g. Tricks with var and anonymous classes (that you should never use at work).
The one difference I could find is that in C#,
If a type named var is in scope, then the var keyword will resolve to that type name and will not be treated as part of an implicitly typed local variable declaration.
In Java 10 var is not a legal type name.

I know this is older but why not create a var class and create constructors with different types and depending on what constructors gets invoked you get var with different type. You could even build in methods to convert one type to another.

Lombok supports var but it's still classified as experimental:
import lombok.experimental.var;
var number = 1; // Inferred type: int
number = 2; // Legal reassign since var is not final
number = "Hi"; // Compilation error since a string cannot be assigned to an int variable
System.out.println(number);
Here is a pitfall to avoid when trying to use it in IntelliJ IDEA. It appears to work as expected though including auto completion and everything. Until there is a "non-hacky" solution (e.g. due to JEP 286: Local-Variable Type Inference), this might be your best bet right now.
Note that val is support by Lombok as well without modifying or creating a lombok.config.

You can, in Java 10, but only for Local variables, meaning,
You can,
var anum = 10; var aString = "Var";
But can't,
var anull = null; // Since the type can't be inferred in this case
Check out the spec for more info.

In general you can use Object class for any type, but you have do type casting later!
eg:-
Object object = 12;
Object object1 = "Aditya";
Object object2 = 12.12;
System.out.println(Integer.parseInt(object.toString()) + 2);
System.out.println(object1.toString() + " Kumar");
System.out.println(Double.parseDouble(object2.toString()) + 2.12);

This feature is now available in Java SE 10. The static, type-safe var has finally made it into the java world :)
source: https://www.oracle.com/corporate/pressrelease/Java-10-032018.html

`final` keyword equivalent for variables in Python?

I couldn't find documentation on an equivalent of Java's final in Python, is there such a thing?
I'm creating a snapshot of an object (used for restoration if anything fails); once this backup variable is assigned, it should not be modified -- a final-like feature in Python would be nice for this.

There is no final equivalent in Python. To create read-only fields of class instances, you can use the property function, or you could do something like this:
class WriteOnceReadWhenever:
def __setattr__(self, attr, value):
if hasattr(self, attr):
raise Exception("Attempting to alter read-only value")
self.__dict__[attr] = value
Also note that while there's #typing.final as of Python 3.8 (as Cerno mentions), that will not actually make values final at runtime.

Having a variable in Java be final basically means that once you assign to a variable, you may not reassign that variable to point to another object. It actually doesn't mean that the object can't be modified. For example, the following Java code works perfectly well:
public final List<String> messages = new LinkedList<String>();
public void addMessage()
{
messages.add("Hello World!"); // this mutates the messages list
}
but the following wouldn't even compile:
public final List<String> messages = new LinkedList<String>();
public void changeMessages()
{
messages = new ArrayList<String>(); // can't change a final variable
}
So your question is about whether final exists in Python. It does not.
However, Python does have immutable data structures. For example, while you can mutate a list, you can't mutate a tuple. You can mutate a set but not a frozenset, etc.
My advice would be to just not worry about enforcing non-mutation at the language level and simply concentrate on making sure that you don't write any code which mutates these objects after they're assigned.

Python 3.8 (via PEP 591) adds Final variables, functions, methods and classes. Here are some ways to use it:
#final Decorator (classes, methods)
from typing import final
#final
class Base:
# Cannot inherit from Base
class Base:
#final
def foo(self):
# Cannot override foo in subclass
Final annotation
from typing import Final
PI: Final[float] = 3.14159 # Cannot set PI to another value
KM_IN_MILES: Final = 0.621371 # Type annotation is optional
class Foo:
def __init__(self):
self.bar: Final = "baz" # Final instance attributes only allowed in __init__
Please note that like other typing hints, these do not prevent you from overriding the types, but they do help linters or IDEs warn you about incorrect type usage.

An assign-once variable is a design issue. You design your application in a way that the variable is set once and once only.
However, if you want run-time checking of your design, you can do it with a wrapper around the object.
class OnePingOnlyPleaseVassily(object):
def __init__(self):
self.value = None
def set(self, value):
if self.value is not None:
raise Exception("Already set.")
self.value = value
someStateMemo = OnePingOnlyPleaseVassily()
someStateMemo.set(aValue) # works
someStateMemo.set(aValue) # fails
That's clunky, but it will detect design problems at run time.

There is no such thing. In general, the Python attitude is "if you don't want this modified, just don't modify it". Clients of an API are unlikely to just poke around your undocumented internals anyway.
You could, I suppose, work around this by using tuples or namedtuples for the relevant bits of your model, which are inherently immutable. That still doesn't help with any part of your model that has to be mutable of course.

you can simulate something like that through the descriptor protocol, since it allows to define reading and setting a variable the way you wish.
class Foo(object):
#property
def myvar(self):
# return value here
#myvar.setter
def myvar(self, newvalue):
# do nothing if some condition is met
a = Foo()
print a.myvar
a.myvar = 5 # does nothing if you don't want to

As of 2019 and PEP 591, Python has a Final type. It won't be available in the standard library until the release of Python 3.8, but until then you can use it via the typing-extensions library. It won't work as final works in Java though as Python is still a dynamically typed language. But if you use it together with a static type checker like mypy it will give you very similar benefits.
There is also a final decorator that can be applied to mark class methods as final and preventing from being overridden. Again this is only checked at "compile-time", so you'd need to include a static type checker in your workflow.

Python has no equivalent of "final". It doesn't have "public" and "protected" either, except by naming convention. It's not that "bondage and discipline".

http://code.activestate.com/recipes/576527/ defines a freeze function, although it doesn't work perfectly.
I would consider just leaving it mutable though.

Python indeed does not have a final type, it does have immutable types such as tuples but that is something else.
Some of the other Answers here make classes full of pseudo final variables and I prefer my class to only have a few Final types, so I suggest using an descriptor to create the final type:
from typing import TypeVar, Generic, Type
T = TypeVar('T')
class FinalProperty(Generic[T]):
def __init__(self, value: T):
self.__value = value
def __get__(self, instance: Type, owner) -> T:
return self.__value
def __set__(self, instance: Type, value: T) -> None:
raise ValueError("Final types can't be set")
If you use this class like so:
class SomeJob:
FAILED = FinalProperty[str]("Failed")
Then you will not be able to set that variable in any instance of that class.
Unfortunately as with the WriteOnceReadWhenever answer you can still set the class variable.
job = SomeJob()
job.FAILED = "Error, this will trigger the ValueError"
SomeJob.FAILED = "However this still works and breaks the protection afterwards"

Although this is an old question, I figured I would add yet another potential option: You can also use assert to verify a variable is set to what you originally intended it to be set to – a double checking if you will. Although this is not the same as final in Java, it can be used to create a similar effect:
PI = 3.14
radius = 3
try:
assert PI == 3.14
print PI * radius**2
except AssertionError:
print "Yikes."
As seen above, if PI were for some reason not set to 3.14, an AssertionError would be thrown, so a try/except block would probably be a wise addition. Regardless, it may come in handy depending on your situation.

As of Python 3.8, Python does have a keyword "final". However, it is a hint and is not enforced at runtime.