Jeronimo Sanchez

What I think Mohana is trying to ask is if all methods in an abstract class are static, do we need to sub-class the class? And the answer is no, we do not need to do so to call the static methods.

It's perfectly legal to invoke static methods within abstract classes. Check the foloowing example:

abstract class A { static void go () { System.out.println("Static method in abstract class"); } } public class TestDrive01 { static public void main (String[] args) { A.go(); } }

Other question is why to have an abstract class with only static methods.

Try the links in JavaRanch FAQ: What are some mock exams available?

Of course, it would be a)

Remember that array indexes run from 0 to dimension-1. It means that in this particular case, the line:

System.out.println(args[0]+" "+args[args.length]);

would try to access the 5th element in the array, which does not exist. So an ArrayIndexOutOfBounds exception would be thrown at runtime.

Barry, your are completely right. I run the same exercise modified to use a nonstatic secret, and the result is exactly the same, as you predicted.

Thanks all that have posted to this thread. Not only I learnt to correctly interpret the authors of the K&B book, but also it indirectly helped me to burn in my brain the control access modifiers (even the hard one: protected) ;-)

Hope I can help you the same way very soon!!!

You are right, Barry!!!

After some posts (perhaps too many ), I finally realized what K&B tried to explain. Now it's clear to me there is no bug in the book. And your sample code is quite educative, really! (as always)

My last thought regarding this subject is: if the secret does not become protected in class C (since class E cannot access it), nor private (since class D inherits the secret)... is it possible to say we have a fifth access control level, yet very specific?

The volatile nonaccess modifier is missing in the bullet point list on page 52, where are listed the modifiers that can/cannot be applied to instance variables.

The volatile modifier is listed, however, in Figure 1.7 (page 53). In addition, in page 59 is stated that we must know for the exam that the volatile can be applied only to instance variables. So I think volatile modifier should also be listed on page 52.

(added volatile to topic title)
[ July 26, 2006: Message edited by: Barry Gaunt ]

Does this mean that we have found a fifth access control level?

I mean, it seems that a protected member in class A that is inherited by class B in another package, has a very special and specific access control level that is not private, nor protected not default (not public, of course).

What do you think?

Thanks Keith/Neelesh. Now it's crystal clear!!!

I thought K&B meant private access control modifier, but they definitively didn't. My blame!!

[ July 25, 2006: Message edited by: Jeronimo Sanchez ]
[ July 25, 2006: Message edited by: Jeronimo Sanchez ]

Test1{
protected int i=9;
}
Test2{
public static void main(String args[]){
System.out.println(new Test1().i); // line 1
}
}

Naseem, I'm talking about a class that extends another class in the same package, which in turn extends a third class in a different package.

Your Test2 class does not even extend Test1. And of course, Test2 cannot access "i" in Test1 because "i" is protected. And even if it were private, Test2 still couldn't access "i". This is clear, you are right and I have no problem with this. Again, this is not the point.

I'm starting think that you are not reading all my posts, because your example has nothing to do with what I'm trying to demonstrate.

The second 3 is just dimensioning all arrays contained in the first dimension array (in this case, to have 3 ints each). You can test it with the following example:

public class Array { public static void main (String[] args) { int[][] myArray = new int[3][3]; System.out.println("2,2 = " + myArray[2][2]); // Line 1 System.out.println("2,3 = " + myArray[2][3]); // Line 2 } }

This code will compile. Line 1 will print "0" on screen (remember that array elements are automatically initialized), but Line 2 will throw an ArrayIndexOutOfBoundsException, because the fourth element in the second dimension array does not exist (remember that array indexes run from 0 to dimension-1).

Hope this can help.
[ July 25, 2006: Message edited by: Jeronimo Sanchez ]

It IS protected. I'm afraid you have a wrong concept of the private access control modifier. If "i" were private in Sub, then class Test could not access "i" throught inheritance. And the fact is that Test CAN access "i" through inheritance: just run my (fixed) sample source code to check it.

To Naseem:

Of course Test cannot access "i" in your example. It is protected, and is not extending neither Sub nor Super!!! This is not the point.

To see what I mean, please, check this (fixed) example:

package B; import A.*; class Sub extends Super {} public class Test extends Sub { static public void main (String[] args) { Test test = new Test(); System.out.println(test.go()); } public int go () { return i; } }

Please, note that we need the public method "go" in order to access the protected non-static member "i".

This example compiles and run perfectly well, which demonstrates what you (and now I) know about the private member: that it can be accessed from subclasses. But then, why does the author that protected members become private in subclasses outside the package? That's the point!!!


To Kevin:

Thanks for your explanation. I see your point, but it makes no sense to say that a member is private for non subclasses, since for non subclasses it doesn't really matter if a class member is protected or private: they cannot access the members in both cases.

Private only differs from protected regarding inheritance: meanwhile protected allows the member to be access through inheritance, private does not. And Naseem and I have demonstrated that protected members got inherited to grandchildren classes outside its package. So it cannot become private. So there's an errata in the book.

Why is so difficult to understand. Am I missing something?
[ July 25, 2006: Message edited by: Jeronimo Sanchez ]

Yes, Naseem, you are right, I realized that after I fixed my own sample code. Now it's clear to me that children classes of the subclass also inherits the protected member, and thus they can see it. Then, why does the author write "...the (protected) member is essentially private inside the subclass"?

According to our sample codes, protected member can be accessed by the subclass outside the package, and all its subclasses. But if the protected member would have become private (as the author states), then it could not have been seen by grandchildren classes. Isn't it?

So, as far as I know, I still think there's an errata, not where I originally thought, but in saying that that protected members become private in subclasses outside the package where they are declared. That's not true, unless the concept of private members I have is wrong.
[ July 25, 2006: Message edited by: Jeronimo Sanchez ]

Of course, I missed the "import A.*;" statement, that's why it failed at compile time. Sorry!!! And even including the import statement, I still had to fix file B/Test.java. See the fixed code:

package B; import A.*; class Sub extends Super {} public class Test extends Sub { static public void main (String[] args) { Test test = new Test(); System.out.println(test.go()); } public int go () { return i; } }

Now that I've fixed the source code file... it works! That means, hence, that protected members do not become private in subclasses outside the package where they are declared!!! Which is still an errata, isn't it?

Now I am even more confused!

Naseem, I appreciate your comments, but I don't see what they have to do with the discussion.

What I say is that, according to K&B book, a protected member becomes private in a subclass outside the package where the protected member was declared. It means that, if we extend the subclass that inherits the protected member, any class that extends such subclass should not be able to access the protected member.

See the following example:

// File: A/Super.java package A; public class Super { protected int i = 9; } // File B/Test.java package B; class Sub extends Super {} public class Test extends Sub { static public void main (String[] args) { System.out.println(new Test().i); // Line 1 } }

Line 1 should give us a compilation error, since "i" becomes private in Sub class, so it's not visible for Test class. If this is true (and it seems it is when running the previous example), the sentence in the K&B book should read:

..when a subclass-outside-the-package inherits a protected member, the member is essentially private inside the subclass, such that only the subclass can access it.

Notice that the text "and its subclasses" has been removed from the sentence.