Explore topic-wise InterviewSolutions in .

JMS is a Java-based API that is like a GATEWAY to the MESSAGE-oriented middleware like SONICMQ, IBM MQSeries etc. It provides a mechanism for sending and receiving messages by making use of the publishing/subscribe (1 message multiple receivers) model or point-to-point (1 message 1 receiver) paradigm from one client to another. 

The following image describes how 2 clients can communicate with each other utilizing JMS providers.

J2EE DEFINES standards and specifications for various COMPONENTS such as e-mailing, database connectivity, security, XML parsing, CORBA communication etc that help in developing complex, reliable, secure and distributed servlets and applications that follow the client-server model. It provides various API interfaces that act as standards between different vendor adapters and J2EE components. This ensures that the application components are not dependent on vendor codes. Due to this, J2EE has been very popular among Java developers in the field of software development.

A Java servlet is typically multithreaded. This MEANS that multiple requests can be sent to the same servlet and they can be executed at the same TIME. All the local variables (not pointing to shared resources) INSIDE the servlet are automatically thread-safe and are request specific. Care has to be taken when the servlet is accessing or modifying the global shared variable. The servlet instance lifecycle for different requests are managed by the web container as follows:

• User clicks on a link in a client that requests a response from a server. In this instance, consider that the client performs GET request to the server as shown in the image below:

• The web container intercepts the request and identifies which servlet has to serve the request by using the deployment descriptor file and then creates two objects as shown below-
  • HttpServletRequest - to send servlet request
  • HttpServletResponse - to get the servlet response

• The web container then creates and allocates a thread that inturn creates a request that calls the SERVICE() lifecycle method of the servlet and passes the request and response objects as parameters as shown below:

• service() method decides which servlet method - doGet() or doPost() or doPut() or doDelete()- depending on the HTTP requests received from the client. In our case, we got the GET request from the client and hence the servlet will call the doGet() method as described below.

• Servlet makes use of the response object obtained from the servlet method for writing the response to the client.

• Once the request is served completely, the thread DIES and the objects are made ready for garbage collection.

The below IMAGE describes the different phases of the servlet lifecycle:

There are five phases, are as follows:

• Classloading phase: The first step is to LOAD the servlet class file (.class EXTENSION) by the web container.
• Instantiation phase: Next step is to instantiate the servlet by calling the default constructor.
• Initialize phase: In this phase, the init() method of the servlet is run where the servlet configuration will be assigned to the servlet. This is a lifecycle method provided by the Servlet interface which is run only once in the servlet lifetime.
• Request Handling phase: Here, the servlets provide services to different requests by making use of the service() method of the Servlet interface.
• Removal phase: In this phase, the destroy() lifecycle method of the Servlet interface will be called that is used for CLEARING the configuration and closing resources before servlet destruction. Post this, the garbage collection will TAKE place.

Servlets are server-side components that aid in developing powerful server-side APPLICATIONS. Ther are SERVERS that are platform-independent and follow various protocols as per the application design. The most commonly used protocol is the HTTP protocol. In Java, we can create servlets by implementing the Servlet INTERFACE that has 3 LIFECYCLE methods - INIT, service and destroy - and we can use the below classes for implementing servlets:

• javax.servlet.http.HttpServletRequest
• javax.servlet.http.HttpServletResponse
• javax.servlet.http.HttpSession.

Hibernate is an Object Relational MAPPER framework in Java that provides a layer of abstraction for retrieving or modifying data in the database. It handles all the implementations internally and the developer need not worry about how the connections to the databases are made, how the data translation from Java application to Database and vice versa happens. Hibernate SUPPORTS POWERFUL object-oriented concepts LIKE inheritance, association, polymorphism, compositions, collections that help in making queries using the Java approach by using HQL (Hibernate QUERY Language).

EAR stands for Enterprise Archive file and it consists of WEB, EJB and client components all compressed and PACKED into a file called .ear file. EAR files allow us to deploy different modules onto the application server simultaneously.

WAR stands for Web Archive file and consists of all web components packed and compressed in a .war file. This file ALLOWS testing and deploying web applications easily in a single request.

JAR stands for Java Archive file. It consists of all libraries and class files that constitute APIs. These are packed and compressed in a file called the .jar file. These are used for deploying the entire application INCLUDING classes and resources in a single request.

There are multiple ways for taking heap dump of Java process. Tools like jCmd, jVisualVM, jmap are AVAILABLE for this purpose. For example, if we are using jmap, then heap dump can be TAKEN by running the below command:

This heap dump contains live objects that are STORED in heap_dump.hprof file. Process ID (PID) of the Java process is needed to get the dump that can be obtained by using ps or GREP commands.

Heap dumps consist of a snapshot of all live objects on Java heap memory that are used by running Java applications. Detailed INFORMATION for each object like type, class name, address, size and references to other objects can be obtained in the heap dump. Various tools help in analyzing heap dumps in Java. For instance, JDK itself provides jhat tool for analysing heap dump. Heap dumps are also used for analysing memory leaks which is a phenomenon that OCCURS when there are objects that are not used by the application anymore and the garbage collection is not able to free that memory as they are still shown as referenced objects. Following are the causes that result in memory leaks:

• Continuously instantiating objects without releasing them.
• Unclosed connection objects (such as connections to the database) post the required operation.
• Static variables holding on to references of objects.
• Adding objects in HashMap without OVERRIDING hashCode() equals() method. If these methods are not included, then the hashmap will continuously grow without ignoring the duplicates.
• Unbounded caches.
• Listener methods that are uninvoked.

Due to this, the application keeps consuming more and more memory and eventually this leads to OutOfMemory Errors and can ultimately crash the application. We can MAKE use of the Eclipse Memory Analyzer or jvisualVM tool for analysing heap dump to identify memory leaks.

64-bit JVM is used in 64-bit operating systems whereas 32-bit JVM is used for 32-bit operating systems. In 64-bit JVM, we can specify more heap size memory up to 100G when COMPARED to the 4G limit of 32-bit JVM. Java applications take more memory while running in 64-bit JVM when compared to running the same APPLICATION in 32-bit JVM. This is because of the increased size of the ORDINARY Object Pointer. However, this can be bypassed by making use of the -XXCompressedOOP option of the JVM for telling to use 32-bit pointers. Additionally, 64-bit JVM uses 12 bytes object header size and a maximum of 8 bytes of INTERNAL references whereas the 32-bit JVM uses 8 bytes headers and a maximum of 4 bytes of internal references.

Since the JAVA application uses a connection POOL, it has active CONNECTIONS that would get disconnected if the database goes down. When the QUERIES are executed to RETRIEVE or modify data, then we will get a Socket exception.

JRMP stands for Java Remote Method Protocol which is used for Remote Method Invocation (RMI) for passing Java objects as arguments. It is an underlying protocol used by RMI for MARSHALLING objects as a stream during object SERIALIZATION for transferring objects from one JVM to other.

Connectors are used for PROVIDING standard extension mechanisms to provide connectivity to DIFFERENT enterprise information systems. A connector ARCHITECTURE consists of RESOURCE adapters and system-level contracts, both of which are specific to enterprise information systems. The resource adapters are plugged into the container. The connector architecture defines certain contracts which a resource adapter must support for plugging into J2EE applications like security, transaction, resource MANAGEMENT etc.

The design goals of J2EE architecture are as follows:

• Service Availability: To ensure that the application is AVAILABLE 24*7 to achieve required business goals.
• Data Connectivity: The CONNECTION between a J2EE application and LEGACY systems should remain compatible enough for ensuring business functions.
• Ease of Accessibility: The user should be able to connect to applications using any device and from anywhere.
• User INTERACTION: The user interaction should be seamless and should be able to connect to different devices like desktops, mobiles, laptops etc.
• Abstraction and Flexibility: The developer should FOCUS on business logic and the configuration details should be handled by the server.