Mock exam 3 question (Java OCA 8 Programmer I Study Guide, Sybex)

[Jan Stückrath]

I have a question about the 3rd online mock exam provided with the book of Boyarsky und Selikoff.
There is one question that says "Which of the following are true statements about interface methods?" and one of the possible options is "They can be overridden by an abstract method in an abstract class that implements the interface". The answer text claims that this it true, but interfaces can also have static methods. Besides the fact that these methods cannot be unverridden (only hidden) in general, static methods of interfaces are not inherited to subclasses, thus, they cannot be overridden. Am I missing something?

[Ramya R Subramanian]

Its true that static methods cannot be overridden but only hidden.

The statement is "They can be overridden by an abstract method in an abstract class that implements the interface" -> Like in line 8 below. But you cannot create a static abstract method like in line 5. It will throw a compiler error like in line 5. so there is no question of overriding it.

package chapter2;
interface InterEx
{
	abstract void mymethod();
	abstract static void statmymethod(); // does not compile as static methods cannot be abstract. 
}
public abstract class AbstractEx implements InterEx {
	public abstract void mymethod(); //overriding without implementation as abstract class
}

JLS says in https://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.4

It is a compile-time error if a method is declared with more than one of the modifiers abstract, default, or static.

[Jan Stückrath]

Ramya Subraamanian wrote:
But you cannot create a static abstract method like in line 5. It will throw a compiler error like in line 5. so there is no question of overriding it.

That is correct, but the question does not refer to abstract interface methods, but only to "interface methods". For instance, the following code will compile just fine:

interface InterEx {
    public static void statmymethod() {}
}

public abstract class AbstractEx implements InterEx {
    public static void statmymethod() {}
}

The static method statmymethod() is a methode of InterEx, i.e. an interface method (isn't it?). However, there is no way AbstractEx can override this method. It could try to hide it (as seen in the code), but even that is not necessary, since AbstractEx does not even inherit this method for InterEx. Since this is a method that can not be overridden, the statement "They can be overridden by an abstract method in an abstract class that implements the interface" should be false for general interface methods, right?

[Roel De Nijs]

Jan Stückrath wrote:There is one question that says "Which of the following are true statements about interface methods?" and one of the possible options is "They can be overridden by an abstract method in an abstract class that implements the interface". The answer text claims that this it true, but interfaces can also have static methods. Besides the fact that these methods cannot be unverridden (only hidden) in general, static methods of interfaces are not inherited to subclasses, thus, they cannot be overridden. Am I missing something?

I think this answer option is definitely debatable.

First of all, this question is not specific to only abstract interface methods, it's about all different kinds of interface methods (abstract, default, and static). Secondly, other answer options mention explicitly "default methods" or "abstract methods". In this answer option the general "they" refers in my opinion to all interface methods and therefore this answer option is not correct (as a static interface method can't be overridden by an abstract method in an abstract class). If answer option C had stated: "Non-static interface methods can be overridden with an abstract method in an abstract class that implements the interface", it definitely was a correct answer.

Also the explanation has a minor issue: "An interface may only be marked" should be "An interface method may only be marked" (at first glance it seems to be not listed yet in the official overview).

Hope it helps!
Kind regards,
Roel

[Jan Stückrath]

Roel De Nijs wrote:
If answer option C had stated: "Non-static interface methods can be overridden with an abstract method in an abstract class that implements the interface", it definitely was a correct answer.

If you write it this way, it really seems that they meant non-static interface methods and wanted to ask weather an abstract method can be overridden by an abstract method.

Roel De Nijs wrote:
Also the explanation has a minor issue: "An interface may only be marked" should be "An interface method may only be marked" (at first glance it seems to be not listed yet in the official overview).

Wow, I was so focused on C, that I didn't even notice. I hope I will be more vigilant in the exam.

[Roel De Nijs]

Jan Stückrath wrote:If you write it this way, it really seems that they meant non-static interface methods and wanted to ask weather an abstract method can be overridden by an abstract method.

Non-static interface methods refers not only to abstract interface methods but to default interface methods as well.

[Jan Stückrath]

Roel De Nijs wrote:
Non-static interface methods refers not only to abstract interface methods but to default interface methods as well.

You are of course right. I actually thought about both, but forgot default in my post.

[Roel De Nijs]

Jan Stückrath wrote:

Roel De Nijs wrote:
Non-static interface methods refers not only to abstract interface methods but to default interface methods as well.

You are of course right. I actually thought about both, but forgot default in my post.

You can better forget it here than on the exam

[Ramya R Subramanian]

When I look at this statement "They can be overridden by an abstract method in an abstract class that implements the interface".I will have options like Interface Methods are static,abstract and default.But in answer statement they have clearly mentioned "overridden by an abstract method". so I will rule out my options for a static abstract or default abstract because its not feasible and understand that the author just wants to convey about abstract methods and not others. And so I conclude this statement is true.(entirely my perspective).

Secondly, other answer options mention explicitly "default methods" or "abstract methods".

I am worried only about the correctness of this statement while considering if this statement is true or not. should I be bothered if other statements have default in them ?

[Jan Stückrath]

Roel De Nijs wrote:
You can better forget it here than on the exam

That is of course also true.

Ramya Subraamanian wrote:
I will have options like Interface Methods are static,abstract and default.But in answer statement they have clearly mentioned "overridden by an abstract method". so I will rule out my options for a static abstract or default abstract because its not feasible and understand that the author just wants to convey about abstract methods and not others. And so I conclude this statement is true.(entirely my perspective).

First of all, for interface methods there is no such thing as static abstract or default abstract. They can be declared either static, default or abstract, but not multiple at the same time. I assume that you rule out abstract and default, but you can only do this if the question does this itself, and I do not see this here. The statement sounds to me like: "interface methods can be overridden by an abstract method in an abstract class that implements the interface" which is from my understanding equivalent to "every interface methods can be overridden by an abstract method in an abstract class that implements the interface" (note that I am not a native English speaker). And the last statement is obviously false.

Ramya Subraamanian wrote:

Roel De Nijs wrote:Secondly, other answer options mention explicitly "default methods" or "abstract methods".

I am worried only about the correctness of this statement while considering if this statement is true or not. I don't care, if other statements have default in them. or should i care?

Normally you would not care about the other statements, but in this case it is not entirely clear what the question wants to ask. Roel said that, they would probably be more precise if they only meant "non-static" in that option, since they were more precise in other case, and I agree with that.

[Ramya R Subramanian]

Yes, I have already mentioned that combination of those(static abstract or default abstract.) are not feasible. So I rule out my options of the interface method being default or static. So I say Interface method should only be abstract. And I read it as

"(they)abstract methods of the interface can be overridden by an abstract method in an abstract class that implements the interface".and thats true..(I am not a Native English speaker either)

If a statement is not clear, I would focus more on the statement itself. I feel comparing statements would confuse me more !!!

Agreed, it would be more precise if Non-static was added and there wouldnt be any confusions

[Roel De Nijs]

Ramya Subraamanian wrote:When I look at this statement "They can be overridden by an abstract method in an abstract class that implements the interface".I will have options like Interface Methods are static,abstract and default.But in answer statement they have clearly mentioned "overridden by an abstract method". so I will rule out my options for a static abstract or default abstract because its not feasible and understand that the author just wants to convey about abstract methods and not others. And so I conclude this statement is true.(entirely my perspective).

That's definitely a wrong assumption and approach. You should never assume anything which is not clearly mentioned in the question (and/or different options). And you have to be aware of the "context of the question". So the question itself mentions "interface methods" and in another options specific references are made to "default methods" and "abstract methods", so therefore "they" refers to all three types of interface methods and the statement is wrong (and I would not have selected it).

Ramya Subraamanian wrote:I am worried only about the correctness of this statement while considering if this statement is true or not. should I be bothered if other statements have default in them ?

As mentioned earlier, it's very important to be aware of the "context of the question" when answering mock (and real) questions. In this thread you'll find a nice discussion about this "context of a question", it's definitely worth reading.

[Roel De Nijs]

Ramya Subraamanian wrote:"(they)abstract methods of the interface can be overridden by an abstract method in an abstract class that implements the interface".and thats true..(I am not a Native English speaker either)

But that's not the actual statement. Because "They" refers to "interface methods". And honestly I don't think this has anything to do with being an English speaker or not.

Here is a simple example: "Goofy, Pluto and Micky Mouse go to the movie theater to watch the latest Disney movie. They bought popcorn and a drink.". In the second sentence "They" refers to "Goofy, Pluto and Micky Mouse". And it really doesn't matter if you know Goofy and Pluto are on a diet and can't buy popcorn.

[Ramya R Subramanian]

Because Jan mentioned he is not native English speaker, I just said I wasn't either !! And that has absolutely nothing to do with the statement.

Goofy, Pluto and Micky Mouse go to the movie theater to watch the latest Disney movie. They bought popcorn and a drink.

If the question is who are "they" and I already know goofy and pluto dont eat popcorn or drink. the answer would be Micky. But I am sure you would disagree because, you cannot assume anything about Goofy and Pluto. But questions are set based on the question setters assumption and the answers are based on their assumption. And each person who reads it perceives it differently. shouldn't we consider all possibilities before answering a question.

And I came across this question in whiz labs practice test :

If x.equals(y) is true then is this statement true -> " both x and y objects should have the same field status" ?

and other statements are "y.hashCode() must equal x.hashCode()" , "y.hashCode() may equal x.hashCode()".

[Jan Stückrath]

Ramya Subraamanian wrote:Because Jan mentioned he is not native English speaker, I just said I wasn't either !! And that has absolutely nothing to do with the statement.

I only mentioned that to be safe, since there are enough "false friend" or other subtleties in diffferent languages. I also don't see such a problem with this statement, but I already had a problem with answering a question, because I didn't know the word "lenient", so the language might be a cause of problems.

Ramya Subraamanian wrote:

Goofy, Pluto and Micky Mouse go to the movie theater to watch the latest Disney movie. They bought popcorn and a drink.

If the question is who are "they" and I already know goofy and pluto dont eat popcorn or drink. the answer would be Micky. But I am sure you would disagree because, you cannot assume anything about Goofy and Pluto. But questions are set based on the question setters assumption and the answers are based on their assumption. And each person who reads it perceives it differently. shouldn't we consider all possibilities before answering a question.

I do not agree with your choice of answers, but I agree with you about answering the question according to the "question setters assumption", because I think you mean the same as Roel when he mentioned "context of the question". However, in this case I think your assumption about the questioner is wrong.

Roel De Nijs wrote:
As mentioned earlier, it's very important to be aware of the "context of the question" when answering mock (and real) questions. In this thread you'll find a nice discussion about this "context of a question", it's definitely worth reading.

I read the thread and the rule "NEVER assume something which is not mentioned in the question" is a very good rule, but unfortunately also very hard to achieve. Already in the access modifier example in that thread you have to assume that the question does not consider reflection. That is quite straightforward in that case, but not necessary in others. At the moment I think that "ambiguous" questions (at least from my perspective) and too well hidden subtleties in code examples will be my main source of point loss in the exam.

[Roel De Nijs]

Ramya Subraamanian wrote:Because Jan mentioned he is not native English speaker, I just said I wasn't either !! And that has absolutely nothing to do with the statement.

If you feel offended, I want to apologize. That was never my intention! Based on our names, I already assumed all of us are not native English speakers.

Ramya Subraamanian wrote:If the question is who are "they" and I already know goofy and pluto dont eat popcorn or drink. the answer would be Micky. But I am sure you would disagree because, you cannot assume anything about Goofy and Pluto. But questions are set based on the question setters assumption and the answers are based on their assumption. And each person who reads it perceives it differently. shouldn't we consider all possibilities before answering a question.

