Charles O'Leary

Ranch Hand
+ Follow
since Jul 10, 2014
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Charles O'Leary


possible answer provided per the question:

1: Interfaces are always abstract. 

Campbell Ritchie wrote: A class is an abstract datatype, but  ... The word was not used in the same context in ”abstract datatype”. Although the answer No 1 was correct, that quote didn't help to explain it.

My quote did not have any buts, exceptions, most of the times, and/or usuallys, so the word "always" was implied and was seemingly, I thought, exactly like your eloquent and concise §  The text (my quote) wriiten another way:  An interface is (always) an abstract datatype. (Period ... no buts) It defines a ...blah, blah, blah. 

So, not to beat a dead horse, but please help me to get my understanding correct on this.  I'd love to correct any misunderstanding that I may have regarding the quote that I provided.  

Campbell Ritchie wrote:

Charles O'Leary wrote:. . . Bingo! (same book)

'Fraid not. The phrase “abstract datatype” does not mean the same as “abstract class”. A class is an abstract datatype, but can usually be instantiated directly. You have found the wrong section.
If you want the definitive answer, you need to go to the Java® Language Specification (=JLS). Fortunately you don't have to go far to find the answer. Last sentence in the first paragraph, and further on in § That also tells you about the keyword abstract.

I did a "find" just to be sure.  But, please note that the word "class" was only used by you.  I think "abstract" was used in the correct context, especially as you outlined so eloquently in pointing out  §
I've enjoyed telling you that you were right all along!

Cozwaldo cozwald wrote:Thanks for the response , so just to clarify - Interfaces are always abstract , however an Interface may contain a static or default method (This method is not abstract - but as a whole the Interface is?) 

Bingo! (same book)
... And welcome to the ranch Cozwaldo.  (I think you have this one figured out.)

I feel option 1 is incorrect.

To which i then added the abstract keyword to the interface, which did not give any compile time errors.  (Which shows that interfaces are abstract - yet at the same time the only method on the interface has an impl?)

It appears that you have answered your own question?

Katherine Reut wrote:
    a) I "x"ed out the arrow pointing from a1 to "Alpha Object #1".
            *This makes the arrow from "a1.b1" to "Beta Object #1" and the arrow from "a1.b2" to "Beta Object #1" be x'ed out too!

Hi Ranchers,

Could you kindly refresh my memory on the specific rules for the above asterisk?  Or, perhaps, provide more insight?  By the way, I think this is one of the better diagrams that I've seen since it "keeps" both sets of b1&b2 within heap objects referenced by a1 and a2.  If you have a better diagram, by all means, please feel free to share it.


It should be clear that there is still a reference to the object referred to by a2, and that there is still a reference to the object referred to by a2.b2. What might be less clear is that you can still access the other Beta object through the static variable a2.b1—because it’s static.

My memory somehow wants to see a1, a1.b1, and a1.b2 as three separate (independent) references, similar to how the above answer seemingly (to me) treats a2, a2.b1, and a2.b2 as separate references?

Thanks in advance!
Welcome. Congratulations on your latest book Hanumant!
page 96 & 104, "argument" should be "parameter"

Now imagine a test class has a method with a declared argument type of GameShape, which means it can take any kind of GameShape.
The key point is that the doShapes() method is declared with a GameShape argument but can be passed any subtype (in this example, a subclass) of GameShape.


Of course, the cool thing here is that any class from any inheritance tree can also implement Animatable, so that means if you have a method with an argument declared as type Animatable, you can pass in PlayerPiece objects, SpinningLogo objects, and anything else that’s an instance of a class that implements Animatable

reference page 49 of OCA Java SE 8 Programmer I Exam Guide (Exams 1Z0-808)

As a bit of background, we’d like to clarify how we’re going to use the terms “argument” and “parameter” throughout this book:

   arguments  The things you specify between the parentheses when you’re invoking a method:

   parameters The things in the method’s signature that indicate what the method must receive when it’s invoked:

I found that changing the code, at the top of page 374 on OCA Java SE 8 Programmer I Exam Guide Exams 1Z0-808 1st Edition by Kathy Sierra  Author, Bert Bates Author, allowed me to properly compile/run/understand the point of the provided just-in-time array example.

Alejandro Daza wrote:I Really dont know why the mask gets 2 increment if there is only one mask++ in the code and I more that sure when you refer a variable to itself it does not increment, so I am really confused I really dont know what it is.

Alejandro Daza wrote:Thanks, So I am right, the answer on the book is incorrect then.

Assuming we have the same book, it's possible that some of the originally posted question was truncated.  If so, the book answer would be correct.


Charles O'Leary wrote:Since you already know the output, the specifics are:
IllegalArgumentException thrown on line 8  is caught on line 9
RuntimeException  thrown on line 11  isn't caught;  line 11 is not "guarded" inside its own try and catch)
line 16 executes inside the finally because the finally always executes (unless System.exit(0) and/or JVM shuts down)
RuntimeException  thrown on line 17 inside the finally is never caught

My apologies for the re-numbering:
Welcome to the Ranch