Java: How does the == operator work when comparing int? - java

Given this Java code:
int fst = 5;
int snd = 6;
if(fst == snd)
do something;
I want to know how Java will compare equality for this case. Will it use an XOR operation to check equality?

Are you asking "what native machine code does this turn into?"? If so, the answer is "implementation-depdendent".
However, if you want to know what JVM bytecode is used, just take a look at the resulting .class file (use e.g. javap to disassemble it).

In case you are asking about the JVM, use the javap program.
public class A {
public static void main(String[] args) {
int a = 5;
System.out.println(5 == a);
}
}
Here is the disassembly:
public class A {
public A();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: iconst_5
1: istore_1
2: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
5: iconst_5
6: iload_1
7: if_icmpne 14
10: iconst_1
11: goto 15
14: iconst_0
15: invokevirtual #3 // Method java/io/PrintStream.println:(Z)V
18: return
}
In this case it optimized the branching a bit and used if_icmpne. In most cases, it will use if_icmpne or if_icmpeq.
if_icmpeq : if ints are equal, branch to instruction at branchoffset (signed short constructed from unsigned bytes branchbyte1 << 8 + branchbyte2)
if_icmpn : if ints are not equal, branch to instruction at branchoffset (signed short constructed from unsigned bytes branchbyte1 << 8 + branchbyte2)

Related

What function is more efficient?

I'm new to Java and i wanted to know if there is a difference between these 2 functions:
public static String function1(int x) {
String res = "";
if(x > 10)
res = "a";
else
res = "b";
return res;
}
and:
public static String function2(int x) {
if(x > 10)
return "a";
return "b";
}
and I'm not speaking on the length of the code, only efficiency.
The second version is in theory more efficient, decompiling to:
public static java.lang.String function1(int);
Code:
0: ldc #2 // String
2: astore_1
3: iload_0
4: bipush 10
6: if_icmple 12
9: ldc #3 // String a
11: areturn
12: ldc #4 // String b
14: areturn
whereas the version with the assignment decompiles to:
public static java.lang.String function1(int);
Code:
0: ldc #2 // String
2: astore_1
3: iload_0
4: bipush 10
6: if_icmple 15
9: ldc #3 // String a
11: astore_1
12: goto 18
15: ldc #4 // String b
17: astore_1
18: aload_1
19: areturn
where it can be seen that the additional variable is created and returned.
However in practise the difference in actual runtime performance should be negligible. The JIT compiler would (hopefully) optimise away the useless variable, and in any case unless the code was in a hot code path according to your profiler then this would certainly count as premature optimisation.
Both versions end up creating a string either "a" or "b" and return it out.
But version 2 is better in term of efficiency, which doesn't create an redundant empty string "" in memory.

Can we use the + sign to add a string literal in a StringBuffer?

StringBuffer sb = new StringBuffer();
sb.append("New "+"Delhi");
and other is:
sb.append("New ").append("Delhi");
both will print "New Delhi".
Which one is better and why?
Because some times to save time I use "+" instead of ".append".
sb.append("New "+"Delhi"):
public class Test {
public Test();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: new #2 // class java/lang/StringBuffer
3: dup
4: invokespecial #3 // Method java/lang/StringBuffer."<init>":()V
7: astore_1
8: aload_1
9: ldc #4 // String New Delhi
11: invokevirtual #5 // Method java/lang/StringBuffer.append:(Ljava/lang/String;)Ljava/lang/StringBuffer;
14: pop
15: return
}
sb.append("New ").append("Delhi"):
Compiled from "Test.java"
public class Test {
public Test();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: new #2 // class java/lang/StringBuffer
3: dup
4: invokespecial #3 // Method java/lang/StringBuffer."<init>":()V
7: astore_1
8: aload_1
9: ldc #4 // String New
11: invokevirtual #5 // Method java/lang/StringBuffer.append:(Ljava/lang/String;)Ljava/lang/StringBuffer;
14: ldc #6 // String Delhi
16: invokevirtual #5 // Method java/lang/StringBuffer.append:(Ljava/lang/String;)Ljava/lang/StringBuffer;
19: pop
20: return
}
As the above bytecode, for static string:
when using "+", the javac compiler will auto concat it a String.
when using "append", the javac compiler will auto expand as two String variables.
so for static string, the "+" is good for using.
"+" sign is used to add a string at the end of another string. Now, as per your question, whenever append() is used with String Buffer to append character sequence or string at that time append function internally performing to concatenate string using "+" sign.
any string append operation is converted into StringBuilder internally like
"The answer is: " + value
is converted into :
new StringBuilder("The answer is: ")).append(value).toString()
If any expression getting concatenated is not constant , .append is a better approach.
so in your case doesn't matter performance wise which way you write. Only '+' will improve readability of your code.
Constant string concatenations will be replaced at compile-time.
You should use a Stringbuilder/Stringbuffer if you concatenate variable strings e.g. variables, especially when you do the concatenations in a loop.

JVM bug? Cached Object field value cause ArrayIndexOutOfBoundsException

This is kind of strange, but code speaks more then words, so look at the test to see what I'm doing. In my current setup (Java 7 update 21 on Windows 64 bit) this test fails with ArrayIndexOutOfBoundsException, but replacing the test method code with the commented code, it the works. And I wonder if there is any part of the Java specification that would explain why.
It seems to me, as "michael nesterenko" suggested, that the value of the array field is cached in the stack, before calling the method, and not updated on return from the call. I can't tell if it's a JVM bug or a documented "optimisation". No multi-threading or "magic" involved.
public class TestAIOOB {
private String[] array = new String[0];
private int grow(final String txt) {
final int index = array.length;
array = Arrays.copyOf(array, index + 1);
array[index] = txt;
return index;
}
#Test
public void testGrow() {
//final int index = grow("test");
//System.out.println(array[index]);
System.out.println(array[grow("test")]);
}
}
This is well defined by the Java Language Specification: to evaluate x[y], first x is evaluated, and then y is evaluated. In your case, x evaluates to a String[] with zero elements. Then, y modifies a member variable, and evaluates to 0. Trying to access the 0th element of the already-returned array fails. The fact that the member array changes has no bearing on the array lookup, because we're looking at the String[] that array referenced at the time we evaluated it.
This behavior is mandated by the JLS. Per 15.13.1, "An array access expression is evaluated using the following procedure: First, the array reference expression is evaluated. If this evaluation completes abruptly, then the array access completes abruptly for the same reason and the index expression is not evaluated. Otherwise, the index expression is evaluated. [...]".
Compare the compiled Java code by using javap -c TestAIOOB
Uncommented code:
public void testGrow();
Code:
0: getstatic #6; //Field java/lang/System.out:Ljava/io/PrintStream;
3: aload_0
4: getfield #3; //Field array:[Ljava/lang/String;
7: aload_0
8: ldc #7; //String test
10: invokespecial #8; //Method grow:(Ljava/lang/String;)I
13: aaload
14: invokevirtual #9; //Method java/io/PrintStream.println:(Ljava/lang/St
ing;)V
17: return
Commented code:
public void testGrow();
Code:
0: aload_0
1: ldc #6; //String test
3: invokespecial #7; //Method grow:(Ljava/lang/String;)I
6: istore_1
7: getstatic #8; //Field java/lang/System.out:Ljava/io/PrintStream;
10: aload_0
11: getfield #3; //Field array:[Ljava/lang/String;
14: iload_1
15: aaload
16: invokevirtual #9; //Method java/io/PrintStream.println:(Ljava/lang/Str
ing;)V
19: return
In the first the getfield happens before the call to grow and in the second it happens after.

significance of && in if()

