About Question enthuware.ocajp.i.v7.2.1403 :

Help and support on OCA OCP Java Programmer Certification Questions
1Z0-808, 1Z0-809, 1Z0-815, 1Z0-816, 1Z0-817

Moderator: admin

toolforger
Posts: 38
Joined: Fri Nov 13, 2015 4:40 am
Contact:

About Question enthuware.ocajp.i.v7.2.1403 :

Post by toolforger » Wed Nov 18, 2015 2:44 am

TestClass accesses m.location, which is a package-private member in a different package, so I had expected it to not compile.
Did I overlook something?

admin
Site Admin
Posts: 8703
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by admin » Wed Nov 18, 2015 2:53 am

Did you read the explanation? It explains exactly what you are asking.
If you like our products and services, please help us by posting your review here.

toolforger
Posts: 38
Joined: Fri Nov 13, 2015 4:40 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by toolforger » Wed Nov 18, 2015 3:33 am

There is no explanation on that question.

admin
Site Admin
Posts: 8703
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by admin » Wed Nov 18, 2015 3:46 am

That is surprising. Could you please confirm that you do not see this?
2.1403.png
2.1403.png (25.45 KiB) Viewed 9040 times
If you like our products and services, please help us by posting your review here.

toolforger
Posts: 38
Joined: Fri Nov 13, 2015 4:40 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by toolforger » Wed Nov 18, 2015 6:14 am

The explanation is actually there. It got cut off because the window was just large enough to show the "Explanation" title but not the explanation text. Somehow I didn't "get" the visual feedback to indicate that I need to scroll; maybe because there's no line between the scrollable area and the fixed "Previous/Next/Review/Discuss" area.
I'll do a screenshot if you wish (I'm not properly equipped for that on this machine).

Anyway. Thanks for the language rule explanation, I now understand what was wrong.
Now I need to go and find James Gosling to whack him for this and similarly "helpful" language exceptions... :-D

ahauge
Posts: 1
Joined: Mon Sep 26, 2016 12:53 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by ahauge » Mon Sep 26, 2016 12:58 pm

Since variables defined in an interface are implicitly final, why is it legal to modify the location variable in the donkey class?
Thanks!

admin
Site Admin
Posts: 8703
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by admin » Mon Sep 26, 2016 8:14 pm

ahauge wrote:Since variables defined in an interface are implicitly final, why is it legal to modify the location variable in the donkey class?
Thanks!
It is indeed not legal to modify the variables of an interface because they are final. But that is not what the code is doing. The code is modifying the "instance" variable of Donkey class. It is not an interface.

HTH,
Paul.
If you like our products and services, please help us by posting your review here.

blackdraft
Posts: 3
Joined: Thu Sep 29, 2016 7:38 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by blackdraft » Thu Sep 29, 2016 8:48 am

Why is it the movables location that gets printed and not the donkeys? Java does now that m.move(10) and m.moveback(20) refer to the donkey object but suddenly thinks that it should use movables location value? Why and what exactly is the difference between the methods and instance variable in this case and why are they treated different?

toolforger
Posts: 38
Joined: Fri Nov 13, 2015 4:40 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by toolforger » Thu Sep 29, 2016 9:23 am

