I still to this moment don't understand why
Java allows you to redeclare abstract methods inherited from Object in your interfaces -- I don't see what this really ever buys you except confusion.
I guess that someone decided that was allowed and legal far, long, way before there was any notion of Java 8's functional interface, they decided to let you do this for some reason, and we don't break compatibility without the utmost of necessity. We kill ourselves before introducing new keywords, etc. too.
[Actually, straining my brain, I guess it could be to suggest that the implementing class should not be content with inheriting Object's implementation, but that they should be overriding it in an appropriate manner?]
From what I can tell here:
https://docs.oracle.com/javase/specs/jls/se11/html/jls-4.html#jls-4.3.2
There are eight, or nine or ten (I used to have it memorized, didn't have the energy to even count them right now) abstract methods belonging to Object that may optionally be re-declared in any Interface, none of which would count towards the total of exactly One that is required to be a legal @FunctionalInterface.
I think that the question is just trying to ensure we are aware of these rules, but I find it even more confusing the way it is worded.
I would protest this question, but most of the fault lies with Java's existing ability to re-declare Object methods.
Many free preparatory materials don't even go into the odd fact that interfaces can re-declare Object methods that don't count towards the "total of one".
While it is fair to write a question that would cause someone who used these materials to prepare for the exam to get the wrong answer, this feels more like the literacy tests that used to be used to disenfranchise voters. I know more than I'd ever want to about the requirements for @FunctionalInterface and still have reservations about what answers they are looking for.
Working backwards from the answers,
B, not A because if the single abstract method happens to be a re-declaration of one from Object, then A itself isn't a functional interface. Also, even if A isn't for that reason, maybe B declares one real, new single abstract method...
C certainly isn't true in two ways, either Cub declares no NEW non-inherited abstract methods, and Panther had one, or B declares one and Panther had none (tho then A wasn't a @FunctionalInterface)...
At least D is obviously wrong, if both methods were just re-declarations of Object methods, then Cub would need one to be a valid @FunctionalInterface, if NEITHER were, then it is absolutely hopeless, but they don't say that.
E seems more right to me than F, if the question isn't stating that A inherits one from Object and declares one new one.
It is not the fault of the mock question authors nor the exam authors (presumably) that Interfaces can (pointlessly?) re-declare abstract methods inherited from Object. Since that can happen, it is proper to require knowing that this can happen and that this doesn't count towards the total of One that is necessary.
I'd go further and agree that one needs to know that neither default methods, private methods nor static methods, public or private count towards that total of one. They can certainly be there or not, and do not conflict with the requirements.
Any questions about validity of candidates for @FunctionalInterface should be easily answered by someone that knows these rules. From the part of the question that made it into this
thread, this would be a questionable question.
I failed to find this in my Sybex 816 book -- so I haven't looked directly at the question, but from what I saw in this thread, I'd have been confused and stressed by the question and answers, and I think I could teach a mini-lesson on this correctly.