We Keep Coding

Java overloading with objects

I want to know why the second print statement produces "one implementation" as and output, below is the java code
class Point {
public boolean equals(final Object anObject) {
System.out.println("One implementation.");
return false;
}
public boolean equals(final Point aPoint) {
System.out.println("Another implementation.");
return false;
}
}
public class Main {
public static void main(final String[] args) {
final Point p1 = new Point();
final Point p2 = new Point();
final Object o = p1;
System.out.println(p1.equals(p2));
System.out.println(o.equals(p2));
System.out.println(p1.equals(o));
}
}
The output:-
Another implementation
false
One implementation {concern}
false
One implementation
false

The method
boolean equals(Object other);
overloads a base Object method; this method
boolean equals(Point other);
does not. So, when you call Object.equals(), which is what you're doing in your second case, you will end up in the first implementation you provided. Overriding Object.equals() is what you need to do as a minimum; other implementations are optional, and in my opinion, apt to mislead.
One should annotate overrides with #Override; this might help avoid confusion about whether a purported override really is.

You can use javap utility with -c -v flags to get better understanding what's going on, full command javap -c -v Main, its output (I truncated it) is
public static void main(java.lang.String[]);
Code:
0: new #2 // class Main$Point
3: dup
4: invokespecial #3 // Method Main$Point."<init>":()V
7: astore_1
8: new #2 // class Main$Point
11: dup
12: invokespecial #3 // Method Main$Point."<init>":()V
15: astore_2
16: aload_1
17: astore_3
18: getstatic #4 // Field java/lang/System.out:Ljava/io/PrintStream;
21: aload_1
22: aload_2
23: invokevirtual #5 // Method Main$Point.equals:(LMain$Point;)Z
26: invokevirtual #6 // Method java/io/PrintStream.println:(Z)V
29: getstatic #4 // Field java/lang/System.out:Ljava/io/PrintStream;
32: aload_3
33: aload_2
34: invokevirtual #7 // Method java/lang/Object.equals:(Ljava/lang/Object;)Z
37: invokevirtual #6 // Method java/io/PrintStream.println:(Z)V
40: getstatic #4 // Field java/lang/System.out:Ljava/io/PrintStream;
43: aload_1
44: aload_3
45: invokevirtual #8 // Method Main$Point.equals:(Ljava/lang/Object;)Z
48: invokevirtual #6 // Method java/io/PrintStream.println:(Z)V
51: return
In other words, Java compiler translated 2nd invocation into java/lang/Object.equals because type of o variable is Object. Java is statically typed language so all type resolutions happen at compile time so it does not matter if variable o will be assigned Point at run-time

Do Java enums allocate heap memory in the Android Runtime?

I was watching a video by two Android engineers talking about garbage collection in Android. In the introduction they do a little banter over enums. Romain Guy says: "I have to correct you there. Enums, they don't allocate. That's the whole point." At first, I that Romain just made a joke because enums work like this in other languages. But after this, Chet seems to concede that enums indeed to not allocate, but doing some "memory-related" stuff (implying: living on the stack). This reaction is what confuses me.
https://youtu.be/Zc4JP8kNGmQ?t=96
In my understanding, enums in Java are basically fixed collections of class-instances and seeing as Enum implements Object as good as object instantiations from a memory perspective, and so will be allocated to the heap.
But I can imagine that enums have some special status, owing to the strong properties the compiler can draw about them. Analogously, I know there are various optimizations for String like a shared pool for literals.
I am currently in the situation where I have fixed list of objects that I use as constants in my application. So I can implement this as an enum or as an array of class instantiations. Assuming readability is not an issue, would it be more performant to do the former?

