About Question enthuware.ocajp.i.v8.2.2013 :

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

Moderator: admin

Post Reply
enthunoob
Posts: 60
Joined: Thu Apr 15, 2021 12:21 pm
Contact:

About Question enthuware.ocajp.i.v8.2.2013 :

Post by enthunoob »

I don't agree this is showing the multiple inheritance of type. I think that would involve the creation of an object and a few virtual method reference. What do you think would be a good example of inheritance of type?

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

Re: About Question enthuware.ocajp.i.v8.2.2013 :

Post by admin »

Why do you think it doesn't show multiple inheritance of type??
Did you go through the link given in the explanation? https://docs.oracle.com/javase/tutorial ... tance.html
If you like our products and services, please help us by posting your review here.

enthunoob
Posts: 60
Joined: Thu Apr 15, 2021 12:21 pm
Contact:

Re: About Question enthuware.ocajp.i.v8.2.2013 :

Post by enthunoob »

Once again I find myself super confused about the differences between these two kind of types: reference type and object type. For clarification, how I understand it now:

A). reference type
1. left-side of declaration (the type of the variable)
2. static references --> never changes *
3. checked at compile time
4. can be interface-type
5. determines accessibility of fields and static methods

B). object type
1. right-side of declaration (the object the variable is referring to)
2. runtime reference --> can change/be casted *
3. checked at runtime
4. is always a class (not interface)
5. determines accessibility of instance methods

So, in the answer mentioning "implementation of TYPE" I had above type B in my mind. Thus I was expecting an example with casting, where the type changes. What I meant with 'virtual method reference' was actually what is called 'virtual method invocation' on this page https://docs.oracle.com/javase/tutorial ... phism.html.

But the example of the question did not do anything with types but instead with method inheritance (and overriding), so I thought the correct answer was "Animal class illustrates Java's support for multiple implementation inheritance.".

And Yes, I have read that. Multiple times. And to be honest I am trying to find logic and write an answer to your question for at least four hours now, but it just doesn't make (perfect) sense. I think my question comes down to this quote (from your linked page):

"The Java programming language supports multiple inheritance of type, which is the ability of a class to implement more than one interface."

-> so WHAT TYPE is mentioned here? A or B? Or am I missing a third type?..

*About A.2 and B.2: what does not make sense to me between these lists now is that with casting the object itself (B) it always stays the same (Rice will be Rice, it doesn't become Food), but casting does change the reference type (A).. please tell me there is a third type..? :?

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

Re: About Question enthuware.ocajp.i.v8.2.2013 :

Post by admin »

Well, you may need to understand what is meant by "type" first and then revisit the question. I suggest you go through this: https://docs.oracle.com/javase/specs/jl ... jls-4.html and may be another good book to get your terminology right.

Briefly, "type" refers to "data type" i.e. the type of the data your are dealing with. Types are of two kinds - primitive and reference.

What you have mentioned above in A and B (reference type and object type) are not distinctions of types! They are properties of two different things - reference and object. More precisely, "reference type" means the type of a given reference and "object type" means the type of the given object.

The statements in this question are about "types" and not about references or objects. In Java, you create new types using classes, interfaces, and enums. That is where inheritance comes into picture and that is why it is said that java supports multiple inheritance of type (because an interface defines a new type and an interface can inherit from multiple interfaces).

Based on the questions you have been asking so far, I would suggest you to go through a good book first before attempting the questions to make sure your preconceived notions match with the reality.
If you like our products and services, please help us by posting your review here.

enthunoob
Posts: 60
Joined: Thu Apr 15, 2021 12:21 pm
Contact:

Re: About Question enthuware.ocajp.i.v8.2.2013 :

Post by enthunoob »

Thanks for your sharp answer. As of your advice I'm actually reading the fundamentals book. I'm halfway where it sais:

"Conceptually, a subclass inherits its own copy of an instance method. This is proven by the fact that a subclass can completely replace the behavior of an inherited instance method for objects of the subclass by “overriding” it with a new implementation of its own without affecting the behavior of the superclass’s implementation for objects of the superclass."

As you're stating the comparison of A and B doesnt hold up, but this quote clears up one of the points for me:

A.5 and B.5 -> I think it can be said that Java always looks for the reference type when it tries to find a method. The reason that sometimes, in my limited terminology, it finds it from the 'left side' (A, ref type, static methods) and other times from the 'right side' (B, object, instance methods) is that instance methods are, as said above, completely replaced. Which means that in case of an overridden instance method, it might look like it is finding it by the 'right side/object type' but Java actually always finds it by the reference type ('left side'/A). It just finds it because the overridden method in the superclass is replaced, and thus as of inheritance it becomes part of the superclass (accessible via ref type of superclass) as well as part of the subclass (and accessible via ref type of the subclass). And with ('overridden') static methods they aren't replaced but stay to exist: a (inherited) parent and it's child class still have seperate methods but the parent one is just hidden (or child one, depending on the chosen reference type).

I suppose this is what I had in mind when thinking of multiple inheritance of type, that methods can be inherited from multiple chained classes by extension and be called depending on the (reference) type. Thus thinking a good example of MIoT would include several chained classes each having their static (hidden) methods, where the main method would call them based on their reference type.

However, as you have noticed and mentioned my definitions are not yet sharp enough. I have yet to come to the chapter on Polymorphism. :)

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

Re: About Question enthuware.ocajp.i.v8.2.2013 :

Post by admin »

You are also skipping too much while reading. It is evident from your statement, "I think it can be said that Java always looks for the reference type when it tries to find a method."
What you do mean by "Java"? There is the java compiler and there is the java virtual machine. And they both do things differently. This is already explained in the fundamentals book.
Suggest you to read it from the beginning carefully.
If you like our products and services, please help us by posting your review here.

enthunoob
Posts: 60
Joined: Thu Apr 15, 2021 12:21 pm
Contact:

Re: About Question enthuware.ocajp.i.v8.2.2013 :

Post by enthunoob »

But I am reading it from the start, not skipping anything.. :(
And I am reading the fundamentals book, OCA Java Programmer 8 Fundamentals 1Z0-808 vs 28.

I indeed thought I could get away with just writing Java as (while reading in the book I realized this quote related to this topic and) while writing the previous, above post I was still figuring it out, and thought it wasn't about jvm/compiler anyway. I (think I) know it should be written JVM instead, as the looking up methods by object references are variable. And the compiler can only check for 'compile time constants' like checking if relationships between types can even exist; it can't know if objects have been casted to another type so it can't check for that.

So yes, I have read that, am reading still and am planning to go over the book again when I finish it, plus look into some compiled code to check if my assumption is actually correct. But as your comment doesn't disagree it seems like it is! :mrgreen:

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

Re: About Question enthuware.ocajp.i.v8.2.2013 :

Post by admin »

I (think I) know it should be written JVM instead, as the looking up methods by object references are variable. And the compiler can only check for 'compile time constants' like checking if relationships between types can even exist; it can't know if objects have been casted to another type so it can't check for that.
Still not quite there.
Both the compiler and the the jvm have a role to play. It is not just JVM.
Compile time constants have little to do with this tpic.
And the last line in the quote above doesn't make any sense.

By skipping, I meant that you have read it too fast thereby missing important points.
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 46 guests