Hello,
In other words, your
servlet class that extends HttpServlet should not override the service(...) method because:
You can add support for different behaviors for different request types by overriding the appropriate doXXX(...) method. This makes sense since a servlet should not return a "successful" response (i.e. status code in the 200 range) for a DELETE request unless it actually did delete the requested resource.
The default service(...) method supports modification dates (i.e.conditional GET requests) by using the getLastModified(HttpServletRequest) method (which you can override to improve performance).
You get automatic support for TRACE, OPTIONS, and HEAD requests (although you can override the doHead(...) method (in servlets 2.3+) to improve performance).
you could override service directly (to "improve" performance by reducing the number of method calls) and include the appropriate logic to replace the aforementioned functionality, but why re-invent the wheel?
And if performance is really your primary concern, never "micro-optimize" before profiling. Chances are, the code you've written has some bottlenecks that make the performance impact of these extra method calls negligible. As a matter of fact, the code you write to replace the functionality you are losing might just contain some of these bottlenecks.