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.
Campbell Ritchie wrote:'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.
Charles O'Leary wrote:. . . Bingo! (same book)
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 §126.96.36.199. That also tells you about the keyword abstract.
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?)
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?)
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!
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.
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
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:
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.
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