The base topic of this question is that you're being alerted to the fact that "this.foo" may really be an access to "SomeClass.foo". Or "SomeInterface.foo". Which is pretty different from a member variable, because static variables exist only once per class (or once per interface if defined in an interface), not once per instantiated object.
The question also alerts you to the fact the member variables declared in classes are nonstatic (i.e. per-object) by default, while member variables declared in interfaces are static (i.e. per-interface). (The background for this is that the Java designers had no idea how to combine nonstatic member variables and multiple inheritance without running into nasty semantics problems. For this reason, you have class inheritance where you can get nonstatic member variables but cannot do multiple inheritance, and interfaces that give you multiple inheritance but not member variables. So in Java, it's a fundamental design decision that interfaces cannot have member variables because they would be inherited, so any variable declared in an interface must be static, whether you add the "static" keyword or not.)

admin
Site Admin
Posts: 8703
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by admin » Thu Sep 29, 2016 5:57 pm

blackdraft wrote:Why is it the movables location that gets printed and not the donkeys? Java does now that m.move(10) and m.moveback(20) refer to the donkey object but suddenly thinks that it should use movables location value? Why and what exactly is the difference between the methods and instance variable in this case and why are they treated different?
The fundamental difference between instance method invocation and variable access ( and static method invocation) is that instance method invocations are polymorphic and are therefore bound at run time while variable access is bound at compile time. In other words, in case of instance method invocation, it is the JVM that determines at run time (based on the class of the actual object referred to by the reference variable) which version of the method is to be called, but in case of variables, it is the compiler that determines which variable is to be accessed (based on the declared class of the reference variable).

Thus, in case of m.location, the compiler has already made the determination that interface Movable's location should be accessed because the declared class of m is Movable. But in case of m.move() or m.moveBack(), it is the JVM that determines that Donkey's methods should be used because the class of the actual object referred to by m is Donkey.

HTH,
Paul.
If you like our products and services, please help us by posting your review here.

blackdraft
Posts: 3
Joined: Thu Sep 29, 2016 7:38 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by blackdraft » Fri Sep 30, 2016 3:19 am

Thanks, that makes it more clear.
I think you meant compile-time instead of the second runtime in your second sentence Paul?

admin
Site Admin
Posts: 8703
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by admin » Fri Sep 30, 2016 10:35 am

Right, corrected. Sorry about that :(
If you like our products and services, please help us by posting your review here.

java_learner
Posts: 6
Joined: Sun Feb 05, 2017 3:42 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by java_learner » Sun Feb 05, 2017 3:50 pm

So what would we need to do in order access the Donkeys location instance-variable?

I see that we could write a getter in the Donkey class. But I wonder if there is some other way - I mean what if we made Donkeys location public? Would the instance variable even then not be accessible? I assume you still would not be able to access it from the TestClass (except maybe via reflection?)

admin
Site Admin
Posts: 8703
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by admin » Sun Feb 05, 2017 10:44 pm

To access's Donkey's location instance variable, cast your reference to Donkey first. Like so:
((Donkey)m).location
If you like our products and services, please help us by posting your review here.

acarella610
Posts: 1
Joined: Sun Mar 19, 2017 1:24 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by acarella610 » Sun Mar 19, 2017 1:32 pm

I'm curious. How would we then access Donkey's location variable, aside from making Donkey getter and setter methods?

EDIT: Didn't see the above answer. Reading and testing now.

rodtwo
Posts: 1
Joined: Sat Nov 18, 2017 10:18 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by rodtwo » Sun Nov 26, 2017 10:25 am

I have only one doubt, I tought the code woudn't compile because we are hiding a static field using an instance field... Is it allowed when hiding fields, it's only forbidden when overriding methods to change from static to instance?

Thanks and regards

admin
Site Admin
Posts: 8703
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by admin » Sun Nov 26, 2017 11:39 pm

Yes, it is ok to hide static field with an instance field (and vice-versa). You can't do that with methods. You should try writing small test programs to confirm your understanding of the concepts.

HTH,
Paul.
If you like our products and services, please help us by posting your review here.

kevin35
Posts: 8
Joined: Mon Dec 25, 2017 4:30 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by kevin35 » Sun Dec 31, 2017 8:40 am

Code: Select all

//assume the classes are in seperate files, same package
public interface I {	
	default void foo() {
		System.out.println("I");
	}
}

public class Base{
	public void foo() {
		System.out.println("Base");
	}
}

public class Sub extends Base implements I{
	public static void main(String[] args) {
		new Sub().foo();
	}
}

Hi Paul, can you plz explain why the code prints "Base" and not "I"?

if the class Base implements I, then Base overrides the foo method from the Interface. (that I understand)
I don't understand what happens when Sub implements I

admin
Site Admin
Posts: 8703
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by admin » Sun Dec 31, 2017 10:22 pm

Because Sub inherits the method foo from Base. The implementation of foo provided by I is only "default", which means, it is to be used only if the class implementing that interface does not provide any implementation for that method. But Sub does provide an implementation for foo (which it inherited from Base), so there is no need to use I's foo.
If you like our products and services, please help us by posting your review here.

OCAJO1
Posts: 221
Joined: Mon Nov 26, 2018 2:43 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by OCAJO1 » Mon Dec 10, 2018 8:29 pm

Comparing this code from another question,

interface Bozo{
int type = 0;
public void jump();
}
public class Type1Bozo implements Bozo{
public Type1Bozo(){
type = 1;
}
public void jump(){
System.out.println("jumping..."+type);
}
public static void main(String[] args){
Bozo b = new Type1Bozo();
b.jump();
}
}

Is the reason that in the above code, type = 1 will cause a compiler error while field location in class Donley does not, because
1. location has been re-initialized as int location, and therefore is not the same field as the one in interface movable?
2. or is it because it is in a different package?

Thanks

admin
Site Admin
Posts: 8703
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by admin » Mon Dec 10, 2018 9:43 pm

In 2.1403, Donkey has its own non-final location field. It is not trying to modify interface Movable's location field (which is static and final). Not sure what you mean by "re-initialize". There is no such technical term. But yes, it is a different field. So, ok.

In the code that you've posted, you are trying to modify the value of an interface's field. Interface's fields are always static and final. So, can't modify.
If you like our products and services, please help us by posting your review here.

OCAJO1
Posts: 221
Joined: Mon Nov 26, 2018 2:43 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by OCAJO1 » Tue Dec 11, 2018 1:38 pm

Don't know why I said re-initialize, I meant to say hide!
So based on your reply, being in the same or different packages does not effect the outcome?

admin
Site Admin
Posts: 8703
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by admin » Tue Dec 11, 2018 10:20 pm

>So based on your reply, being in the same or different packages does not effect the outcome?
It is difficult to answer such a vague question with 100% certainty.
You need to post exact code that shows what exactly are you trying the understand. Also, please compile and run the code, observe the output, and let us know if you have any trouble understanding the output.
If you like our products and services, please help us by posting your review here.

OCAJO1
Posts: 221
Joined: Mon Nov 26, 2018 2:43 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by OCAJO1 » Wed Dec 12, 2018 2:00 pm

I have run the program both with all the interface and classes being in the same package and different packages (like the question).

My question had to do with trying to understand that as a rule, when a variable defined in an interface is used again in a class that implements that interface (i.e. package p2, Class Donkey, int location = 200; in this blog's question), does the fact that a class (i.e. class Donkey) is in a different package than an interface (i.e. Movable interface), have any bearing on how that field in the class (i.e. location in class Donkey) is treated by the compiler and JVM?

admin
Site Admin
Posts: 8703
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1403 :

Post by admin » Wed Dec 12, 2018 8:50 pm

No, there is no difference.
If you like our products and services, please help us by posting your review here.

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests