Java is portable not its JVM

"Java is portable" has become the ubiquitous quote in the technological world and this is one of the reasons for the popularity of Java.

But what is the logic behind its portability. It is simple. There is a JVM - Java virtual machine , which will convert the java byte code into native code.

So Code is compiled into a byte code which is architecturally neutral and this code is then converted to machine((OS) dependent code by the JVM specific to the OS.

Thats smart is not it. Write once Run Everywhere .....

JVM is basically an interpreter that interprets the class files and is different for different OS.

Servlet Constructors

Very often Java programmers are thrashed with this rather awkward question "Can you have Constructors inside Servlets"..in the interviews and when the prospective bride in this case the person facing interview blushes the prospective bride groom in this case the interviewer is overcome with a sense of sadistic smile displaying itself uglyly on his face..... Comeon do you really use Servlets in first place after the very cuter younger brother of servlets "The JSPs" have come or if at all you are among those nerds who still prefer to use Serlvets would you at the least be bothered if Servlets have constructors or not.

Anyways lets get into the center of the topic the much out of use Servlet constructor . The answer for this is "Yes we can have constructors inside Servlets" bingo you that .Thats such a simple issue and as usual thats not as simple as it looks like... You can have a constructor as long as the constructor has the access type public and there are no arguments for it. Any other access type would simply throw an exception when the server runs and you call the servlet. And saddest of the sad part is that one of my interviewers actually argued with me that there is no such thing as Servlet constructor. This is by default usually inserted into the Servlet and the default servlet Constructor has an assess type of public.

Ex For how a Servlet constructor would look like:


public HelloWorld(){
super();
}


Now in the first place why in the hell do we need that public Constructor when as any novice to the Servlets would put to you that "The container calls the init() method. This method initializes the servlet and must be called before the servlet can service any requests. In the entire life of a servlet, the init() method is called only once." and that means all initialization happens in this method." The blame squarely is on the container for not allowing us to play with the Constructors of the servlets we would be writing.

This, in my perspective is to stop the user from fussing with the initialization and instantiuation of the servlets. The init() method has access to the "ServletConfig" object in the servlet and as i have already mentioned there are no arguments for a servlet constructor. Hence init() methods score over the constructors here. The servlet container however allows a public no argument constructor as it is mandatory for any object created in java to have a constructor if it is not an interface and thereby limits the coder/programmer from scrubbing the code to what ever he has in the mind. Well that might be a vaguer explanation. Moreover from this constructor the super constructor - that is the HttpServlet constructor is also called at.

Hope this one has been a small eye opener on Servlet constructors. Will add more articles on Java related topics in days to come. Till then scrub your hair, laugh a lot or do what ever you wanna do but keep coming back to my blog whenever you think of JAVA as more Java gyaan will be explored.

"JAVA Beans" and "COFFEE Beans" have one thing in common apart from beans in their spelling :: "Both are bitter but are addictive"