This week's book giveaway is in the Java in General forum.
We're giving away four copies of Beginning Java 17 Fundamentals: Object-Oriented Programming in Java 17 and have ishori Sharan & Adam L Davis on-line!
See this thread for details.
Win a copy of Beginning Java 17 Fundamentals: Object-Oriented Programming in Java 17 this week in the Java in General forum!

George Coolidge

Greenhorn
+ Follow
since Apr 08, 2009
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by George Coolidge

You are always welcome.

Max Campa wrote:Thank you George. I have debugged the code and now it makes sense.

The reason is even though

looks like that an instance variable is assigned, it is actually assigning a class variable, aka, static variable. So b1 is still referenced in Alpha.b1, remember, even though a2 gets collected, b1 still won't be collected since you don't need to instantiate an instance to assign a class variable.

So only a1 is not referenced by anybody and becomes dangling reference, and therefore only 1 object will be garbage collected. In real code, the form in

is discouraged since it is confusing to the readers and sometimes coders themselves.
I couldn't find the edit button for my first post, thanks for the reminder.

Ankit Garg wrote:Please Use Code Tags when you post a source code. You can edit your message using button and then add code tags to it...

Thank you for the explanation on the difference of is-a and has-a relationship, I now understand that Foot class cannot even access variable a through inheritance even though Foot extends Foo, and it can access Foot class's variable b since it now has the ownership of variable b now.

Since now Foot class has the variable

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.

I am not asking how to fix the problems, but why these lines don't pass the compiler's checking, thanks.

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

OK, I can understand why line 2 and 3 are illegitimate with your explanation, but why line 3 is still illegitimate? Should class Foot be able to access its own variable provided that it is within the same package? Thank you for your help!

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.

I am utterly confused by a question in SCJP preparation book:
There are two classes in different packages, say Foo and Foot as below:

package pkgA;

public class Foo{
int a = 5;
protected int b = 6;
}

package pkgB;

import pkgA.Foo;

public class Foot extends Foo{
Foo f = new Foo(); //line 1
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
}

In the book and also in Ecplise 3.3.0, line 2, 3, 4 will cause compiler errors. In my opinion, line 2 is illegitimate since Foo is in different package of Foot and variable a is package private, so it is not visible in line 2.

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.
When you override a method in the subclass, you can loose the specification by omitting an exception. In this case, Toyota class can throw either no exception at all or EmptyStackException, which is an unchecked exception. Remember that Toyota.drive() method doesn't "inherit" the IOException thrown in the superclass's drive method.

Always remember that a Java method's signature ONLY include the method name and its parameter type list, contrary to many people's intuition, access modifier, return type and thrown exception do NOT belong to the signature and therefore are not guaranteed to be the same in the overriden methods.

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.

Exactly, unless it is absolutely impossible for C to be is-a Runnable interface, the compiler will let it pass and throw ClassCastException at runtime if the referenced type (C or its subtypes) doesn't implement Runnable interface.

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.

HTH

Which compiler do you use? It works fine for both versions in my eclipse.

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.



The deal fell apart, then, what's next for Sun? Will it shine again?
12 years ago