views:

274

answers:

3

Why do we have to override init() method in Servlets while we can do the initialization in the constructor and have web container call the constructor passing ServletConfig reference to servlet while calling constructor?

Ofcourse container has to use reflection for this but container has to use reflection anyway to call a simple no-arg constructor

+7  A: 

Since a constructor can not be part of an interface, it can not be "formally" specified within the Servlet API, unlike normal methods. Moreover, since Java has no destructors, a destroy method is needed anyway, so it defining the corresponding init method makes the API more consistent and easier to use.

Using reflection to detect/verify constructor parameters would just unnecessarily complicate things, and I don't see any added value.

Péter Török
Well, reflection is used anyway, and the added value would be that you can make your servlets immutable. There are many examples of classes which do initialization in the constructor but which have a corresponding close method; pretty much every single stream class works this way.
gustafc
@gustafc, since you are not supposed to store (nonstatic) data in your servlets anyway, immutability doesn't really make a difference. Stream classes are a good example; however note that these are concrete classes, not interfaces.
Péter Török
There are very good reasons for having (immutable) non-static state in servlets. The whole point of `ServletConfig` is that you can instantiate the same servlet several times and have it do (slightly) different things.
gustafc
@Peter, though unrelated don't we have a finalize() method which can be used as a destructor?
Reddy
@gustafc, sorry I didn't understand what is immutability... can you please explain?
Reddy
@Reddy, `finalize()` is not a destructor and practically should not be used. See [What is the purpose of Finalization in java?](http://stackoverflow.com/questions/2450580/what-is-the-purpose-of-finalization-in-java), and for further details, [this article](http://www.codeguru.com/java/tij/tij0051.shtml).
Péter Török
@gustafc, note that `ServletConfig` does not mandate using nonstatic data members.
Péter Török
@Reddy, immutability means that you can't change an object after it has been initialized (in Java, that means after the constructor has finished). It's genereally considered a Good Thing 'cause it makes it a lot easier to reason about your code.
gustafc
@Péter Török: If you put stuff into static fields, what happens then when you have the same servlet class mapped to several different servlets with different configurations? (Answer: Whatever servlet was loaded last overwrites the values set by the previously loaded servlets.)
gustafc
@gustafc, fair enough, my comment was poorly worded - just skip "nonstatic".
Péter Török
Thanks a lot Péter and gustafc. Its fully clear now.
Reddy
+2  A: 

Servlet object has a well-defined life cycle where creation and initialization steps are distinct. Usually you don't want to do heavy and unreliable work in constructors, e.g. getting DB connection pool or initializing cache. You have a chance to do it after a Servlet object is successfully created.

Also, here http://oreilly.com/catalog/jservlet/chapter/ch03.html is a historical reason:

The init() method is typically used to perform servlet initialization--creating or loading objects that are used by the servlet in the handling of its requests. Why not use a constructor instead? Well, in JDK 1.0 (for which servlets were originally written), constructors for dynamically loaded Java classes (such as servlets) couldn't accept arguments.

So, in order to provide a new servlet any information about itself and its environment, a server had to call a servlet's init() method and pass along an object that implements the ServletConfig interface.

Also, Java doesn't allow interfaces to declare constructors. This means that the javax.servlet.Servlet interface cannot declare a constructor that accepts a ServletConfig parameter. It has to declare another method, like init(). It's still possible, of course, for you to define constructors for your servlets, but in the constructor you don't have access to the ServletConfig object or the ability to throw a ServletException.

leopoldkot
Thank you leopoldkot
Reddy
A: 

One reason is that you don't have access to the ServletConfig object in the constructor. The ServletConfig object is created after the constructor is called and before init() is called. So, you cannot access servlet init parameters in the constructor.

Michael Angstadt