Anton Ganeshalingam wrote:
George Coolidge wrote:
However, in line 3, since Foot extends Foo, f.b should be visible to Foot and also new Foot().a should be visible to Foot class since it is referring to a variable of itself. I looked in the Java online documents (http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html), it states that protected members can be accessed by subclasses or classes in the same directory. Could somebody explains to me why line 2, 3 and 4 don't pass the compiler checking? Thank you and I really appreciate it.
line 3 //
Just because you extend Foot to Foo doesn't mean variable f is a subclass of type Foo. Variable f is contained ( has-a) in Foot class. You need to understand "is-a" / "has-a" relationships. In the context of Foot class, variable f is pointing to a object of type Foo which is defined in pkgA. This is why line 3 not compiling. When it comes to protected access member, it is visible to all classes that has"is-a" and "has-a" relationships in same package. But outside package a class can access to a protected variable only through inheritance (is-a).
Hope this helps.
Anton Ganeshalingam wrote:Remove the following lines and put them inside a method:
System.out.println(f.a); //line 2
System.out.println(f.b); //line 3
System.out.println(new Foot().a); //line 4
System.out.println(new Foot().b); //line 5
Siva Masilamani wrote:Protected member can be accessed in All the classes present in the same package and only by sub classes from different package but with one condition.
Subclass in different package can access the protected member from super class only through inheritance so you should not use Super class reference variable to access the protected member Insted just use the variable name or use sub class reference variable.
This condition holds true only if the sub class is in different package.
Hope you are clear now.
jay vas wrote:Can somebody explain to me why my compiler is allowing me to NOT catch the clearly
relevant exception in the Toyota.drive() method ?
I have a different exception in that method.... but there is no reason why the compiler couldnt force me
to catch both exceptions, or at least catch the Exception superclass.
Ankit Garg wrote:In case of a non-final class, a cast to/from interface is always allowed as there might be a class that is a sub-type of both. For example
So even if you don't declare a class D, but it might exists somewhere or someone else might create it, so the compiler allows a cast between a non-final class and interface. But in case of final-class, if that class doesn't implement an interface, then a cast between that interface and the class is not allowed
Since there can't be any class that is a sub-type of both C and I, so there can't be any object that IS-A C and I. This is why a cast between C and I is rejected at compile time as the compiler knows that the cast can't succeed at runtime.
Harry Henriques wrote:The following code snippet DOES NOT compile, but the code snippet below it DOES compile and run. This problem is part of a Drag-n-Drop problem from ExamLab by M Devaka Cooray.
The example below DOES compile without warnings or errors, and runs without exceptions. What is the difference between this code and the code above, and why does the keyword "final" make the difference?
Pat Farrell wrote:
Billy Tsai wrote:Remeber what happened to Compaq's Alpha Assembly after Compaq was Merged by HP
You mean what happened to DEC's Alpha after DEC was sold to Compaq and Compaq was sold to HP?
That really was a bit of a different case, as HP had a lot invested in the Itanium chips which were a direct competitor to the Alpha chips.
Today's rumor is that IBM will do the deal, buying Sun for $9.50 a share.