• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

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

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Jigar Damani
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 23958
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Jigar Damani
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 23958
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Master Rancher
Posts: 5116
82
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
get schwifty. tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic