问题
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
回答1:
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.
回答2:
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.
回答3:
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.
回答4:
Servlet implementation classes can have constructor but they should be using init() method to initialize Servlet because of two reasons, first you cannot declare constructors on interface in Java, which means you cannot enforce this requirement to any class which implements Servlet interface and second, Servlet require ServletConfig object for initialization which is created by container as it also has reference of ServletContext object, which is also created by container.
Servlet is an interface defined in javax.servlet package and HttpServlet is a class and like any other class in Java they can have constructor, but you cannot declare constructor inside interface in Java. If you don't provide an explicit constructor than compiler will add a default no argument constructor in any Servlet implementation class. Another reason that you should not initialize Servlet using constructor because Servlets are not directly instantiated by Java code, instead container create there instance and keep them in pool. Since containers from web servers like Tomcat and Jetty uses Java Reflection for creating instance of Servlet, presence of no argument constructor is must. So, by any chance if you provide a parametric constructor and forget to write a no argument constructor, web container will not be able to create instance of your Servlet, since there is no default constructor. Remember Java compiler doesn't add default no argument constructor, if there is a parametric constructor present in class. That's why it's not advised to provide constructor in Servlet class.
来源：https://stackoverflow.com/questions/2920616/why-we-cant-initialize-a-servlet-using-constructor-itself