Method Access Question

[Higgledy Smith]

I am reviewing my notes. I comprehend why a method cannot be both abstract and final. But Why can't a method be marked abstract and private?

[Arno Reper]

because an abstract method must be declared in the subclass and a private method is only known into the 'class'...so the sub class can't declare the private method but must declare the abstract method. what is a problem...compiler error, i think

:-)

arno

[Higgledy Smith]

Thanks Arno. It is so obvious now, I feel dumb.

[Arno Reper]

no problem,
like my math's teacher always says there are no stupid question, only stupid answer.
lol
have a nice study time
arno

[Arno Reper]

ps : abstract is only use with public or protected...

[Edisandro Bessa]

Just in addition to Higgledy's post, can anyone explain why is not allowed to declared a method that is both abstract and synchronized ?

Both codes does not compile. Can anyone explain why ?

interface MyInterface{
      synchronized void doSomething(); [B]//Does not compile[/B]
}
 
abstract class MyAbstract{
  public abstract synchronized void doSomething(); [B]//Does not compile[/B]
}

[Vijay Gade]

I think it is because of the fact that abstraction has nothing to do with the implementation (where in, implementation is the method body). On the contrary, I am not being able to come up with an example for what if abstract and synchronized ARE in fact, allowed. I am sure someone else would surely come up with an example :-)

Thanks,
-Vijay

[Phil Kurian]

Hi,

What Vijay said is correct. The synchronized keyword is used in defining the implementation of a method. Abstract methods are supposed to be independant of implementation and thus shouldn't (and can't) have anything describing the implementation.

[Edisandro Bessa]

Thanks for your explanations but I am still not convicted about the reason that made Java creators prevent you declare a method as both abstract and synchronized.

For sure there's a reasonable cause that I'm unable to wonder.

As per my simple and poor concept about interfaces for example, it's defined as a contract to implementer classes. So, in my mind I think that I would obligate implementer classes to define synchronized methods through interfaces as shown in the interface definition I posted above.

But as you can see the compiler complains.

I'm not telling that it's Java is wrong, for sure there's a resoanable cause, but even after your explanations I'm still unable to determine it.

[ak pillai]

It is always a good habit to keep asking questions. I went to programming from a engineering background and I can't help asking questions. That is the best way to learn. Your question was not stupid at all.

[Vijay Gade]

Hi Edisandro,

Your question really got me thinking. The best answer that I could satisfy myself is this:

Synchronization is all about objects. Not object references. When you cannot have an object of an abstract class, what good is it to let you have a method that would be synchronizable?
In the following code, even if the abstract method g() was synchronizable, there is no use because g() of the abstract class AA will not be called anyway.

abstract class AA {
   abstract void g(); //-->Suppose g() was synchronized
   synchronized void f() {
      System.out.println ("f of AA");
      g(); //-- and you call g() from f(), which is synchronized
   }
}
class BB extends AA {
   void g() { //-- of course, you would HAVE to override g()!
      System.out.println ("g of BB");
   }
   void f() {
      System.out.println ("f of BB");
      super.f(); //-- super's f() called, but still, sub's g() would run!
   }
}
class Test {
   AA aa = new BB();
   aa.f();
}

Forgive me if I've confused you more, but this is the best example I could come across. I am sure the bartenders and sheriffs would take care of this problem if it continues.

Thanks,
-Vijay

[Vijay Gade]

p.s.

Forgot to add the main method in the Test class. aa.f() would fail to compile if not inside some method.

Thanks,
-Vijay

[Phil Kurian]

I'll also add that synchronization is not inherited by overriding methods - so even if you could declare a method to be abstract and sychronized, it wouldn't be any use - the implementer could chose whether they wanted it synchronized or not.

It's also worthwhile to remember what is hoped to be achieved by abstract methods. Abstract methods just provide a declaration of what an object should be able to do if calling a method with certain parameters. That's the whole point of abstraction. By declaring a method abstract, you are giving the implementer of the subclass free licence to make that method do anything he/she likes. All that is necessary is that it accepts the input variables, and returns a result of the correct type. So when a reference of the superclass type calls the method all it needs to know is what parameters to provide, and what it will return.

In the case of sychronization, you have no idea what the implementer is going to do with the variables you pass to it - or how the method will get the result. It may not need to be synchronized. Assuming the synchronized keyword had to be used, you would be enforcing a certain type of implementation on something which is supposed to be abstract. If this is the case, you'd have to ask yourself why you're creating this method as abstract in the first place.

[Edisandro Bessa]

Huummm. Phil's post makes sense for me now.

I think the key point highlighted by Phil is that developer could choose to implement a subclass that overrides this method as NOT - synchronized. So, supposing that a given method was defined as synchronized and the developer chose to override this method as not synchronizable he/se would break the contract. I think now it makes sense.

Thanks very much guys for your prompt replies, specially thanks to Vijay for making efforts to try explain me by using some code.

Thanks.