• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin

Doubt in K&B SCJP 5: mock exam question on IS-A relationships

Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm a huge technicrat when it comes to semantics, and I guess I'd like to know whether this question is there to reflect what might be on the actual exam or whether it's there to instruct what an "is-a" relationship means.

In my opinion, none of these statements are always true.

B & E are obviously out, as they're talking about of has-a and cohesion/coupling. The book's answer is that A, C, D are all true, however. And I just can't bring myself to see it that way.

The thing about "always" is that it opens you up to proofs by contradiction, and on a test that's so semantically demanding, I really take issue with A,C,D all being called constitutively true.


In Java semantics, an interface implementation isn't consistently referred to as necessarily involving inheritance. Sun's Java trail]un's Java trail actually splits up "Inheritance and Interfaces" into a chapter as two diametrically opposed features addressing the same end-goal:

Therefore, if I have the following:

There is clearly an "Is-a" relationship as it's defined in K&B here. A Lazy IS-A DoNothingable, but does not inherit anything from it. Therefore, this is a contradiction of A's statement that "Is-a relationships always rely on inheritance.


This one claims that IS-A relationships always require at least two class types. My problem with this is that an IS-A relationship doesn't rely on two types, but rather it's a relationship between a declared reference type and an instance type. Therefore, if you're given:

At run-time, w's subclasses and implemented interfaces might pass dozens of instanceof tests. However, at compile-time, there's one (if trivial, guaranteed) IS-A relationship as defined by the fundamentals of polymorphism: Widget w IS-A Widget. Any Object instance must pass IS-A for its own class definition. Therefore, the IS-A relationship doesn't at all necessitate two class types. It's virtually meaningless, but it's the base case in the inductive reasoning behind polymorphism, and can't be discounted. Therefore, since an Object instance IS-A Object, not all IS-A relationships require two class types.


C sets me up for why I disagree with D as well. D claims that "Is-a relationships always rely on polymorphism". If polymorphism means "many forms", and an Object IS-A Object involves only one Platonic form Object, then clearly that IS-A relationship does not rely on polymorphism, since unimorphism apparently suffices.

Paging Bert Bates

[ July 10, 2007: Message edited by: Justin Seconi ]
[ December 05, 2008: Message edited by: Justin Seconi ]
Posts: 9050
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Justin -

There was a similar discussion recently about a similar question (or it might have been the same question?), in any case I agreed that we would make the wording of the question less "Absolute". So that instead of saying "always" we would say "typically" or "usually".

Thanks for your good catch.

A couple of general comments:

- Given the constraints that the exam creation team had while creating the exam, some of the "oo concepts" questions are perhaps not as totally bulletproof as they might be. The good news is that you will be told exactly how many answers are correct, so if you can try to avoid thinking about corner cases you should be able to answer these questions correctly.

- Based on your post, I have a feeling that you might research the exam topics more deeply than necessary for the exam. I could be all wet here, and it's tricky for sure, but we've tried to make the exam a lot less "tricky" than it used to be. We really tried to avoid testing on obscure "corner cases". In other words there are a lot of little nooks and crannies in the language and in the API that are NOT covered in the exam. Of course there is always benefit to detailed reseach, but just know that if you're focusing on the exam you won't have to go really deep - it's far more important to be really solid on the fundamentals that are described by the Sun objectives. It's totally cool to ask in this forum whether a particular detail is in scope on the exam.


Justin Seconi
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the reply Bert. I agree with your opinion on this. I'm the product of a life of trying to outsmart multiple choice exams (can't seem to help myself) and if it happens to bite me Friday, it certainly won't be the first time.

I appreciate your efforts in trying to restrict the number of non-helpful 'gotchas' in the exam, and I certainly don't mind as long as its answers are all certifiably correct

(btw, I have another outstanding question on a mock exam question I didn't see in the errata: https://coderanch.com/t/263807/java-programmer-SCJP/certification/SCJP-mock-exam-equals-hashCode )
Surfs up space ponies, I'm making gravy without this lumpy, tiny ad:
a bit of art, as a gift, the permaculture playing cards
    Bookmark Topic Watch Topic
  • New Topic