I would like to know is there any difference in performance between these two codes.
String sample="hello";
if(sample!=null)
{
if(!sample.equals(""))
{
// some code in here
}
}
or
String sample="hello";
if(sample!=null && !sample.equals(""))
{
// some code in here
}
As far as i have understood, in the first code, if sample is not null then only it will go in to the block. same is the case with 2nd piece of code.
What i would like to know is what is the difference in performance or better coding standards and why?
If you're asking about performance you should always measure. But No, there shouldn't be a difference. Besides, if that is your only performance-problematic code then I envy you, seriously.
As for coding standards. Less nesting is almost always nicer to read and follow. Which means that putting both in a single if, especially since they are related is preferrable. The pattern
if (check_foo_for_null && compare_foo)
is very common and thus much less surprising than another nested if.
EDIT: To back it up:
I have the two little methods:
static boolean x(String a) {
if (a != null && a.equals("Foo"))
return true;
else return false;
}
static boolean y(String a) {
if (a != null) {
if (a.equals("Foo")) {
return true;
} else return false;
} else return false;
}
which produce the following code:
static boolean x(java.lang.String);
Code:
0: aload_0
1: ifnull 15
4: aload_0
5: ldc #16 // String Foo
7: invokevirtual #21 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
10: ifeq 15
13: iconst_1
14: ireturn
15: iconst_0
16: ireturn
static boolean y(java.lang.String);
Code:
0: aload_0
1: ifnull 17
4: aload_0
5: ldc #16 // String Foo
7: invokevirtual #21 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
10: ifeq 15
13: iconst_1
14: ireturn
15: iconst_0
16: ireturn
17: iconst_0
18: ireturn
So apart from an extraneous else jump target the code is identical. If you don't even have the else:
static boolean z(String a) {
if (a != null) {
if (a.equals("Foo"))
return true;
return false;
}
then the result is really the same:
static boolean z(java.lang.String);
Code:
0: aload_0
1: ifnull 15
4: aload_0
5: ldc #16 // String Foo
7: invokevirtual #21 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
10: ifeq 15
13: iconst_1
14: ireturn
15: iconst_0
16: ireturn
As everyone else said, there shouldn't be any difference in preformance.
Small tip - equals almost always calls instanceof which returns false for null.
So writing:
if( !"".equals(foo)) {...}
does same check and is null-safe.
Bothe have no difference in terms of performance. Because in first case it checks one condition, if fails it does not enter inside. In 2nd case also, JVM checks the first condition, if it return false, then JVM will never go for 2nd check. As logical && operator will always false if first is false.
In terms of coding standard, I will choose 2nd option, as it has less number of coding lines.
Most likely the bytcode generated will be optimized to if(sample!=null && !sample.equals("")) since java performs an optimization in compile time.
If you are talking about the actual code you write it is better to have only one if. Since the structure of two if is more complex for the compiler (with no optimization). Although I have no empiric data to back this.

Is it possible to differentiate between character and integer stored in the same integer array?

My code is
int array[] = {'a',98};
for(int num:array) {
System.out.println(num);
}
If I print this, I'll get o/p as 97 98.
If I print (char) num then o/p will be a b.
Is it possible to print the array as a 98? My guess is as array will store integer values of the array elements, it is not possible. But any solution here?
I don't think there is any way to do it with int[]. But you can create Object[] to achieve this.
Here is the code snippet:
public static void main (String[] args) throws Exception {
Object array[] = {'a',98};
for(Object o : array){
System.out.println(o);
}
}
Output:
a
98
You have int[] array, that's how the bytecode looks:
public class Test {
public Test();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: iconst_2
1: newarray int
3: dup
4: iconst_0
5: bipush 97
7: iastore
8: dup
9: iconst_1
10: bipush 98
12: iastore
13: astore_1
14: return
}
As you can see, values are inserted as int.
Other users suggested using Object[] array. Look at the bytecode of it:
public class Test {
public Test();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: iconst_2
1: anewarray #2 // class java/lang/Object
4: dup
5: iconst_0
6: bipush 97
8: invokestatic #3 // Method java/lang/Character.valueOf:(C)Ljava/lang/Character;
11: aastore
12: dup
13: iconst_1
14: bipush 98
16: invokestatic #4 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
19: aastore
20: astore_1
21: return
}
Note the
// Method java/lang/Character.valueOf:(C)Ljava/lang/Character;
line, which tells that the method Character.valueOf is invoked, so you'll get the actual character instead of its int value.
No, it is not possible for an int[] to know if its data was written as a character or as a number in the source code. You need a different data structure if you wish to keep that kind of information.
Object[] array = { 'a', 98 }
if (array[i] instanceof Character) { // Or Integer

Categories