Each question will test a specific part of your Java knowledge. If we go back to the original question "Which of the following are true statements about interface methods?", it's already obvious from this question that it will test you about your knowledge about the interface methods. So you have prepared thoroughly for this certification exam, so you know there are three types of interface methods: abstract, default, and static. So you have to verify if each of these statements is true for every interface method. So the first statement is "They can be declared abstract, default, or static". You know that's obviously true. You also know that you can only apply one of these keywords to an interface method, so if a method is already marked as abstract, it cannot be marked default or static (and that's exactly what the last answer is stating so you mark that one as correct as well). Then you see the next statement: "They can be overridden with an abstract method in an abstract class that implements the interface". Because this question is about "interface methods", the statement is equivalent to "Interface methods can be overridden with an abstract method in an abstract class that implements the interface". And although that statement is true for abstract and default interface methods, it isn't for static ones. So this statement is incorrect. (Also note that you might flag this statement as false for an incorrect reason as you might think for example that a default method can't be overridden with an abstract method )
If the question creator wanted to test you knowledge about default interface methods and their ability to be overridden by an abstract method in an abstract class implementing the interface, the statement will be "Default interface methods can be overridden with an abstract method in an abstract class that implements the interface". And if the question creator wants to test your knowledge about static interface methods, the question would have been Which of the following are true statements about static interface methods?". And then the same statement "They can be overridden with an abstract method in an abstract class that implements the interface" would be equivalent with "Static interface methods can be overridden with an abstract method in an abstract class that implements the interface".

Ramya Subraamanian wrote:And I came across this question in whiz labs practice test :

If x.equals(y) is true then is this statement true -> " both x and y objects should have the same field status" ?

and other statements are "y.hashCode() must equal x.hashCode()" , "y.hashCode() may equal x.hashCode()".

What about these statements?

[Roel De Nijs]

Jan Stückrath wrote:At the moment I think that "ambiguous" questions (at least from my perspective) and too well hidden subtleties in code examples will be my main source of point loss in the exam.

The more mock exams (or actual exams) you take, the more familiar you'll get with such "ambiguous" questions and you'll become much better at interpreting the "context of a question". And altough it might introduce some subtleties, I think it's definitely necessary. Otherwise exam creators would have a very difficult task to create clear/obvious/unambiguous questions. And I think this post (from the "context of a question" topic) about the statement "A public field can be accessed and modified from anywhere." explains very well why this "context of a question" really matters.

You might think that the exam creator should rephrase this statement to "A public non-final field defined in a public class can be accessed and modified from anywhere." and then this statement is absolutely unambiguous (and always true). But again that's not the case Because someone with a few years of experience knows about inner classes and he thinks about this code snippet and marks that absolutely unambiguous statement as false

class CrazyZoo {
    private static class Animal {
        public static class Lion {
            public String name = "Simba";
        }
    }
}
class TestCrazyZoo {
    public static void main(String[] args) {
        new CrazyZoo.Animal.Lion().name = "The Lion King"; // compiler error
    }
}

Because the Animal class is not visible (marked private), the public name field in a public class can't be accessed/modified from anywhere.

Hope it helps!
Kind regards,
Roel

Disclaimer: anonymous inner classes is not a topic of the OCA certification exams. I used them for demonstration purposes only. So if you don't understand what's happening, don't worry and just move on! Inner (or nested) classes (including anonymous inner classes) is an OCP exam objective.

[Ramya R Subramanian]

What about these statements?

This is question 41 in practice test of whiz labs ,.. what do you think is the answer(just to understand your thought process)?

If "x.equals(y)" returns true , then which of these statements are correct ?

A. both x and y objects should have the same field status
B. y.hashCode() must be equal to x.hashCode()
C. y.hashCode() may equal x.hashCode()

[Roel De Nijs]

Ramya Subraamanian wrote:If "x.equals(y)" returns true , then which of these statements are correct ?

A. both x and y objects should have the same field status
B. y.hashCode() must be equal to x.hashCode()
C. y.hashCode() may equal x.hashCode()

A is definitely wrong, because you don't know anything about the implementation of the equals() method. I can have several different implementations and every implementation is a valid one, but doesn't return true if both objects have same field status. Have a look at this Person class

class Person {
    private String id;
    private String firstName;
    private String lastName;

    @Override
    public boolean equals(Object obj) {
        if (!(obj instanceof Person)) {
            return false;
        }
        Person other = (Person) obj;
        return id.equals(other.id);
    }
}

The equals() method returns true if both objects have the same id. So firstName and lastName could have different values, but both objects could still be equal. That's why answer A is incorrect! Another illustrative example is this code snippet

class Dog {
    private String name;

    @Override
    public boolean equals(Object obj) {
        if (!(obj instanceof Dog)) {
            return false;
        }
        Dog other = (Dog) obj;
        return name.equalsIgnoreCase(other.name);
    }

}

I can have 2 Dog instances dog1 and dog2. The first one's name is "pluto" and the second one is "PLUTO". Although both instances have a different name (and thus a different field status), the equals() method will return true.

If you check the contract of the hashCode() method in the Object class, you can read this statement

Object's hashCode() method wrote:If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.

So from the part in bold it's pretty clear that B is the correct answer (and therefore C is wrong).

Hope it helps!
Kind regards,
Roel

[Ramya R Subramanian]

I know B is true without any doubt. But there was confusion in A.
x.equals(y) must be true only if I override equals. And if I have 2 fields as num1 and color. I will check if both of them are equal and then return true, thats the actual meaning of equality.

public class ObjectExample {
	int num1;
	String color;
	public static void main(String args[])
	{
		ObjectExample x = new ObjectExample() ;
		ObjectExample y = new ObjectExample() ;
		x.num1=10;
		y.num1 =10;
		x.color="blue";
		y.color="red";
		System.out.println(x.equals(y)); 
	}
	public boolean equals(ObjectExample obj)
			{
				if((this.num1 == obj.num1)&& (this.color == obj.color))
					return true;
				else
					return false;
			}
   }

I had a little doubt that when writing equals , I will just check one field like this below. But this is possible ,because we can write equals in anyway we want which makes statement "A" false.

public boolean equals(ObjectExample obj)
			{
				if((this.num1 == obj.num1) || (this.color == obj.color))
					return true;
				else
					return false;
			}

Now there's no confusion. Awesome explanation with the code snippet. Thank you Roel.

[Roel De Nijs]

Ramya Subraamanian wrote:x.equals(y) must be true only if I override equals. And if I have 2 fields as num1 and color. I will check if both of them are equal and then return true, thats the actual meaning of equality.

The meaning of equality depends on the type of the object and the use case. For example, you can have a Person class with a gazillion fields. In one application two Person objects will be considered to be equal if their social security number (SSN) is the same. And in another application it might be the e-mail address (because in this application the SSN is not a field). If you override the equals(Object) method, it's up to you to decide when two instances of this class will be equal. And it is possible that two instances are equal if all fields are equal, but that's not a requirement nor a guarantee. That's completely up to you.

Ramya Subraamanian wrote:But this is possible ,because we can write equals in anyway we want which makes statement "A" false.

Exactly! I like to make 2 remarks about both your code snippets. First a very important one: you did not override the equals(Object) method (from the Object class), but you have overloaded the equals(Object) method instead. And a second one, when you want to compare strings, you should not use the == operator but the equals(Object) (or the equalsIgnoreCase(String) method).

Ramya Subraamanian wrote:Now there's no confusion. Awesome explanation with the code snippet. Thank you Roel.

Glad to hear you liked the explanation with the code snippet and it cleared your doubt.

[Jan Stückrath]

Roel De Nijs wrote:The more mock exams (or actual exams) you take, the more familiar you'll get with such "ambiguous" questions and you'll become much better at interpreting the "context of a question".

I think so as well. Unfortunately I have currently no experience with these kind of certification exams, but this will change shortly.

Roel De Nijs wrote:And altough it might introduce some subtleties, I think it's definitely necessary. Otherwise exam creators would have a very difficult task to create clear/obvious/unambiguous questions.

I am not so sure about this being necessary, but it is inevitable, I suppose. From the exams I created in my time an the university I know how difficult the creation of good exam questions is. It happened to me more than once that students answered a question of mine and I asked myself: "how could they even interpret it that way?".

[Jan Stückrath]

A small supplementary information to our discussion:
Yesterday I passed the OCA exam with a score of 95%. There was actually a text-only question about the advantages of exceptions in Java, which I know that I answered incorrectly, because I did not manage to understand the "questions context" and failed to clear the ambiguity (I saw) correctly. It seems I still have a way to go.

Nontheless, I want to thank you, Roel, for the helpful dicussions.

[Ramya R Subramanian]

Congrats Jan ...that's a superb score !!

[Roel De Nijs]

Ramya Subraamanian wrote:that's a superb score !!

Agreed! Such a score deserves a topic on its own instead of a post tucked away in some other topic. What are you waiting for, Jan?

[Jan Stückrath]

Roel De Nijs wrote:

Ramya Subraamanian wrote:that's a superb score !!

Agreed! Such a score deserves a topic on its own instead of a post tucked away in some other topic. What are you waiting for, Jan?

Thanks. Well, I was just not planning to write a big report about my experiences, so a new topic seemed to be too much self-praise. But I just noticed that there is a subforum for exam results, so I will add a short entry there and also one to the hall of fame.

[Jeanne Boyarsky]

Jan Stückrath wrote:

Roel De Nijs wrote:

Ramya Subraamanian wrote:that's a superb score !!

Agreed! Such a score deserves a topic on its own instead of a post tucked away in some other topic. What are you waiting for, Jan?

Thanks. Well, I was just not planning to write a big report about my experiences, so a new topic seemed to be too much self-praise. But I just noticed that there is a subforum for exam results, so I will add a short entry there and also one to the hall of fame.

It's not just about self-praise. It's also about motivating others. For example, hearing that someone scored a 40% on their first mock exam and later passed with an 85% is very encouraging!

[Roel De Nijs]

Jan Stückrath wrote:But I just noticed that there is a subforum for exam results, so I will add a short entry there and also one to the hall of fame.

For those who are really curious, you'll find Jan's short entry here.

[Jeanne Boyarsky]

Roel De Nijs wrote:Also the explanation has a minor issue: "An interface may only be marked" should be "An interface method may only be marked" (at first glance it seems to be not listed yet in the official overview).

Noted.