Enums are objects. Like all objects, they live on the heap.
Indeed, if you decompile a simple enum, like:
enum Foo { A, B }
it looks like this (some stuff omitted):
static {};
Code:
0: new #4 // class Foo
3: dup
4: ldc #7 // String A
6: iconst_0
7: invokespecial #8 // Method "<init>":(Ljava/lang/String;I)V
10: putstatic #9 // Field A:LFoo;
13: new #4 // class Foo
16: dup
17: ldc #10 // String B
19: iconst_1
20: invokespecial #8 // Method "<init>":(Ljava/lang/String;I)V
23: putstatic #11 // Field B:LFoo;
26: iconst_2
27: anewarray #4 // class Foo
30: dup
31: iconst_0
32: getstatic #9 // Field A:LFoo;
35: aastore
36: dup
37: iconst_1
38: getstatic #11 // Field B:LFoo;
41: aastore
42: putstatic #1 // Field $VALUES:[LFoo;
45: return
which is basically the same as a class like this:
class Bar {
static final Bar A = new Bar("A");
static final Bar B = new Bar("B");
static final Bar[] $VALUES;
static {
Bar[] array = new Bar[2];
array[0] = A;
array[1] = B;
$VALUES = array;
}
private Bar(String name) {}
}
which decompiles to:
static {};
Code:
0: new #2 // class Bar
3: dup
4: ldc #3 // String A
6: invokespecial #4 // Method "<init>":(Ljava/lang/String;)V
9: putstatic #5 // Field A:LBar;
12: new #2 // class Bar
15: dup
16: ldc #6 // String B
18: invokespecial #4 // Method "<init>":(Ljava/lang/String;)V
21: putstatic #7 // Field B:LBar;
24: iconst_2
25: anewarray #2 // class Bar
28: astore_0
29: aload_0
30: iconst_0
31: getstatic #5 // Field A:LBar;
34: aastore
35: aload_0
36: iconst_1
37: getstatic #7 // Field B:LBar;
40: aastore
41: aload_0
42: putstatic #8 // Field $VALUES:[LBar;
45: return
There are a few other special things you get from an enum (like guarantees that they can't be creayed reflectively); but really, they are just regular objects.
The point that I think they are trying to make is that enums don't get allocated more than once (they are a good way to implement singetons, if you really need a singleton). So, you pay a small, fixed cost to load the enum class; but you can then reuse those same instances over and over.

Is it possible to re-reference any final String variable. Please clear me what is happening in given program

I have written a same program in two different way and both are giving me different output. i am not able to understand why.
please correct me.
In first program i am getting this output
Original: Umesh
Changed: Xmesh
And in second program i am getting this output.
Original: Umesh
Changed: Umesh
Program-1
import java.lang.reflect.Field;
public class SomeClass {
public static void main(final String[] args) throws Throwable {
final String s = "Umesh";
changeString(s);
}
// We need a method so the compiler won't inline "s":
static void changeString(final String s) throws Throwable {
System.out.println("Original: " + s);
final Field field = String.class.getDeclaredField("value");
field.setAccessible(true);
final char[] value = (char[]) field.get(s);
value[0] = 'X';
System.out.println("Changed: " + s);
}
}
Program-2
import java.lang.reflect.Field;
public class SomeClass {
public static void main(final String[] args) throws Throwable {
final String s = "Umesh";
System.out.println("Original: " + s);
final Field field = String.class.getDeclaredField("value");
field.setAccessible(true);
final char[] value = (char[]) field.get(s);
value[0] = 'X';
System.out.println("Changed: " + s);
}
}

I'll just start by saying you really, really shouldn't be mucking about with strings like that. :-)
In your first example you aren't "re-referencing" anything (that is, you're not changing what string s refers to), what you're doing is modifying the string it refers to. Even though officially strings are immutable, you're using reflection as a backdoor to modify the undocumented internals of the String implementation in Oracle's JDK (other JDKs may be implemented differently, making that code fail). But the s reference is unchanged. Even with reflection, you can't change the value of a final local variable. (You could change a final field via reflection, but doing so would open you up to the same sort of inconsistencies you're seeing in this example.)
What's happening in your second example is that since s is a final variable you give a literal value to within main, as far as the compiler is concerned, it's a compile-time constant, since String is officially immutable. The compiler is (very) aware of strings and does a fair bit of optimization around them, such as turning "a" + "b" + "c" into simply "abc". So later, when it sees "Original: " + s, it can happily just substitute "Original: Umesh" for that. And again at the end, when it sees "Changed: " + s it can replace that with "Changed: Umesh". It ends up being exactly as though you'd actually written System.out.println("Original: Umesh"); and System.out.println("Changed: Umesh"); in the source code.
The compiler couldn't do that in the first example because s is an argument to the function, rather than a final declared right there in main.
You can see the difference in the bytecode. Compile each of them, then disassemble them via javac -p SomeClass. Here's what I get (I called them Example1 and Example2):
$ javap -c Example1
Compiled from "Example1.java"
public class Example1 {
public Example1();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."":()V
4: return
public static void main(java.lang.String[]) throws java.lang.Throwable;
Code:
0: ldc #2 // String Umesh
2: invokestatic #3 // Method changeString:(Ljava/lang/String;)V
5: return
static void changeString(java.lang.String) throws java.lang.Throwable;
Code:
0: getstatic #4 // Field java/lang/System.out:Ljava/io/PrintStream;
3: new #5 // class java/lang/StringBuilder
6: dup
7: invokespecial #6 // Method java/lang/StringBuilder."":()V
10: ldc #7 // String Original:
12: invokevirtual #8 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
15: aload_0
16: invokevirtual #8 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
19: invokevirtual #9 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
22: invokevirtual #10 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
25: ldc #11 // class java/lang/String
27: ldc #12 // String value
29: invokevirtual #13 // Method java/lang/Class.getDeclaredField:(Ljava/lang/String;)Ljava/lang/reflect/Field;
32: astore_1
33: aload_1
34: iconst_1
35: invokevirtual #14 // Method java/lang/reflect/Field.setAccessible:(Z)V
38: aload_1
39: aload_0
40: invokevirtual #15 // Method java/lang/reflect/Field.get:(Ljava/lang/Object;)Ljava/lang/Object;
43: checkcast #16 // class "[C"
46: checkcast #16 // class "[C"
49: astore_2
50: aload_2
51: iconst_0
52: bipush 88
54: castore
55: getstatic #4 // Field java/lang/System.out:Ljava/io/PrintStream;
58: new #5 // class java/lang/StringBuilder
61: dup
62: invokespecial #6 // Method java/lang/StringBuilder."":()V
65: ldc #17 // String Changed:
67: invokevirtual #8 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
70: aload_0
71: invokevirtual #8 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
74: invokevirtual #9 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
77: invokevirtual #10 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
80: return
}
and
$ javap -c Example2
Compiled from "Example2.java"
public class Example2 {
public Example2();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."":()V
4: return
public static void main(java.lang.String[]) throws java.lang.Throwable;
Code:
0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #3 // String Original: Umesh
5: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: ldc #5 // class java/lang/String
10: ldc #6 // String value
12: invokevirtual #7 // Method java/lang/Class.getDeclaredField:(Ljava/lang/String;)Ljava/lang/reflect/Field;
15: astore_2
16: aload_2
17: iconst_1
18: invokevirtual #8 // Method java/lang/reflect/Field.setAccessible:(Z)V
21: aload_2
22: ldc #9 // String Umesh
24: invokevirtual #10 // Method java/lang/reflect/Field.get:(Ljava/lang/Object;)Ljava/lang/Object;
27: checkcast #11 // class "[C"
30: checkcast #11 // class "[C"
33: astore_3
34: aload_3
35: iconst_0
36: bipush 88
38: castore
39: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
42: ldc #12 // String Changed: Umesh
44: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
47: return
}
Notice how we don't see any string concatenation (StringBuilder usage) in the second example, the compiler combined the static strings at the compilation stage.

In the 2nd case, "Changed: " + s is a constant expression, the value is computed at compile time. It must be treated the same as the String literal "Changed: Umesh". (you can test that by ==)
In the 1st case, while aggressive optimzations are allowed on final fields , you are not actually modifying any final fields. You are writing to an array element, which is not final. This write must be visible to subsequent reads in the same thread.

Using .append(string1 + string 2) vs .append(string1).append(string2)

I am wondering if anyone could give me an answer as to which one of these statements would perform better in java using StringBuilder object:
Using
.append(string1 + string 2)
vs
.append(string1).append(string2)

The second option will almost certainly be superior (assuming there is any noticeable performance difference at all). When you write something like
string1 + string2
it is internally translated to
new StringBuilder(string1).append(string2).toString()
i.e. a new StringBuilder is created to concatenate the strings. Your second variant circumvents this issue since it appends directly to the existing StringBuilder, avoiding the creation of a new one.

We can take a look at the bytecode for each option:
public class Concat {
private static String s1 = "foo";
private static String s2 = "bar";
public static String good() {
StringBuilder b = new StringBuilder();
b.append(s1).append(s2);
return b.toString();
}
public static String bad() {
StringBuilder b = new StringBuilder();
b.append(s1 + s2);
return b.toString();
}
}
$javap -c Concat.class
public static java.lang.String good();
Code:
0: new #2 // class java/lang/StringBuilder
3: dup
4: invokespecial #3 // Method java/lang/StringBuilder."<init>":()V
7: astore_0
8: aload_0
9: getstatic #4 // Field s1:Ljava/lang/String;
12: invokevirtual #5 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
15: getstatic #6 // Field s2:Ljava/lang/String;
18: invokevirtual #5 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
21: pop
22: aload_0
23: invokevirtual #7 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
26: areturn
public static java.lang.String bad();
Code:
0: new #2 // class java/lang/StringBuilder
3: dup
4: invokespecial #3 // Method java/lang/StringBuilder."<init>":()V
7: astore_0
8: aload_0
9: new #2 // class java/lang/StringBuilder
12: dup
13: invokespecial #3 // Method java/lang/StringBuilder."<init>":()V
16: getstatic #4 // Field s1:Ljava/lang/String;
19: invokevirtual #5 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
22: getstatic #6 // Field s2:Ljava/lang/String;
25: invokevirtual #5 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
28: invokevirtual #7 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
31: invokevirtual #5 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
34: pop
35: aload_0
36: invokevirtual #7 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
39: areturn
Your first option actually becomes append(new StringBuilder().append(s1).append(s2).toString()).

The first one is quicker to type and in many situations easier to read.
The second one may perform marginally better (as per Jeffrey's bytecode and arshajii's explanation).
However, this kind string concatenation is very unlikely to be the bottleneck in your system! If performance is a problem, you need to profile. Compilers differ. And improving algorithms generally has much, much more impact than this kind of micro-optimization.
Don't optimize earlier than necessary! Really! It's so tempting and such a waste of time.

It may be reasonably expected that a future improvement in the compiler will make both alternatives generate the same code.

Enums - static and instance blocks

I had learned that in Java the static block gets executed when the class is initialized and instance block get executed before the construction of each instance of the class . I had always seen the static block to execute before the instance block . Why the case is opposite for enums ?
Can anyone please explain me the output of the sample code :
enum CoffeeSize {
BIG(8), LARGE(10),HUGE(12),OVERWHELMING();
private int ounces ;
static {
System.out.println("static block ");
}
{
System.out.println("instance block");
}
private CoffeeSize(int ounces){
this.ounces = ounces;
System.out.println(ounces);
}
private CoffeeSize(){
this.ounces = 20;
System.out.println(ounces);
}
public int getOunces() {
return ounces;
}
}
Output:
instance block
8
instance block
10
instance block
12
instance block
20
static block

You need to know that enum values are static fields which hold instances of that enum type, and initialization order of static fields depends on their position.
See this example
class SomeClass{
public SomeClass() { System.out.println("creating SomeClass object"); }
}
class StaticTest{
static{ System.out.println("static block 1"); }
static SomeClass sc = new SomeClass();
static{ System.out.println("static block 2"); }
public static void main(String[] args) {
new StaticTest();
}
}
output
static block 1
creating SomeClass object
static block 2
Now since enum values are always placed at start of enum type, they will always be called before any static initialization block, because everything else can only be declared after enum values.
BUT initialization of enum values (which happens at class initialization) their constructors are called and as you said non-static initialization blocks are executed at start of every constructor which is why you see them:
for every enum value
and before any static initialization block.

Little late and building up on Pshemo's answer. The output of the (compiling) code below is as follows:
8
10
Foo
static block
Bar
So the enum constant initializations are executed first (as Pshemo said, they are always implicitly static and final, see second blockquote) and then all fields explicitly declared as static are initialized. As mentioned, the language specification says this about the order of execution during class initialization and about enum constants:
Next, execute either the class variable initializers and static initializers of the class, or the field initializers of the interface, in textual order, as though they were a single block.
In addition to the members that an enum type E inherits from Enum, for each declared enum constant with the name n, the enum type has an implicitly declared public static final field named n of type E. These fields are considered to be declared in the same order as the corresponding enum constants, before any static fields explicitly declared in the enum type.
class StaticTest {
enum CoffeeSize {
BIG(8), LARGE(10);
private int ounces;
static Foo foo = new Foo();
static { System.out.println("static block "); }
static Bar bar = new Bar();
private CoffeeSize(int ounces){
this.ounces = ounces;
System.out.println(ounces);
}
}
public static void main(String[] args) {
CoffeeSize cs = CoffeeSize.LARGE;
}
}
class Foo { public Foo() { System.out.println("Foo"); } }
class Bar { public Bar() { System.out.println("Bar"); } }

Use bytecode to make out this problem.
import java.util.ArrayList;
import java.util.List;
public enum EnumDemo {
ONE(1), TWO(2);
private final static List<Integer> vals;
static {
System.out.println("fetch instance from static");
vals = new ArrayList<>();
EnumDemo[] values = EnumDemo.values();
for (EnumDemo value : values) {
vals.add(value.val);
}
}
private int val;
EnumDemo(int val){
this.val = val;
System.out.println("create instance:" + val);
}
}
use javac compile to class file, and then javap -c EnumDemo.class, got this:
Compiled from "EnumDemo.java"
public final class EnumDemo extends java.lang.Enum<EnumDemo> {
public static final EnumDemo ONE;
public static final EnumDemo TWO;
public static EnumDemo[] values();
Code:
0: getstatic #1 // Field $VALUES:[LEnumDemo;
3: invokevirtual #2 // Method "[LEnumDemo;".clone:()Ljava/lang/Object;
6: checkcast #3 // class "[LEnumDemo;"
9: areturn
public static EnumDemo valueOf(java.lang.String);
Code:
0: ldc_w #4 // class EnumDemo
3: aload_0
4: invokestatic #5 // Method java/lang/Enum.valueOf:(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Enum;
7: checkcast #4 // class EnumDemo
10: areturn
static {};
Code:
0: new #4 // class EnumDemo
3: dup
4: ldc #16 // String ONE
6: iconst_0
7: iconst_1
8: invokespecial #17 // Method "<init>":(Ljava/lang/String;II)V
11: putstatic #18 // Field ONE:LEnumDemo;
14: new #4 // class EnumDemo
17: dup
18: ldc #19 // String TWO
20: iconst_1
21: iconst_2
22: invokespecial #17 // Method "<init>":(Ljava/lang/String;II)V
25: putstatic #20 // Field TWO:LEnumDemo;
28: iconst_2
29: anewarray #4 // class EnumDemo
32: dup
33: iconst_0
34: getstatic #18 // Field ONE:LEnumDemo;
37: aastore
38: dup
39: iconst_1
40: getstatic #20 // Field TWO:LEnumDemo;
43: aastore
44: putstatic #1 // Field $VALUES:[LEnumDemo;
47: getstatic #8 // Field java/lang/System.out:Ljava/io/PrintStream;
50: ldc #21 // String fetch instance from static
52: invokevirtual #15 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
55: new #22 // class java/util/ArrayList
58: dup
59: invokespecial #23 // Method java/util/ArrayList."<init>":()V
62: putstatic #24 // Field vals:Ljava/util/List;
65: invokestatic #25 // Method values:()[LEnumDemo;
68: astore_0
69: aload_0
70: astore_1
71: aload_1
72: arraylength
73: istore_2
74: iconst_0
75: istore_3
76: iload_3
77: iload_2
78: if_icmpge 109
81: aload_1
82: iload_3
83: aaload
84: astore 4
86: getstatic #24 // Field vals:Ljava/util/List;
89: aload 4
91: getfield #7 // Field val:I
94: invokestatic #26 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
97: invokeinterface #27, 2 // InterfaceMethod java/util/List.add:(Ljava/lang/Object;)Z
102: pop
103: iinc 3, 1
106: goto 76
109: return
}
So, enum instance is the static instance, and at the head.

1. An enum type is a type whose fields consist of a fixed set of constants. Common examples include compass directions (values of NORTH, SOUTH, EAST, and WEST) and the days of the week.
2. They are static final constant, therefore have all letters in Caps.
3. And static variables are initialized as soon as the JVM loads the class.
For further details see this link:
http://docs.oracle.com/javase/1.5.0/docs/guide/language/enums.html