Meaningless Drivel is fun!*
The moose likes Beginning Java and the fly likes Why protected method possible in Abstract class but in Interface it is not Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Why protected method possible in Abstract class but in Interface it is not" Watch "Why protected method possible in Abstract class but in Interface it is not" New topic
Author

Why protected method possible in Abstract class but in Interface it is not

Jigar Damani
Greenhorn

Joined: Jul 04, 2011
Posts: 8
I have some questions regarding core java.

1. Interface is 100% Abstract means all the methods are abstract in interface.

So why in interface we cannot declare abstract method but in Abstract class we can.
Ultimately abstract method in both (interface and abstract class) can be used by overriding by concrete class.

I know the actual functionality of protected i.e. only class in same package can access and child from other package can access.
But what is the actual (logical) reason behind such kind of feature?

2. Synchronization of constructors not allowed in Java - why?

I want to know the actual logic applied in both features.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7781
    
  21

Jigar Damani wrote:But what is the actual (logical) reason behind such kind of feature?

Well, basically it's because an interface is used to describe a public API, whereas an abstract class is usually used to partially implement a concrete class. And don't forget that any class that overrides an abstract method can make it public, even if it wasn't originally defined as such.

2. Synchronization of constructors not allowed in Java - why?

What would you synchronize them on?

Winston


Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Jigar Damani
Greenhorn

Joined: Jul 04, 2011
Posts: 8
Make constructor synchronized.
Construct is special kind of method so why we can synchronized method but not Constructor.

Constructor is not synchronized so how following situation would be handled by container?

Assume simultaneously 100 requests come for same Servlet (assume requests come at same time from all client to server).
On first request, container will create object of class and then thread. So if 100 request comes simultaneosly, How it will synchronized object creation?
So how container handle this situation?

How container first load Servlet into memory and at that time prevent remaining 99 request to wait?

I know this is question of Servlet forum but synchronized related question comes in mind based on this scenario so posted here.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18834
    
  40

Jigar Damani wrote:Make constructor synchronized.
Construct is special kind of method so why we can synchronized method but not Constructor.

Constructor is not synchronized so how following situation would be handled by container?

Assume simultaneously 100 requests come for same Servlet (assume requests come at same time from all client to server).
On first request, container will create object of class and then thread. So if 100 request comes simultaneosly, How it will synchronized object creation?
So how container handle this situation?


First, synchronization is on an instance. One hundred threads synchronizing on different instances doesn't do anything special. So, synchronizing on a constructor, would presumably for the case of one hundred threads trying to create the same instance? ... which is a concept not supported by Java.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Jigar Damani
Greenhorn

Joined: Jul 04, 2011
Posts: 8
Hi Henry,

Thanks for your reply.

Still I have one doubt.
Servlet would be loaded in memory only once for first request. For subsequent request it will not be loaded in memory.
If 100 concurrent request comes to server at the same time (assume it), so how this situation Container tackle?

Because for concurrent request Container try to load memory so it should load Servlet in memory 100 times.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7781
    
  21

Jigar Damani wrote:Construct is special kind of method so why we can synchronized method but not Constructor.

I ask again: What would it be synchronized on?

A synchronized instance method is synchronized on its instance, but in the case of a constructor there is no instance, because you're in the process of creating it.

A synchronized static method is synchronized on its class. I suppose this would be possible, but do you really want to be locking an entire class simply because you want to create an instance? Furthermore, since all constructors eventually call Object's, this would presumably involve locking out Object.class every time ANY object is created. Ooof.

Constructor is not synchronized so how following situation would be handled by container?

Assume simultaneously 100 requests come for same Servlet (assume requests come at same time from all client to server).
On first request, container will create object of class and then thread. So if 100 request comes simultaneosly, How it will synchronized object creation?

Well first off, I would suspect that the request is a Thread to the container.

Second, servlet creation is handled by a servlet container like Tomcat or Jetty, which may not even be written in Java; so I wouldn't even want to start guessing about how it goes about servicing multiple threads or servlet requests. Suffice to say that I trust the authors presumably thought this one through, since millions of copies of Tomcat have been running successfully for many years now.

So how container handle this situation?

Dunno; don't care. And unless you plan on writing a servlet container of your own (which sounds rather like re-inventing the wheel to me), are you sure you really need to know?

As far as Java is concerned, an object (with a few tortuous exceptions) is not available until its constructors have completed their task, so there is nothing to synchronize.

Winston
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7781
    
  21

Jigar Damani wrote:Because for concurrent request Container try to load memory so it should load Servlet in memory 100 times.

Maybe; although from what I gather, most containers use (or at least allow) a servlet pool.

Winston
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18834
    
  40

Jigar Damani wrote:
Still I have one doubt.
Servlet would be loaded in memory only once for first request. For subsequent request it will not be loaded in memory.
If 100 concurrent request comes to server at the same time (assume it), so how this situation Container tackle?

Because for concurrent request Container try to load memory so it should load Servlet in memory 100 times.


which is why the singleton pattern was invented/used -- although I highly doubt the servlet container restricts it to just one instance.

Henry
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3014
    
  10
Jigar: I agree with the others here; there's no need for synchronized constructors in Java. However I disagree with a few of the previous statements, which I respond to below. This does not change the fact that we don't need synchonized constructors, and Java does not have them. You can safely skip this post if you prefer.

Winston Gutkowski wrote:
Jigar Damani wrote:Construct is special kind of method so why we can synchronized method but not Constructor.

I ask again: What would it be synchronized on?

A synchronized instance method is synchronized on its instance, but in the case of a constructor there is no instance, because you're in the process of creating it.

That's not true really. Yes, you're in the process of "creating" it, or more precisely of completing initialization of the instance. But there is an instance, available as "this" (as in "this.x = x" for example). You could even synchronize on it:

If a constructor could be synchronized, I would expect it to be equivalent to this, synchronizing on the current instance. Much like a synchronized instance method.

The real issue, already asked in this thread, is why would you ever want to do this. There isn't really any good use case I know of.

I suppose you could sync on the class instead, but that doesn't make sense to me because a constructor should be primarily about initializing the instance fields, not the class fields. On the other hand, in the rare cases you need to modify a class field in a constructor, you may indeed need some sort of sync to make it thread-safe. But that can still be achieved with a sync block or other techniques if needed.

Winston Gutkowski wrote:A synchronized static method is synchronized on its class. I suppose this would be possible, but do you really want to be locking an entire class simply because you want to create an instance? Furthermore, since all constructors eventually call Object's, this would presumably involve locking out Object.class every time ANY object is created. Ooof.

But there's no reason to think that the Object() constructor need be synchronized as well. In this model, you would need to get a lock on the class with the synchronized constructor. The other constructors can be called with no additional sync (unless they themselves declare synchronized constructors)

Cheers.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Why protected method possible in Abstract class but in Interface it is not