• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Method Access Question

 
Ranch Hand
Posts: 193
Hibernate Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 193
Hibernate Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Arno. It is so obvious now, I feel dumb.
 
Arno Reper
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
ps : abstract is only use with public or protected...
 
Ranch Hand
Posts: 584
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ?
 
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 584
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 288
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

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
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 584
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic