say I have a piece of code in a local method
int a = 5, b;
and then some code to indirectly initialize B such as
if (true) b = 5; // legal
if (someBool) b = 10; else b = 7; // legal
if (false) b = 5; // illegal
illegal even though B will always be initialized
if (a > 10)
b = 4;
if (a <= 10)
b = 4;
My question is what are all of the exact circumstances in which a local variable can be legitimately considered "initialized"?
A local variable can be considered to be "initialized" if the compiler can easily deduce that every possible code path will lead through a path where the value has been set.
if(true) can be determined to always run.
if(false) can be determined to never run.
if/else can be determined to run at least one of the branches, so you must assign the variable in each branch if you want it to be guaranteed initialized. Same principle applies for if/else if/.../else
switch statements will either run one of the possible cases, or will hit the default case, so if you assign the variable in all of these places then it can be guaranteed initialized.
The Java compiler doesn't bother checking all the possible values of each variable at various points in the method when making this determination, because variables are variable--they can change. However, if values can be considered constant then it can safely assume they won't change.
For example, the compiler doesn't care if you assign a variable and never change it in your code:
boolean val = true;
if(val) {
b = 5;
}
Debuggers and things make it possible for you to change the value of val on-the-fly, so the compiler doesn't make any assumptions here. However, if you make val constant, by declaring it final and initializing it with a constant or literal value, then the compiler will treat it exactly the same as if you'd used the constant value in code.
final boolean val = true;
if(val) { // Same as if you'd said `if(true)`
b = 5;
}
Such constants can be chained, as well, and the compiler will simplify them to their constant values rather than maintaining the longer expressions and operators:
final int five = 5;
final int four = five - 1; // Same as `four = 5 - 1`, or `four = 4`
final boolean val = five > four;
if(val) { // Same as `if(5 > 4)`, or `if(true)`
b = 5;
}
For further reading, check out the Java Specs. (Hat tip to Radiodef for finding the right section.)
In this case:
if (false) b = 5; // illegal
The compiler throws an exception since if(false) can be erased at compile time. It is futile to even analyze a block of code that won't be executed by any mean.
In this case:
int a = 5, b;
if (a > 10)
b = 4;
if (a <= 10)
b = 4;
The compiler cannot assure that the piece of code will be executed since a can change its value. In this case, you can fix it by marking a as final and assigning it a literal int value (which compiler can understand):
final int a = 5;
int b;
if (a > 10)
b = 4;
if (a <= 10)
b = 4;
But note that you can still break this code by giving final int a a value that the compiler cannot determine:
final int a = foo();
int b;
if (a > 10)
b = 4;
if (a <= 10)
b = 4;
//...
int foo() {
return 5;
}
More info:
Java Language Specification. Chapter 16. Definite Assignment
Related
Why are assignment chains are evaluated in right to left order?
i = j = k = 10;
is
k = 10;
j = k;
i = j;
Addition is evaluated left to right:
public static void main(String[] args)
{
int i = m1() + m2() + m3();
}
public static int m1()
{
System.out.println("m1");
return 1;
}
public static int m2()
{
System.out.println("m2");
return 2;
}
public static int m3()
{
System.out.println("m3");
return 3;
}
Output:
m1
m2
m3
According to which rule are assignment operator chains processed in right to left order?
Why? Because that's the most useful order, and seems to conform to most people's expectations, perhaps in part because that's the usual case.
The other way round would be surprising (i.e., a source of bugs):
int k;
j = 42;
i = j = k = 10;
Left to right leaves i at 42, j undefined, and k 10. Right to left makes all 3 variables have the value 10, much more useful.
Which rule? https://docs.oracle.com/javase/specs/jls/se10/html/jls-15.html#jls-15.26
Chainable assignment is right-associative (i.e. right to left) simply because that is the only way it would make sense. The operation i = j = k = 10 is supposed to assign 10 to all three variables. If it was done left to right, it would evaluate to
i = j;
j = k;
k = 10;
Rather, than assigning the same value to all three, it would be "shifting" the values: i gets the old value of j, j gets the old value of k, and only k gets the value 10. Now, this could possibly be a useful operation to have, but it is not the intended behaviour here, so it has to be done from right to left.
Also, going left to right would evaluate to ((i = j) = k) = 10, which would be putting an rvalue (the assignment expression as a whole is an rvalue) on the left side of an assignment, which is not allowed.
The evaluation order is specified in the Java Language Specification (JLS). In section 15.26 Assignment Operators is written
There are 12 assignment operators; all are syntactically right-associative (they
group right-to-left). Thus, a=b=c means a=(b=c), which assigns the value of c to
b and then assigns the value of b to a.
This means, that the right-most assignment is performed first, then then next to the left etc.
Generally, the precedence of operations is specified by the grammar of Java. This also specifies why additions are performed after multiplications.
Concerning you first question: It would be quite counter-intuitive to evaluate the assignment in a different order, as the variables could have different values afterwards.
Until today, I thought that for example:
i += j;
Was just a shortcut for:
i = i + j;
But if we try this:
int i = 5;
long j = 8;
Then i = i + j; will not compile but i += j; will compile fine.
Does it mean that in fact i += j; is a shortcut for something like this
i = (type of i) (i + j)?
As always with these questions, the JLS holds the answer. In this case §15.26.2 Compound Assignment Operators. An extract:
A compound assignment expression of the form E1 op= E2 is equivalent to E1 = (T)((E1) op (E2)), where T is the type of E1, except that E1 is evaluated only once.
An example cited from §15.26.2
[...] the following code is correct:
short x = 3;
x += 4.6;
and results in x having the value 7 because it is equivalent to:
short x = 3;
x = (short)(x + 4.6);
In other words, your assumption is correct.
A good example of this casting is using *= or /=
byte b = 10;
b *= 5.7;
System.out.println(b); // prints 57
or
byte b = 100;
b /= 2.5;
System.out.println(b); // prints 40
or
char ch = '0';
ch *= 1.1;
System.out.println(ch); // prints '4'
or
char ch = 'A';
ch *= 1.5;
System.out.println(ch); // prints 'a'
Very good question. The Java Language specification confirms your suggestion.
For example, the following code is correct:
short x = 3;
x += 4.6;
and results in x having the value 7 because it is equivalent to:
short x = 3;
x = (short)(x + 4.6);
Yes,
basically when we write
i += l;
the compiler converts this to
i = (int)(i + l);
I just checked the .class file code.
Really a good thing to know
you need to cast from long to int explicitly in case of i = i + l then it will compile and give correct output. like
i = i + (int)l;
or
i = (int)((long)i + l); // this is what happens in case of += , dont need (long) casting since upper casting is done implicitly.
but in case of += it just works fine because the operator implicitly does the type casting from type of right variable to type of left variable so need not cast explicitly.
The problem here involves type casting.
When you add int and long,
The int object is casted to long & both are added and you get long object.
but long object cannot be implicitly casted to int. So, you have to do that explicitly.
But += is coded in such a way that it does type casting. i=(int)(i+m)
In Java type conversions are performed automatically when the type of the expression on the right hand side of an assignment operation can be safely promoted to the type of the variable on the left hand side of the assignment. Thus we can safely assign:
byte -> short -> int -> long -> float -> double.
The same will not work the other way round. For example we cannot automatically convert a long to an int because the first requires more storage than the second and consequently information may be lost. To force such a conversion we must carry out an explicit conversion.
Type - Conversion
Sometimes, such a question can be asked at an interview.
For example, when you write:
int a = 2;
long b = 3;
a = a + b;
there is no automatic typecasting. In C++ there will not be any error compiling the above code, but in Java you will get something like Incompatible type exception.
So to avoid it, you must write your code like this:
int a = 2;
long b = 3;
a += b;// No compilation error or any exception due to the auto typecasting
The main difference is that with a = a + b, there is no typecasting going on, and so the compiler gets angry at you for not typecasting. But with a += b, what it's really doing is typecasting b to a type compatible with a. So if you do
int a=5;
long b=10;
a+=b;
System.out.println(a);
What you're really doing is:
int a=5;
long b=10;
a=a+(int)b;
System.out.println(a);
Subtle point here...
There is an implicit typecast for i+j when j is a double and i is an int.
Java ALWAYS converts an integer into a double when there is an operation between them.
To clarify i+=j where i is an integer and j is a double can be described as
i = <int>(<double>i + j)
See: this description of implicit casting
You might want to typecast j to (int) in this case for clarity.
Java Language Specification defines E1 op= E2 to be equivalent to E1 = (T) ((E1) op (E2)) where T is a type of E1 and E1 is evaluated once.
That's a technical answer, but you may be wondering why that's a case. Well, let's consider the following program.
public class PlusEquals {
public static void main(String[] args) {
byte a = 1;
byte b = 2;
a = a + b;
System.out.println(a);
}
}
What does this program print?
Did you guess 3? Too bad, this program won't compile. Why? Well, it so happens that addition of bytes in Java is defined to return an int. This, I believe was because the Java Virtual Machine doesn't define byte operations to save on bytecodes (there is a limited number of those, after all), using integer operations instead is an implementation detail exposed in a language.
But if a = a + b doesn't work, that would mean a += b would never work for bytes if it E1 += E2 was defined to be E1 = E1 + E2. As the previous example shows, that would be indeed the case. As a hack to make += operator work for bytes and shorts, there is an implicit cast involved. It's not that great of a hack, but back during the Java 1.0 work, the focus was on getting the language released to begin with. Now, because of backwards compatibility, this hack introduced in Java 1.0 couldn't be removed.
What happens if you change the variable b, or what if you change a. What does the order have to do with anything.
I know count = count + 1 but the two variables is messing up my brain.
b = 7;
a = 7;
a = b;
a += 1;
What happens to b?
What happens to b?
Nothing happens to b.
When you do
a = b;
you're copying the value stored in b and putting it in a. (You're not making a an alias of b.)
When you then do a += 1; you're changing the value stored in a (and the value stored in b remains unchanged).
You can verify this by printing the final values after your code snippet:
System.out.println(a); // prints 8
System.out.println(b); // prints 7
What happens if you change the variable b, or what if you change a. What does the order have to do with anything.
a and b are two independent variables and changing one will never affect the other.
The order matters since when you do a = b the value of b is copied into a and whatever a stored before is discarded. If you had done a += 1 prior to a = b, then a would have been restored to 7 again.
int is raw type you don't copy reference but the value itself. This will work same way for Integer because it is immutable class.
int b = 7;
int a = 7;
a = b;
a+=1;
System.out.println(a);// ->8
System.out.println(b);// ->7
Still 7.
integer is raw type and if you assign a int variable to another int, just its value is received by the new one. Not the object itself.
b stays 7.
a becomes 8.
You could use System.out.println(); to print values of variables and find out yourself if you ever doubt.
That or use the debugger.
public static void main(String[] args) {
int b = 7; // b points to 7
int a = 7; // a points to 7
a = b; // b and a points to 7
a += 1; // a points to 8 now, b is still pointing to 7
System.out.println(a);
System.out.println(b);
}
output
8
7
When we do a += 1; we change the value stored in a (value stored in b is still same).
I'm working on Project Euler Problem 9, which states:
A Pythagorean triplet is a set of three natural numbers, a < b < c, for which,
a^2 + b^2 = c^2
For example, 3^2 + 4^2 = 9 + 16 = 25 = 52.
There exists exactly one Pythagorean triplet for which a + b + c = 1000.
Find the product abc.
Here's what I've done so far:
class Project_euler9 {
public static boolean determineIfPythagoreanTriple(int a, int b, int c) {
return (a * a + b * b == c * c);
}
public static void main(String[] args) {
boolean answerFound = false;
int a, b, c;
while (!answerFound) {
for (a = 1; a <= 1000; a++) {
for (b = a + 1; b <= 1000; b++) {
c = 1000 - a - b;
answerFound = determineIfPythagoreanTriple(a, b, c);
}
}
}
System.out.println("(" + a + ", " + b + ", " + c + ")");
}
}
When I run my code, I get this error:
Project_euler9.java:32: error: variable a might not have been initialized
System.out.println("The Pythagorean triplet we're looking for is (" + a + ", " + b + ", " + c + ")");
Note: I get this for each of my variables (a, b, and c) just with different line numbers.
I thought that when I declared a, b, and c as integers, the default value was 0 if left unassigned.
Even if this weren't the case, it looks to me like they all do get assigned, so I'm a bit confused about the error.
Why is this happening?
Instance variables (in your case, they would be integers) are assigned to 0 be default. Local variables not. (From Java Docs)
If the loop is not entered, then your variables won't be initialized, that's the reason of the error.
What you can do is initialize them when declaring:
int a=0, b=0, c=0;
Your problem is this line:
System.out.println("(" + a + ", " + b + ", " + c + ")");
which is after the while (!answerFound) {...} loop. The compiler thinks that there may be a case where one or more of the variables a, b or c isn't initialised.
Use this line:
int a=0, b=0, c=0;
when declaring the variables, so that they are initialised when declared, and the error should go away.
Do this, at the beginning of the method after the local variables are declared:
a = b = c = 0;
The error is basically stating that Java can't be sure that the variables have a value assigned when they reach the System.out.println(). Remember: in Java only attributes have default values, all local variables must be explicitly initialized at some point.
You're right and wrong in your thinking:
Where you're right:
Yes, uninitialized variables may be assigned a value by the compiler, but a) it is considered bad style, b) You shouldn't depend on it, c) That does not apply to local variables (as declared in a method)
Where you are wrong:
Local variables are not assigned a default value, only instance variables.
For reference, take a look at The docs:
Default Values
It's not always necessary to assign a value when a field is declared.
Fields that are declared but not initialized will be set to a
reasonable default by the compiler. Generally speaking, this default
will be zero or null, depending on the data type. Relying on such
default values, however, is generally considered bad programming
style.
The following chart summarizes the default values for the above data
types.
Data Type Default Value (for fields)
byte 0
short 0
int 0
long 0L
float 0.0f
double 0.0d char '\u0000' String (or any object) null
boolean false
Local variables are slightly different; the compiler never assigns a
default value to an uninitialized local variable. If you cannot
initialize your local variable where it is declared, make sure to
assign it a value before you attempt to use it. Accessing an
uninitialized local variable will result in a compile-time error.
When you declare local variables in a method, you have to assign them values before use them.
The Java compiler has to be convinced that when we get to the line HERE, it can prove that a, b, and c have been set to something:
boolean answerFound = false;
int a, b, c;
while (!answerFound) {
for (a = 1; a <= 1000; a++) {
for (b = a + 1; b <= 1000; b++) {
c = 1000 - a - b;
answerFound = determineIfPythagoreanTriple(a, b, c);
}
}
}
// HERE
From the compiler's point of view, if the loop is executed zero times, then it will get to HERE without the variables being initialized; therefore, you can't use them. We know that this is impossible, because we know that answerFound is initialized to false and therefore the loop will be executed at least once, and also that each for loop will be executed at least once. But the language has to have consistent rules to determine which programs are legal and which ones aren't; in order to keep things from being overly complex, the compiler isn't required to make the kinds of deductions that would be necessary to prove that a, b, and c are always initialized. I haven't looked at the actual "definite assignment" rules in detail, but I think they're already fairly complex.
So even though you know that the variables will be initialized, you can't convince the compiler of that. So just initialize them when they're declared.
int a = 0, b = 0, c = 0;
By the way, since the while is outside the for loops, this code will not exit right away when answerFound becomes true. It still executes the for loops until they're done, and only then does it test to see whether to leave the while loop. You'll need to solve that.
P.S. If you want to cheat, note that every Pythagorean triple has the form a = m2 - n2, b = 2mn, c = m2 + n2, for some m and n. You could actually get the answer without a computer, using algebra. But go ahead and finish the program you started--it's great practice.
As others have pointed out your variables a, b, c may not have been initialized by the time you get to System.out.println. There are several ways to avoid this.
Initialize variables explicitly, so:
int a = 0;
Use a do...while loop, which ensures your loop is run at least once, so:
do {
[...]
} while (!answerFound);
Use loop-scoped variables, which avoid local-scoped variables hanging around, so:
for (int a = 1; a <= 1000; a++) {
[...]
}
I was asked to write a swap without using temp variables or using xor and i came up with this.
In Java, this works, but in C/C++ this does not work.
I was under the impression that this would always work since the value of 'a' on the left side of the '|' would be stored in a register and then the assignment to 'a' would occur negating the effect on the assigned value for 'b'.
int a = 5;
int b = -13;
b = a | (0 & (a = b));
You are modifying a variable and reading its value without an intervening sequence point.
b = a + 0 * (a = b);
// reading a's value modifying a
This is undefined behavior. You have no right to any expectations on what the code will do.
The C/C++ compiler optimizes the expression 0 * (a = b) to simply 0 which turns your code fragment into:
int a = 5;
int b = -13;
b = a;
In C/C++, assigment are performed in the order of expression. In Java, assignments occur last regardless of other expressions.
e.g. This increments in C but does nothing in Java.
a = a++;