Java-Success Blog: Top 20 Java technical interview questions and answers for experienced Java developers -- Part 3

Java Interview Questions and Answers

Most applications built today are web based and it is vital that you have a good handle on the web paradigms.

Q11. HTTP is a stateless protocol, so how do you maintain state? How do you store user data between requests? Is it a good thing to maintain state?
A11 . This is a commonly asked interview question. The “http protocol” is a stateless request/response based protocol. You can retain the state information between different page requests as follows:

HTTP Session. A session identifies the requests that originate from the same browser during the period of conversation. All the servlets can share the same session. The JSESSIONID is generated by the server and can be passed to client through cookies, URL re-writing (if cookies are turned off) or built-in SSL mechanism. Care should be taken to minimize size of objects stored in session and objects stored in session should be serializable. In a Java servlet the session can be obtained as follows:

HttpSession session = request.getSession(true); //returns a current session or a new session

//To put/get a value in/from the session 
Name name = new Name(“Peter”);
session.setAttribute(“Firstname”, name); //session.putValue(…) is deprecated as of 2.2

session.getAttribute(“Firstname”);//get a value. session.getValue(…) is deprecated

//If a session is no longer required e.g. user has logged out, etc then it can be invalidated.
session.invalidate();

Hidden Fields on the pages can maintain state and they are not visible on the browser. The server treats both hidden and non-hidden fields the same way.

URL re-writing will append the state information as a query string to the URL. This should not be used to maintain private or sensitive information.

Http://MyServer:8080/MyServlet?Firstname=Peter&Lastname=Smith

Cookies: A cookie is a piece of text that a Web server can store on a user’s hard disk. Cookies allow a website to store information on a user’s machine and later retrieve it. These pieces of information are stored as name-value pairs. The cookie data moves in the following manner:

Q12. Are states bad? if yes, why?
A12. State isn’t bad, it’s a necessity. But favor stateless architecture for the number of reasons described below.

You should ALWAYS make your systems not only as simple as possible, but also as scalable as possible. In a clustered or load balanced environment with multiple servers, maintainig of states requires the user to always return to the same server using sticky sessions or else the whole system breaks down. The answer to this problem is using sticky sessions which force the load balancer to send traffic for a given user to the same server every time. The LB is hardly balancing load if it can’t decide who gets the traffic. There are other more complicated methods for sharing sessions across multiple servers via true clustering, but getting this right is more complicated and time consuming.
State can also be problematic from a security point of view due to sharing the state between the client and server. There are methods around this problem using encryption and other techniques, but again can complicate your solution.

The single page rich web pages making a number of RESTFul web services via ajax requests is a very popular architecture. Making server side RESTful web services stateless is a central tenant of REST. A truly stateless RESTful web service is not only incredibly flexible and scalable thing, but also takes responsibility for handling security and deciding who can access what in the system. Since there is very little "under the covers stuff" happening to try to make this stuff “easier”, you are free to implement security however makes sense for your system.

Q13: What is your understanding of the following terms ... forward, redirect (aka sendRedirect), and post-back?
A13:

Forward

a forward is performed internally by the servlet.
The browser is completely unaware that it has taken place, so its original URL remains intact.
You can set request attributes from the forwarding request (e.g. s servlet) to the resource to which it is forwarded (e.g. JSP).

Redirect

A redirect is a two step process, where the web application instructs the browser to fetch a second URL, which differs from the original.
A browser reload of the second URL will not repeat the original request, but will rather fetch the second URL. This makes the second resource link book markable.
A redirect can be marginally slower than a forward as it requires two browser requests as opposed to one with the forward.
Any attributes placed in the original request scope are not available to the second request, since it is a new request.

Post-back

The HTTP verb POST is used to send data to the server in the body, with XML, JSON, or form fields.
The term "back" really means that you retrieved the page initially with a GET verb to show the user the <form> elements, and at the end you're sending data back. So, a PostBack is a POST request for a page that is not the first request.

Spring framework is very popular and can be used as an IoC container, MVC2 web application framework, JDBC and JMS template, and so on. So you need to be prepared with basic Spring job interview questions.

Q14:What are the different ways can you wire up your dependencies using Spring?
A14: 3 different ways. You can combine all 3 ways.

Using an XML based application context file as demonstrated here in STEP 3.
Using annotations @Resource, @Component, and @Service as described here, including the @Autowired annotaion.
Using the Java config using the annotations @Configuration and @Bean. This is demonstrated via wiring up Apache Camel routing using Java based Spring configuration as shown in step 2 to see how it is done. This also shows @Autowired, @Service, and @Resource annotations in action.

Q15. Can you describe the following bean concepts

Spring managed beans life cycles.
Bootsrapping the initial Spring bean.
What is a bean factory?
How would you create an application context from a web application?

A15. The answers are clearly explained in this Spring training tutorial on bean life cycle.

Q16. Can you list some real life scenarios where you will use Spring AOP?
A16.

1. You can use the Method AOP interceptors for dead lock retry and logging. Occasionally, you get deadlocks in databases and you database management systems resolves deadlocks by aborting a transaction. These transactions can be retried with the help of Spring AOP method interceptors. This is clearly explained in Step 3 under How do you wire up transaction manager?

2. Another area is service retry service in general where any failed remote service calls can be retried at a certain interval say every 10 seconds for 3 times.

3. for auditing purposes.

4. Spring itself uses aspects for things like transaction management, security, and caching.