My new thing learnt for today - Java related

PaulStat · 20 Jan 2009 at 14:15

Currently studying for my SCJP exam, the material they provide you with to study is quite clearly rubbish as it covers no where near enough detail about the nuances of Java. For example

Code:

interface Jumpable {
  int height = 5;
  void jump();
}
class Jumper implements Jumpable {
  public Jumper(int height) {
     height = 10;
  }
  protected void jump() {}
}

Spot the errors in the above code, a little test for you

But anyway that's not what I learnt today, given the following code

Code:

Bob bob1 = new Bob();
bob1.setHeight(10);
System.out.println("bob1 height: " + bob1.getHeight());
Bob bob2 = bob1;
bob2.setHeight(20);
System.out.println("bob1 height: " + bob1.getHeight());

Produces the output:

bob1 height: 10
bob1 height: 20

What does the following code output

Code:

String str1 = "Hello";
System.out.println(str1);
String str2 = str1;
str2 += " World";
System.out.println(str1);

You lot probably already know this, but scroll down to see the answer

Hello
Hello

Despite the fact that the str2 reference variable refers to the same object, when you make a change to the reference variable the JVM refers it to a different string object so the other string isn't changed!

Dj_Jestar · 20 Jan 2009 at 14:54

+= is a reassignment operator, so the reference to str1 is lost in favour of the new string of str1 + " World". It's the exact same as doing:

Code:

String str1 = "Hello";
String str2 = str1;
str2 = str1 + " World"; // this line reassigns
System.out.print(str1); // str1 is unchanged and is still "Hello"

Ergo, the String str2 = str1; line is superfluous.

and regards to the interface, protected is not public, so it breaks the interface.

This is where I get hideously shown up because I'm completely wrong

PaulStat · 20 Jan 2009 at 15:08

Dj_Jestar said:
and regards to the interface, protected is not public, so it breaks the interface.

This is where I get hideously shown up because I'm completely wrong

Yup there's one of the errors, there are more

Dj_Jestar · 20 Jan 2009 at 15:16

the value is not implemented.

PaulStat · 20 Jan 2009 at 15:22

Dj_Jestar said:
the value is not implemented.

heh, ummm slight mistake, what I really meant to type for the constructor was

Code:

public Jumper(int height) {
   height = 10;
}

PaulStat · 20 Jan 2009 at 15:39

Put you out of your missery

the integer in the interface is implicitly 'public static final', so you can't change the value i.e. height = 10

Dfhaii · 20 Jan 2009 at 22:04

Wouldn't the height = 10 there be changing the value of the parameter to the method, rather than attempting to change the one in the interface, which would be this.height?

PaulStat · 20 Jan 2009 at 22:54

Dfhaii said:
Wouldn't the height = 10 there be changing the value of the parameter to the method, rather than attempting to change the one in the interface, which would be this.height?

nope, as Jumper implements Jumpable, Jumper IS-A Jumpable, and seeing as interface constants are implicitly public final static you can just refer to height. Just did a test to be sure.

This code:

Code:

interface Jumpable {
	int height = 10;
	void jump();
}
public class TestClass implements Jumpable {
  public TestClass() {
  	height = 20;
  }
  public void jump() {}
}

Gives the following compilation error

TestClass.java:7: cannot assign a value to final variable height
height = 20;
^
1 error

EDIT:

Sorry just read what you typed again, yes it should have read

Code:

public Jumper(int height) {
   this.height = height;
}

JonB · 21 Jan 2009 at 01:07

PaulStat said:
But anyway that's not what I learnt today, given the following code

Code:

Bob bob1 = new Bob(); bob1.setHeight(10); System.out.println("bob1 height: " + bob1.getHeight()); Bob bob2 = bob1; bob2.setHeight(20); System.out.println("bob1 height: " + bob1.getHeight());

Produces the output:

bob1 height: 10
bob1 height: 20

It's because you're making a shallow copy of the object and not a deep copy. 'bob2' just becomes a reference to 'bob1' rather than taking a complete, separate copy.

EDIT: Not sure i've used the correct terminology here but oh well. Java classes were so Level 1.

PaulStat · 21 Jan 2009 at 20:59

Next question, given the following code in what order does the output appear

Code:

class A {
  { System.out.println("Class A"); }
  public A() { System.out.println("In class A"); }
  static { System.out.println("Static A"); }
}
class B extends A {
  static { System.out.println("Static B"); }
  public B() { System.out.println("In class B"); }
}
public class InitBlocks extends B {
   public static void main(String [] args) {
    new InitBlocks();
    System.out.println("Welcome to the main method");
   }
   static { System.out.println("Static initblocks"); }
}

Dfhaii · 21 Jan 2009 at 21:34

I think it'd be the three statics in the order they're written, then class a, then in class a, in class b and welcome to the main method. I think this because the static bits will be done at first run, then the "class a" will come when class a is loaded by the class loader (caused by the new InitBlocks call and following constructor calls), then the new InitBlocks will call the b constructor which'll call the a constructor to print those.

apeZ · 21 Jan 2009 at 22:14

Java reads top to bottom, so I also assume that it will print them in the order that they are displayed in the code.

PaulStat · 22 Jan 2009 at 09:14

Dfhaii said:
I think it'd be the three statics in the order they're written, then class a, then in class a, in class b and welcome to the main method. I think this because the static bits will be done at first run, then the "class a" will come when class a is loaded by the class loader (caused by the new InitBlocks call and following constructor calls), then the new InitBlocks will call the b constructor which'll call the a constructor to print those.

So you're saying

Static A
Static B
Static initblocks
Class A
In class A
in class B
welcome to the main method

Correct!