Link to home
Start Free TrialLog in
Avatar of afterburner
afterburner

asked on

Basic Question, sorry.

What's the story with protected methods exactly? I tried to call "configureEnclosingScrollPane()" and "resizeAndRepaint()" on a jtable instance, but the compiler complained that the methods are protected and not accessible. My table is a subclass and an instance, so why's my head not straight about this?

thnks
aftrbrnr.
ASKER CERTIFIED SOLUTION
Avatar of navneet77
navneet77

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of girionis
Protected methods/variables can only be accessed by subclasses. Are you sure that the protected method is not also final?
Avatar of navneet77
navneet77

ya they are not final unless you specify final. Sometime inbuild java classes define them to be final and you cant overwrite these method.
>  I tried to call

  Sorry for my previous answer. "final" has nothing got to do with calling. I thought you were trying to override the method as well.
Avatar of afterburner

ASKER

girionis;

methods are not final according to the documentation I have, they are public void .... .

As I said, my table *is* a subclass of JTable, there is no doubt about that. Can anyone enlighten further?

BTW, all help appreciated, but as a personal wish, I would prefer no-one post any code in answers or comments, unless otherwise unavoidable please.
> objB.methodA() 'this will give you an error

  No, it shouldn't give you an error. It should call the "methodA" with no problems.
 afterburner can you pleae post the exact error message you are getting?
documentation:

protected void configureEnclosingScrollPane();

my code:
jtab = new JTable();
blah, blah blah, table added to scrollpane etc etc etc ...
jtab.configureEnclosingScrollPane();

compiler:

go away. method is protected.
>  they are public void .... .

  How come the compiler complains for protection then? Are you sure you haven't mixed up JVMs/JDKs?
afterburner you cannot call the protected method like this.
you can only call it from a subclass and if the above is in a subclass it is not acting as a subclass. When you creat a new instance of JTable it act as any other class using that object
and if you go to
http://java.sun.com/j2se/1.3/docs/api/javax/swing/JTable.html
it says they are protected and not public
compiler:

1.
"configureEnclosingScrollPane() has protected acces in javax.swing.JTable"

2.
"resizeAndRepaint() has protected acces in javax.swing.JTable"

> jtab.configureEnclosingScrollPane();

  Don't call it like that. Just call it by its name: configureEnclosingScrollPane();

  What's the point o calling it like that if it's a subclass?
 Damn... this topic changes fast. navneet77 sorry I did not see your comment before I posted mine :-)

  afterburner by calling the method using a JTable instance you "break" the inheritance concept. WHat is the point of subclassing JTable if you are going to use its instance?
no worries girionis :)
>How come the compiler complains for protection then? Are you sure you haven't mixed up JVMs/JDKs?

Sorry my slip. Docs say that methods are protected - of course. Dont know how I said public, after all. Anyway ...

>What's the point o calling it like that if it's a subclass?

Dont follow you here. I am asking that instance, am I not, to run that method? If I leave out the jtab, how dows the call know where I am pointing?
girionis:

Wrong use of vocab on my part, sorry. jtab is an *instance* of JTable, not a subclass. I make the instance, then I try to call the two methods. That's what I am doing.
when you subclass a class the subclass inherits all public/protected methods from the parent class. So if you just call the method of parent it is like calling a method withing that class.You do not need to create a new jTable and just call the method
So afterburner you cannot call a protected method by creating its instance, you can only call it from the subclass or itself. Its simple as that, and so you are rightly getting compile error.

You can only call the public methods like this
>when you subclass a class

But that's like a static call, and that wont compile either.

Basically, "do I have to subclass JTable in order to be able to call these two methods on an instance of the new subclass".
> So afterburner you cannot call a protected method by creating its instance, you can only call it from the subclass or itself.

  Exactly!
OK, I said at the top that my head wasnt straight, and I knew I was doing something ultra stupid, and I was. ut could I see it at all when I needed to? ;)

Thanks.
OKAY. Tnanks both.
 afterburner I suggest you accept some other of navneet77's comments. The answer you accepted is not correct and other people with similar problems might be confused.

class A
{
    protected methodA()
}

class B extends A
{
    public methodB()
    {
        methodA() 'this is ok
    }
}

class C
{
    B objB = new B()
    objB.methodA() 'this will give you an error
}

  The above should *work* since it is the class "B" (and not the class "C" directly) that calls the "methodA" which is perfectly acceptable since class "B" is a subclass of class "A". In contrast the following should *not* work.

class A
{
    protected methodA()
}

class B extends A
{
    public methodB()
    {
        methodA() 'this is ok
    }
}

class C
{
    A objA = new A()
    objA.methodA() //this will give you an error
}
girionis:

>you can call protected method from within the subclass
but not from outside

he answered it like that in the comment I accepted. I cant help what other people make of his answers - anyone using EE must know that it is fraught with such pitfalls. But please dont take offence at this comment.
 None taken. I just thought it would be nice to make it clear for other people that might have a similar question. :-)
:)
girionis,
>> class C
   {
   B objB = new B()
   objB.methodA() 'this will give you an error
   }


>>The above should *work* since it is the class "B" (and not the class "C" directly) that calls the "methodA" which is perfectly acceptable since class "B" is a subclass of class "A". In contrast the following should *not* work.

if the subclass do not over a super classes protected method will it not remain protected in the subclass as well. In that case even objB.methodA(). Note that the method is called from class C which is not a subclass of any class

Correct me if i am wrong
 The secret to understand what happens is that we should take into consideration the package structure since a "protected" defined method/variable is only accessible from a subclass *or* a class that resides on the same package (regardless if it's a subclass or not). Thus the following:

class A
{
   protected methodA();
}
class B extends A
{
   public methodB()
   {
       methodA();
   }
}
class C
{
   B objB = new B();
   objB.methodA();
}

  will compile and run perfectly if the classes A, B and C are in the same folder when compiled (and, naturaly, their corresponding class files are under the same folder as well). However the following:

package a;
class A
{
   protected methodA();
}

package a;
class B extends A
{
   public methodB()
   {
       methodA();
   }
}

package b;
import a.*;
class C
{
   B objB = new B();
   objB.methodA();
}

  won't compile at all.
> *or*

  This could also be *and*, depends on the context. To be precise it can be accessed by either:

1) subclass and same package
2) subclass and different package
3) not subclass and same package.
Yeah, I'll catch up with this later. But for now, I'm worried that this all, (apart from your last comment maybe) implies that an instance of a class, by *possibly* not being able to implement a protected method, is held to be less important, hierarchically, than a subclass?? Seems a bit weird doesnt it?
> hat an instance of a class, by *possibly* not being able to implement a protected method, is held to be less
>important, hierarchically, than a subclass?? Seems a bit weird doesnt it?

  Well I wouldn't say so. It all comes down to design and specification issues I guess. If you want to implement a method, any method, and make your class more important hierarchically, why declare the method protected and not public?
> why declare the method protected and not public?

Why have any modifiers at all? Think of the imperative delaration of variables in some languages: if a programmer really had his act together, he wouldnt need such 'safety nets'. This is slightly different here, I know, because in our case it is concerned with external access to methods. But then again, all unmetered access to any resource is unwarranted isnt it?

I would have thought that *if anything* a subclass should be the entity that is restricted in its access to parent classes, since you can 'steal' what the parent can do, *and still* foul things up with more home-grown code. On the other hand, if foreign classes had access to the so-called protected methods, then, if the methods were conceived correctly, they themselves should not allow any wayward misuse of their functionality.
> Why have any modifiers at all?

  Well, why have any types at all? Why have any objects at all? Why not only have functional or relational programming languages? What is the use of imperative programming languages?

  You see every language is here to solve a different problem. That is the case with modifiers as well. Each modifier is here to solve a specific problem. *I believe* that by not having modifiers make the programme more error prone since you could implement specific functionality differently.

> On the other hand, if foreign classes had access to the so-called protected methods, then, if the methods were conceived correctly,
>they themselves should not allow any wayward misuse of their functionality.

  Exactly. And that can be obtained by properly using modifiers.
Agreed. Best regards.
Aftrbrnr.
girionis comment dated 03/07/2003 08:16AM PST is actually the correct answer:

>  be precise it can be accessed by either:

> 1) subclass and same package
> 2) subclass and different package
> 3) not subclass and same package.

so why then does this happen >

my code:
jtab = new JTable();
blah, blah blah, table added to scrollpane etc etc etc ...
jtab.configureEnclosingScrollPane();

compiler:

go away. method is protected.
 I thought you understood what the problem was. You class instantiates a JTable and you try to call a protected method on it. This is not allowed since your class is not (and shouldn't be) in the same package as JTable. However if your class extends JTable you can call the configureEnclosingScrollPane() without instantiating JTable.
I did understand. But I am posing the question thusly:

I subclass JTable, producing myJTable lets say. I instantiate myJTable. I can then call the protected methods in JTable. Right?

Other scenario: I instantiate a JTable object, straight, producing, say, JTableInstance. I cant access the protected methods, right?

Question: What sense does something like that make?

To me, an instance of the parent class should have equal, if not greater priority access to its class's members than a subclass. As I said before, it seems to me to be concetually the wrong way 'round.
This is a comment "for the record" only.

Listeners please note that in my original question at top, I made a mistake of saying that my object was both a subclass and an instance, and this is wrong. My object is not a subclass, so you can strike that out of the equation.
> I subclass JTable, producing myJTable lets say. I instantiate myJTable. I can then call the protected methods in JTable. Right?

  If you subclass JTable your class *is* a JTable, there is no need to subclass JTable *and* create a JTable instance. So you subclass JTable and you can call JTable's protected method by just its name (or using the "super" keyword). But if you instantiate another JTable you cannot call the protected method from the JTable instance. Except if your class is in the same package as the JTable class.

  You see, if you subclass *and* instantiate JTable you end up with *two* JTable instances, one your class (which can call protected methods) and one your JTable instance (which you cannot call protected methods - unless the class from which you create the JTable instance is in the same package as JTable).

>  I instantiate a JTable object, straight, producing, say, JTableInstance. I cant access the protected methods, right?

  Yes right, you can't access the protected method. Unless your class from which you instantiate JTable is in the same package as JTable. In other words if in the beginning of you class you have: package javax.swing;

>  What sense does something like that make?

  Perfect to me since you restrict access to specific objects only.

> To me, an instance of the parent class should have equal, if not greater priority access to its class's members than a subclass

  It has if you are in the same package.

 
>Yes right, you can't access the protected method. Unless your class from which you instantiate JTable is in the same package as JTable. In other words if in the beginning of you class you have: package javax.swing;


My point exactly. JTable *is* in the same package, isnt it?
>My point exactly. JTable *is* in the same package, isnt it?

  So your class is in the javax.swing package?
>Unless your class from which you instantiate JTable is in the same package as JTable.

The class *from which I instantiate* a JTable instance object *is* afaik in the same package as JTable, viz: javax.swing. As I said, I do this:

import javax.swing.*;
blah blah.....
JTableinstance = new JTable();
 Importing the javax.swing package doesn't mean that your class is in the same package. Two classes are in the same package only if they explicitly define it (by having the package... declaration) or if it is done implicitly (they have no package... declaration but they are under the same folder when they are compiled.

  Look at your class from which you instantiate the JTable. Has it got:

package javax.swing;

 as its first line?

  If not then they are not under the same package.
>>from which I instantiate

or do you mean the "**class from which** I am calling for an instantiation of JTable"??

I have been interpreting this concept as a call not "directionally" from *my class*, but a call from my class, yes, but asking for a new object **from** the JTable class.

My reasoning for this - and I havent thought about it until now - is that it is *absolutely obvious* that the direction of the call (ie where it is coming from) is the present class, whatever that may be. Therefore, the call, I thought, should relate to asking a service *from* elsewhere, ie the JTable class. In other words I am asking for something *from that class*.

Alright, now I can start to see where the difference is.

Thanks.
Still, I cant see why a subclass has more right to access protected methods than a direct child. Isnt that like saying that your cousin should have more influence with your parents than you do as their child?
And the reason I say that is because there isnt much point in subclassing anything unless you are going to do something different with it than the present class can handle, ie. the cousin is more different from the parents than the direct child is. But is that a reason to give the cousin access to the parents secrets?
> an instance of the parent class should have equal, if
> not greater priority access to its class's members than
> a subclass.

No the 'parent' has no special rights. It is simply using the other class. (I'm assuming you are referring to the object that creates the instance as the 'parent').

> I cant see why a subclass has more right to access
> protected methods than a direct child.

You better verify your semantics so were all talking about the same thing. Can you give an example to indicate what you mean by 'parent' and 'child'.



somewhere ....
class a extends JTable{}

before we go somewhere else : what is a? Child or Parent.
My answer = child.
Your answer =


My answer = child.
Your answer = subclass






My answer is also = child.
My answer was actually 'subclass'.
(I just filled in the blank)
Child class, right?
Let me give you a bit more help.

b = new a();

b is now an instance of a subclass of a.

b can call protected methods.

But,

c = new JTable();

c cant play. b is better.
>(I'm assuming you are referring to the object that creates the instance as the 'parent').

Dont think so. The object that creates the instance is an instance of a different parent altogether.
>b is now an instance of a subclass of a

= b is an instance of a subclass of JTable, I mean, a being the subclass of JTable.
> b can call protected methods.

methods of b can call protected methods, but you cannot use b to call protected methods.

ie. if xyz() is a protected method of b then you cannot say:

b.xyz();

unless the call is made from a subclass of a, or from the same package as a.
Well, I dont know what we are talking about any more.

>methods of b can call protected methods, but you cannot use b to call protected methods

are you saying that b has the protected method configureEnclosingScrollPane() or not? IOW, can you do this:

b.configureEnclosingScrollPane();

without having written a method of that name into your subclass b?
> are you saying that b has the protected method
> configureEnclosingScrollPane() or not?

yes we can say that :)

> can you do this:
> b.configureEnclosingScrollPane();

Only if the class that is making the call is a subclass of a, or in the same package as a.




>Only if the class that is making the call is a subclass of a, or in the same package as a.

Is b is making the call here?
b is an instance of a (which is a subclass of JTable), so yes it can call protected methods in JTable.
so b, as an instance of a subclass of JTable, can call protected methods of JTable. That much we have established.

_______________________________________________________;)

So now, c.

c =  new JTable();

c is an instance of JTable, but cannot call protected JTable methods.

To me, this does not make sense. c is an instance of the class itself; that alone should surely qualify it for use of protected methods. But b gets to use protected methods - why?
There appears to be confusion on what is meant.
When we say b can call protected methods we are saying that code within the class 'a' can call JTable protected methods, *not* that any code can call b's protected methods.
ie. it depends where the call is being made from.

eg. as i state above:
"methods of b can call protected methods, but you cannot use b to call protected methods."


>any code

What do you mean by this?
does "any method" make more sense?
Well I am truly confused.

b is an instance of a subclass of JTable. b is a to all intents and purposes, which makes b equivalent to JTable as far as practical purposes are concerned. b can access the protected methods that were written ab initio into JTable, were inherited by a, and passed on canned-up to b when it was born.

b is just a working incarnation of JTable. But it is one that was made from a, the first-generation subclass.

My point is that by going straight to a statement like :
" x = new JTable ", "x" is not able to access those protected methods, right. Well, that is the bit that makes no sense. "x" should be considerable as at least a peer to a, and possibly something more important, if such a thing exists. It is why I said that it is like giving your cousin more rights to talk to your parents than you have yourself. :)
You're still missing point I think.
It depends on which class is making the call.
If I have an enclosing class called NothingToDoWithAnyOfThisWhatsoEver, which calls a protected method in a subclassed instance of a JTable, then, unless the enclosing class is itself a subclass of JTable or in the same package, then you mean it cant access the protected methods - ?
> then you mean it cant access the protected methods

correct.

Whether a method can be called is dependant on both:
- the class *making* the call, and
- the visibility modifier of the method being called
So if I subclass JTable, write a public method into that new subclass which calls a JTable protected method, then *effectively* I can make a call to a JTable protected method from whatever class I like?

Also, I can perhaps see a point for this protection when a value is returned from the protected call; but what is the point of protection when there is no return type, and the call is to a facility such as reSizeAndRepaint(), which is hardly going to cause the end of the world.
> So if I subclass JTable, write a public method into that
> new subclass which calls a JTable protected method, then
> *effectively* I can make a call to a JTable protected
> method from whatever class I like?

Yes.

> but what is the point of protection when there is no
> return type, and the call is to a facility such as
> reSizeAndRepaint(), which is hardly going to cause the
> end of the world.

Maybe, maybe not. The fact that it doesn't return a value doesn't really make ant difference as it can still change the state of the object. What about:

private void endTheWorldNow()

No return type, but I don't think you'd want just anyone to be able call it :)
>private void endTheWorldNow()

>but I don't think you'd want just anyone to be able call it :)

Not even the subclass, thank you ;)


>Maybe, maybe not

This is then the equivalent of being able to subclass a class, and writing overriding methods with different modifiers - it amounts to the same thing. This then takes us full circle to the point that there is no point having protected or private methods. In fact, being able to circumvent the modifiers' gatekeeping means that the derived subclass could be even more insidious than an incorrect access to a protected method in the first place.




> Not even the subclass, thank you ;)

That's right, not even a subclass would have access to it.

> and writing overriding methods with different modifiers

From memory you can't override a method and change it's cisibility.

> derived subclass could be even more insidious than an
> incorrect access to a protected method in the first
place.

Subclasses are permitted to access protected methods, what the implementor of that subclass does is their problem.
If you want to stop subclasses accessing a method then make it private.




>private void endTheWorldNow()

See, I tripped up then; you slipped in a private when my eyes wanted to see "protected". You're right, of course. ;)

>what the implementor of that subclass does is their problem.

That is the problem.

What remains to be examined is the thinking behind making self-referential, return type void methods such as reSizeAndRepaint() protected? There can't be much of a case for that, can there? After all, the object is hardly going to resize and reapint something else!
resizeAndRepaint().
> There can't be much of a case for that, can there?

Yes there can. The class authors do want users of the class to call that method (or there is no need), but developers subclassing it may need to class it.
The decision on the visibility of methods is made by author of the class for whatever reasons.
>The class authors do want users of the class to call that method


Then they dont need to proteect it I would say. ;)