J2EE Interview Questions and Answers for 2025

Struts is an enhanced web application framework with a no-limitation source that broadens the Java Servlet Application Programming Interface (API). It was formerly known as Jakarta Struts when it was created by Mcclanahan Craig in the year 2000 and donated to the foundation, Apache, which was replaced in 2007 by the Struts 2. 

Struts frameworks are large frameworks used to develop business-large apps with designs that are easy to use. They are referred to as the legacy that should be adhered to if subsequently required by the user. 

The Struts Framework: 

• The struts framework provides the Action and controller servlets, which are incorporated into the libraries and Integrated Development Environment (IDE). They are included in the frameworks Extensible Markup Languages (XML) and on boarded onto a standard architectural platform known as the Model, View, Controller (MVC), which is used to develop the Java 2 Platform, Enterprise Edition (J2EE ). 
• This model (the addition of logic to interrelate with the available database) is distinguished from the view (which is the HTML page seen by the user) and controller.  
• The servlets are used at the commencement of the project. The action series develops the displayed user templates, while the controller servlet delivers the information between both view and model users.  
• Struts configurations are established by programmers such as config.xml which maintains the model, controller, and view display. 
• Servlet maps are then used to demand Struts Action Objects (SAOs) using the earlier established configuration. 
• In the event of an information alteration, an update to the Extensible Markup Languages (XML) file would be sufficient. 
• Data is stored momentarily as Action Form Objects (AFO), and orders are executed. 
• A string (Action Forward) is brought back by the Model to build the controller and direct it to forward an output page to the user. 
• After processing requests, Action Objects sorts out new data and sends the results to the right display point. 
• The JavaBeans form is then used to pass information about the model and client pass. 
• The library custom tag is used to document the content of the beans, thus the Java code will not be needed. 
• Struts templates called the “Tiles mechanisms” are then used as a layer for representation. 
• The Java annotations are used to represent information to create applications that can be integrated into other frameworks. 
• Anytime an order is placed, an action is created and the servlet answers the model calls. 

The use of struts is simplified by the provision of UI, control, and action tags. 

• The Strut themes  
• HTML (Default theme) 
• css_html  
• simple 

Advantages of Struts in the J2EE Framework 

• The struts framework assists in binding received files with enterprise logic and the display of deliveries using HTML.  
• Struts encourages the development of flexible, adaptable, and sustainable apps built on strong technological standards like the Jakara Server Pages (JSPs), JavaBeans, and Extensible Markup Languages (XML). 
• Due to the Model, View, Controller (MVC) framework, it is easy to use, efficient, and easily understood by developers and has less creation time. 
• As a result of XML and property files, changes can be made to files without having to alter the original Java code. 
• It aids developers in properly maintaining documentation.

Before designing an Interactive User Interface (UI) for J2EE apps the following points should be considered. 

• Knowledge of the proposed users 
• The simplicity of the interface 
• The need for consistency, standard, and the application of common UI elements 
• An efficient and flexible page layout 
• The resourceful use of graphic textures and colors for aesthetics 
• Clarity of design 
• Freedom for user-based control 

The J2EE interface gives rise to a group of minimal-level routines in form of servlet APIs that allow developers the opportunity to directly design the release that is streamed into the search interface. The APIs serve as the foundation for which the hierarchical layers are set, which include the Interface displayer, and front controller feature needed for a common several-paged application, all these simplify the dynamic output release. Also, the UI and controller framework possess many different attributes which serve several functions.  

Several UI technology methods exist when creating a J2EE application 

• JSP 
• JSF (JavaServer Faces) 
• Basic HTML 5 and JavaScript 

There are different conditions to use the above UI technologies based on the benefits of one over the other in a given scenario. 

One of the most frequently posed J2EE scenario based interview questions, be ready for this conceptual question. Here is how to approach this question -

HashTables are:

• Also called hash maps
• Value map keys embeds the class of the dictionary, and maps keys to values.
• The values contained in the hash tables are based on the keys.
• It uses a hash feature to collate an index called the hashcode which is input into a collection of lists, each of which serves as a todo called ‘bucket’, and its position is identified by calling out the method of the hashcode().
• During a search, the key is hashed and this shows where the respective value is kept.
• The J2EE hashtable class possesses specific and unique elements, prevents null values or keys, and can be synchronized

The workings of J2EE

Hashtable was previously a part of the main Java and is a standard dictionary implementation. J2EE was designed with the hashtable added to its framework also to implement a map. It saves keys and values in the hash table.

During the utilization of a hashtable, the following steps are taken:

• Indicate the object to be used as a key
• Incorporate the value you like to include in that key
• Hash the key
• Use the generated hashcode as the index (that is, where the values are saved on the table)

Available Constructors In The Hashtable Class

Example of a hashtable for a mini-client book

In a normal setting, the hash function assigns a specific bucket to each key, however, in certain instances, some hash table designs utilize a flawed hash function that may result in a hash collision where the function develops an exact index for different keys.

Properly dimensioned hashtables have lookup times that are not determined by the number of elements on the table. Also, some designs permit alterations like additions and deletions to be made to the value-key pairs.

Hashing best describes the concept of, a space-time trade-off where an infinite memory exists and all the keys on a table can be used directly as an index to look up their value within one access memory. Alternatively, where an infinite time exists, values can be saved without considering their keys, and elements can be retrieved utilizing a binary or linear search.

Hibernate is a powerful framework used to keep and retrieve data from a Java platform to a database table. It is a high-operational Object-Relational Mapping (ORM) tool in J2EE that maps classes to tables, often in rows, and assigns values to mapped table columns. It is also used to map various J2EE data types to the SQL. Hibernate translates the HQL queries into the usual SQL queries, which subsequently the database actions.

It is a persistence platform, that stores data permanently to storage platforms like SQL databases and fetches them back at any period such as towards or after the end of the execution processes.

Hibernate-supported databases include: 

• The MySQL database 
• PostgreSQL database 
• Oracle database 
• DB2/NT database 
• Sybase SQL server database 
• Microsoft SQL Server Database and others. 

The Architecture of Hibernate: 

There are 3 available configurations in Hibernate; 

Hibernate.cfg.xml 

It is an XML file that is saved and rooted within the application's classpath, and this file is what encompasses the Hibernate configuration. 

Hibernate.properties 

It is a property file that bears the pair of value-keys for the various Hibernate configurations. 

Program configurations 

This represents the Java file configurations that are to be done manually. 

Hibernate Query Language (HQL) is a type of query language of the Hibernate framework that operates with the use of recurring objects and their persisting properties. The syntax of HQL is similar to that of the SQL but differs in that it executes object and property operations of classes that are persistent instead of using columns and tables, however, the SQL statements can be used directly in the Hibernate framework. 

The Hibernate framework converts the queries in HQL into specifically designed databases to execute specific actions. The query platforms are the techniques and feature functionalities required to display, operate, and navigate the HQL query in an object-defined manner. 

Certainly, there are drawbacks to the use of Hibernate, despite its high performance and exquisite nature. 

• Need to learn numerous APIs 

The daunting task and enormous effort required to learn Hibernate APIs stands as a discouraging factor, although Hibernate in itself is a simplified framework to use, however, it is often tasking to learn how to use it.  

• Difficulty Debugging 

With Hibernate, oftentimes, debugging files to optimize performance may be challenging. 

• Slower than a Java Database Connectivity (JDBC) 

Due to the numerous SQL statements generated by Hibernate during its runtime, this slows down its activities such that a basic JDBC seems faster in application compared to Hibernate. 

• Not recommended for Batch processing 

The basic JDBC is what remains recommended for batch processing for better functionality. 

• Unsuitable for minimal projects 

Small and less-sized projects are those with fewer tables and columns, this defeats the aim of using Hibernate, hence it is unsuitable and unrecommended. 

• Prevents multiple inserts 

Using the Hibernate framework negates the application of some types of queries that are not JDBC-supported. For instance, it prevents the addition of multiple insert objects like persistent data to the database using the same particular query. Hence, a developer will be required to write a different query for individual objects. 

• Develops complex queries 

Hibernate generates several joint queries causing multiple query conversations for complex data. The recurrent mapping between objects and queries results in a reduction in the level of performance and prolonged query conversation time interval.

These are the benefits of using Hibernate: 

1. No new written code is required to map it because it operates the mapping of the J2EE data classes to the table of the database using configurations, annotations, or an XML file. 
2. The objects in this Java tool can be directly saved and retrieved by the application of the framework's simplified APIs. 
3. In an event of an alteration made to the table or any of its databases, a basic change to only the XML file and related Java class would suffice. 
4. Only known Java files and data types will require to be worked on, there often is no need to work on the SQL data type. 
5. No application server is necessary for its effective functionality. 
6. With easy and simplified retrieval techniques, the complexity of the database is minimized. 
7. The data-access query used by Hibernate is highly simplified and easy to operate 

Web components can be defined as a conglomeration of different technological methods that permits the development of custom elements that are reusable with their enclosed feature functionalities made away from the remaining codes, which are subsequently used in web applications. 

The Web Components are helpful to developers in the context of reusing codes that are beneficial to their developing processes. This however is not as basic and easy as it may appear for the custom markups. For example, the complex HTML and its related patterns, may sometimes still need written custom UI controllers because overusing them recurrently can render a design messy.  

Web components aim to proffer solutions to such problems associated with reusing codes, using its major technologies which when combined, create a wide range of custom elements with enclosed functionality that can be recycled for reuse wherever applicable without the risk of code collision. 

The three main web component technologies are: 

Custom Elements 

These are a group of APIs in a JavaScript set that permits the expansion of custom elements and their patterns, which can be applied as recommended in the desired interface. 

Shadow Document Object Model (DOM) 

These are a group of JavaScript APIs used to combine an enclosed ‘shadow’ to an element that is separate from the main DOM, and in charge of related features. With this, elements feature privacy can be maintained, so they can be designed, scripted, and styled as pleased without colliding with other aspects of the documents. 

HTML Templates 

These are elements that assist the writing of markup templates that are not shown on the display page. These can be recycled repeatedly as the foundation of a customs elements’ structure. Such as <template> and <slots>. 

The Implementation Strategies For The Web Component: 

1. Design a class specifically for the web component features using its syntax  
2. Register the new custom element using the custom element registry. Indicate the name to be identified with, the specific class, and maybe the location where the element was retrieved from. 
3. Include a shadow DOM to the custom element if needed.  
4. Define the HTML template using the basic DOM and clone the template before attaching it to the shadow DOM 
5. Make use of the custom element in a similar way you would use any common HTML feature on the home page 

Object Relational Mapping (ORM) is a feature tool used to create and establish a link between a relational database and an object by generating a navigation plane between the object state and the column of the database. It can operate several databases such as updates, inserts, and delete feature functionalities. 

ORM serves as a bridge between Object-Directed Programs(ODP) and relational databases. 

While using different ODP languages, there is a need to create different operational performances such as creating - reading - updating - deletion (CRUD) data.

The ORM frameworks are: 

1. Hibernate 
2. ORMLite 
3. iBATIS 
4. TopLink 
5. JPOX 

The types of mapping include 

• Single-to-single 

Here, every feature in an entity is related to a particular feature in another entity. 

• Single-to-numerous 

In this entity, one particular feature can be related to multiple features in another entity. 

• Numerous-to-single 

Multiple features in an entity are related to a single feature in another entity. 

• Numerous-to-numerous 

Several features in an entity are related to multiple features in another entity. Here, either of the sides can represent the owning side. 

The functioning of the ORM within the J2EE framework is executed by setting up maps which are of two types, based on direction. 

Unidirectional mapping relationship 

Here, the relationship is such that only one party can make properties referral to the other. Only one side is established within this framework and empowered with the ability to make updates to the database system. 

Bidirectional mapping relationship 

In this relationship, two sides are involved, one is the owing side which is seen in the unidirectional relationship and acts similarly, and the other aspect is the inverse side, with this structure, every feature aspect possesses a relationship platform and can make a referral of entities or properties to the other. 

Hibernate is an interface existing between the Java app and the Hibernate framework. Several session methods are existing and are in use within the Hibernate framework such as the Save () and Update() methods.  

Save () Method  

Also called the Hibernate save is a feature that can be used to store entities in the database. This method is onboarded outside the confines of a transaction resulting in the storage of only primary entities.  

The save() method makes a TRANSIENT entity PERSISTENT by associating it with an org.hibernate.Session. 

Before the persistence of an entity, the save() method links a developed identifier to the identification field, after it is returned. Therefore, it must quickly execute the SQL statement to be inserted regardless of whether it is within or outside the transaction. This is because identifiers are created solely for the main entity, and this can result in inconsistency of data if there is a failure to flush the changes made or in cases where the application develops errors. 

Update () 

The update () method is a more simplified pattern that functions thus, 

1. It operates the SQL update queries for feature entities that are persistent. 
2. It discards transient objects lacking an identifier-associated entity. 

Just To Note: 

• For entries that are persistent, the save() method functions as an update() method and operates the update SQL queries. 
• For entries that are detached, an identifier already exists within such framework and the pattern of behavior of the save() method will be dependent on the identity generator when operating the insert query. 
• Applying both the Save () or Update () methods will provide both functions on the premise of identification fields that are available within the entity, and in most instances, it is preferred to use both as opposed to using just the save() or the update () methods. If the identifier is absent, the framework summons the save () entity, and if it is present, the update () entity is called. 
• Both the save () and update () entities can be utilized with both persisting and transient entities. In this case, the entities that persist will be acted upon by the update () method and get updated, while the transient entities will be inserted into the framework's database to be saved. 

One of the most frequently posed J2EE developer interview questions, be ready for this conceptual question.

The get() and load() methods are other Hibernate techniques used to retrieve data from a database. At a glance, both of these methods may look similar but are innately distinct from each other. 

The get() method retrieves an object by deriving it from the cached Hibernate database while the load() method retrieves data by returning the reference of a hypothetical object that may not be in existence, it loads the data either from a database or a cache after accessing other objects properties. 

The use of get() in retrieving non-existing data would automatically redirect it to null, this is because it attempts to load the data immediately after it is called up. This is different with the load() method, here, it is possible to print the ID, however, just after attempting to access other fields, a database query is fired and yields org.Hibernate.objectnotfoundexception. This happens when there is no record located in that particular identifier because it is specific to the Hibernate runtime exception, therefore, there is no need to catch it directly. 

To reiterate the differences between the get() and load() methods; 

• The data is loaded by get() at the instant it is called upon while load() sends a proxy object and loads the data at instances when it is specifically needed. 
• The Load() method facilitates sluggish loading, which makes it a better method. 
• The load() method throws an exception when the sought data is unavailable, therefore, it can be utilized when there is the certainty of the existence of data in the database 
• Get(0) can be used to ensure the presence of sought data in the database. 

By sharing issues and helpful solutions, design patterns in programming enable you to take advantage of the collective knowledge of the developer community. The definition and context of an issue, a potential solution, and the results of that solution must all be included in a design pattern.

Design patterns can be divided into two groups for the sake of J2EE application architecture: those that address general software development concerns and those that focus on J2EE -specific issues.

The bare minimum of known issues that a sound application architecture should address is identified by J2EE specific design patterns. When it comes to directing the creation of architecture, the first category, which includes software development patterns that aren’t J2EE specific, performs just as well.  

A staple in J2EE design patterns interview questions and answers, be prepared to answer this one using your hands-on experience. Here is the answer -

There are three categories of design patterns in J2EE, each with various subcategories:

Presentation Layers Design Pattern: 

1. Intercepting Filter Pattern: A request and response can be intercepted and altered both before and after the request is complete with an intercepting filter pattern. It is used when a user needs centralization, and common processing across requests, including recording details about each request, compressing an outgoing answer, or examining the data encoding method of each request. 
2. Front Controller Pattern: In a scenario where a user wants to create a centralized request handling method so that all requests are handled by a single handler, the front controller pattern is best suited for this. This handler can handle requests’ authentication, authorization, logging, and tracking before forwarding them to the appropriate handlers. 
3. View Helper Pattern: The processing of the data for the business model is separated from the static view, such as a JSP.
4. Composite View Pattern: Building composite views from several subviews is the responsibility of the composite view pattern. The composite view pattern enables the framework to be linked to both the content and the layout. This greatly streamlines the application’s development process.

Business Layer Design Pattern: 

1. Business Delegate Pattern: The business delegate hides the actual implementation of the business services and serves as a client-side business abstraction. It lessens the connectivity between the system’s business services and presentation-tier customers. 
2. Service Locator Pattern: It is a design pattern used in software development to tightly group the steps necessary to acquire a service under a robust abstraction layer. This design makes use of a central register called the “service locator,” which, in response to a request, returns the data required to carry out a certain operation. When service clients or service consumers request specific instances of a service, the ServiceLocator is in charge of providing those instances.
3. Session Façade Pattern: The creation of enterprise apps is the primary use of the Session Façade design. The pattern captures the interaction that takes place between the low-level components. It is implemented as a Session EJB, a higher-level component. Then, in order for the app or a component of the app to work, it must have a single, standard interface.
4. Transfer Object Pattern: When a user wishes to send data with various attributes all at once from the client to the server, the transfer object pattern is used. The Transfer Object Pattern is a straightforward POJO class with getter and setter methods that are serialized to enable network transfer 

Integration Layer Design Pattern: 

1. Data Access Object Pattern: The DAO pattern is used to differentiate between high-level business services and low-level data accessing APIs or actions.
2. Web Service Broker Pattern: XML and web protocols are both used by the web service broker. This pattern can be used to expose and broker the services. It serves as a general gateway or addresses that the client apps can use to access a wide range of services.

JTable class is a component of the Java Swing Package, the JTable class is typically used to show or update two-dimensional data that has both rows and columns. It’s a lot like a spreadsheet. This creates a table with data arrangement.

JTable Constructors: 

1. JTable() creates a table with blank cells.
2. JTable(int rows, int columns) creates a table with the dimensions or rows * columns. 
3. JTable(Object[][] data, Object []Column) creates a table with the supplied name, and []Column specifies the names of the columns in the table.

Features of JTable: 

1. addColumn(TableColumn []column) adds a column to the end of the JTable. 
2. clearSelection() selects each row and column that have been chosen. 
3. editCellAt(int row, int col) edits the specified indices if they are valid and the corresponding cell is editable.
4. setValueAt(Object value, int row, int col) sets the cell value as “value” for the location row, col in the JTable.

Below is an example of a Java JTable: 

import Javax.swing.*;
public class TableExample {
JFrame f;
TableExample(){
f=new JFrame();
String data[][]={ {"101","Amit","670000"},
{"102","Jai","780000"},
{"101","Sachin","700000"}};
String column[]={"ID","NAME","SALARY"};
JTable jt=new JTable(data,column);
jt.setBounds(30,40,200,300);
JScrollPane sp=new JScrollPane(jt);
f.add(sp);
f.setSize(300,400);
f.setVisible(true);
}
public static void main(String[] args) {
new TableExample();
}
}

Output: 

The two patterns are the Proxy Pattern and the Chain of Responsibility.

The Proxy Pattern enables users to build a middleman that serves as an interface to another resource while simultaneously masking the component’s inherent complexity. When using a Proxy pattern, there is an assured response to the request if the communication between the client and server locations is functional.

The Chain of Responsibility pattern processes a request from the client sent to a chain of objects, which is used to establish loose coupling in software design. Later, each object in the chain will choose for itself who will handle the request and whether or not it has to be forwarded to the following object in the chain. The response is not certain in the case of the Chain of Responsibility. It implies that even if the request makes it all the way to the top of the chain, it might not be handled.

One of the fundamental Java EE design patterns is the business delegate pattern. It is utilized to disconnect or lessen the link between the business services and the presentation tier. Additionally, the lookup function in the business layer code contained within the presentation tier code must be removed in order to hide the implementation details of the services.  

The business delegates frequently take on the role of adapters in order to invoke the business objects that are present in the presentation tier. The business delegate pattern is set up so that a client sends a request and establishes a connection with a business delegate object that utilizes a business service. The business service that the business delegated access to is created by the lookup service.

A staple in J2EE design patterns interview questions and answers, be prepared to answer this one using your hands-on experience.

Communication between items is demonstrated through behavioral patterns. The designer can concentrate on how objects communicate thanks to behavioral patterns. Examples of behavioral patterns include command, chain of responsibility, memento, template method, state, observer, interpreter, strategy, and visitor.

a.  Command: The objects include a function and all required input and output parameters. The objects that will initiate the action and the objects that perform the action are kept apart when various actions are carried out by triggering these items from the outside. The objects can be used in a variety of operations and can be kept in collections. When additional functionality is required, adding new command objects is also a simple process

b. Chain of Responsibility: A group of function classes and the command classes necessary to initialize those classes make up this design pattern. Function classes record the type of work they perform and choose the function class that will be the next in the array. When a process needs to perform a given number of functions sequentially, this design pattern might be employed. 

c. Memento: An object can maintain its state and then reset to the state it was in before the most recent action was taken thanks to this design pattern. In other words, it offers a mechanism to hide some of the object’s states and return to them when needed.

d. Template Method: In the hierarchy of classes, the template method is the top class. This top class reveals the model that subclasses should adhere to; the details are left up to the subclasses. This design technique prevents code redundancy in lower classes. In the higher class, the common codes of the lower classes are gathered in one location. This is done at some point when a change to this shared part is required.

e. State: If an object’s behavior changes as its state changes, the State design pattern may be employed. Using this design pattern removes the cumbersome “if/else” or “switch” statements from controlling the diverse behaviors of objects depending on their state if we have objects that respond differently in different circumstances.

f. Observer: When an object’s state changes and we wish to notify other objects of those changes, we utilize this design pattern. In other words, a large number of objects that are in the position of listeners continuously monitor an object’s state, and these observers are alerted when something changes.

g. Interpreter: This design pattern’s goal is to translate a specialized computer language. The main concept is to split each sign of this specialized language into its own class. In database management systems, this design pattern can be used to parse languages similar to SQL.

h. Strategy: The object decides which method to use when several are appropriate for a given task. The specifics of how the method should be used are isolated from the object that will use with the help of this design pattern. Additionally, the code is removed from the lengthy “if/else” or “switch” lines while utilizing this design pattern.

i. Visitor: This design pattern can be applied to a wide variety of objects. The items remain unchanged. Visitor objects carry out the action. This design pattern can be applied when the system does not introduce new objects but constantly requires the addition of new operations. The action-related codes are grouped into one main object

1. Intercepting filter pattern: Intercepting Filter applies a filter to both incoming requests and outgoing answers. These filters can be added and deleted declaratively, making it possible for them to be used in several combinations without being overtly noticeable. The final filter in the group vectors controls the initial target object after the preprocessing and/or postprocessing is finished. This is frequently a Front Controller for an incoming request, although it could also be a View.
2. Composite view pattern: Composite View refers to creating a View out of multiple atomic components. To build a single template, various smaller static and dynamic views are combined. A frequent fusion of other patterns from the catalog is shown by the Service to Worker and Dispatcher View patterns. The two patterns both have a controller that collaborates with a dispatcher, views, and helpers as part of their shared structure. Dispatcher View and Service-to-Worker have comparable participant responsibilities, but they differ in how those roles are split up. Dispatcher View, in contrast to Service to Worker, delays business processing until after view processing has been completed.  
3. Front controller pattern: The presentation tier’s common processing logic, which may otherwise be mistakenly placed in a View, is included in the Front Controller. A controller manages navigation, security, content retrieval, and view management while outsourcing dispatching to a View to a Dispatcher component.  
4. Application controller pattern: The processing of views and commands is centrally controlled, retrieved, and invoked by the application controller. The Application Controller Pattern is in charge of locating and calling commands, as well as locating and dispatching to views, whereas a Front Controller serves as a centralized access point and controller for receiving requests.
5. Context object pattern: Context Objects allow you to communicate state throughout your whole application in a manner that is protocol-independent. Testing is made simpler by using context objects, which allows for a more generic test environment with less reliance on a particular container.
6. View Helper Pattern: The separation of formatting-related code from other business logic is encouraged by View Helper. It advises encapsulating the functionality for starting content retrieval, performing validation, and modifying and formatting the model in Helper components. The presentation formatting is subsequently put into the View component. A View may be made up of several subcomponents to construct its template, in contrast to Helper components, which commonly delegate to the business services through a Business Delegate or an Application service.
7. Dispatcher view pattern: To manage client requests and create a dynamic display as the response, Dispatcher View integrates a controller, dispatcher, views, and helpers. Since content retrieval is a task that is delayed until after view processing, controllers do not assign it to helpers. A dispatcher, which can be contained within a controller, a view, or another component, is in charge of view management and navigation.
8. Service to worker pattern: Before control is sent to the view, the service to worker handles basic request handling and invokes business logic. Before handing control over to the view, it centralizes control and request handling to retrieve a presentation model. A dynamic response is produced by the view depending on the presentation model.

• Application service pattern: Application Services give a standard service layer to the business titer services by centralizing and aggregating behavior. Other services or business objects may interact with an application service. A layer of services can be added to your application by using an application service to call another application service.
• Business delegate pattern: Business delegate offers a point of entry for using remote services in the business layer and lessens connection across remote tiers. To enhance performance, a business delegate may also cache data as required. A Business Delegate maintains a one-to-one relationship with a Session Façade by encasing it. A Session Façade is triggered by an Application Service using a Business Delegate.
• Service locator pattern: The implementation strategies for locating business service components are encapsulated by Service Locator. A Service Locator is used by a Business Delegate to connect to a Session Façade. A service locator can be used by other clients who need to find and connect to Session Façade, other business-tier services, and web services.
• Session façade pattern: By masking the complexity of the interactions between business services, Session Façade offers coarse-grained services to the clients. Numerous Application Service implementations or Business Objects may be called by a Session Façade. A Value List Handler may also be contained within a Session Façade.
• Transfer object pattern: By reducing the number of calls necessary to obtain data from another tier, the Transfer Object Pattern offers the finest methods and approaches for exchanging data across tiers (i.e., across system boundaries) and so lowering network overhead.
• Business object pattern: The conceptual domain model is put into practice by Business Object using an object model. Business objects divide your application’s business data and logic into independent layers. Business objects often stand in for permanent items, and Domain Store enables transparent persistence.
• Value list handler pattern: The GoF iterator design is used by the Value List Handler to provide query execution and processing services. The Value List Handler stores the results of query execution in a cache and provides clients with requested subsets of the results. It is possible to avoid the costs involved with locating numerous entity beans by employing this strategy. The Value List Handler runs a query and retrieves the results from the persistent store using a Data Access Object. 
• Composite entity pattern: Using local entity beans and POJOs, Composite Entity implements a business object. A Composite Entity employs Data Access Objects to aid persistence when it is implemented using bean-managed persistence.  
• Transfer object assembler pattern: From several sources, the Transfer Object Assembler creates a composite Transfer Object. These sources could be Data Access Objects, EJB components, or any other Java object at random. The best time to apply this pattern is when the client needs to get data for the entire model or a specific component of the model.

• Service Activator Pattern: Corporate applications can use JMS to provide asynchronous processing thanks to Service Activator. An Application Service, Session Façade, or Business Objects can all be called by a Service Activator. To offer parallel asynchronous processing for lengthy operations, you can also use multiple Service Activators.
• Domain Store Pattern: A potent tool for implementing transparent persistence for your object model is provided by Domain Store Pattern. Data Access Objects are one of the many other patterns it mixes and connects.
• Web Service Broker Pattern: Using XML and common web protocols, Web Service Broker exposes and brokers one or more services from your application to external clients as a web service. Application Service and Session Façade can communicate with a Web Service Broker. A Web Service Broker processes a request asynchronously using one or more Service Activators.
• Data Access Object Pattern: Loose coupling between the resource and business levels is made possible by Data Access Objects. The whole data access logic required to create, access, remove, and update data from persistent storage is included in a data access object. Transfer Object is used by Data Access Object to send and receive data.

• MVC Pattern: A data model, presentation information, and control information must all be included in an application, according to the Model View Controller (MVC) design pattern. Each of them needs to be divided into separate items to follow the pattern.
• Business Delegate Pattern: The Business Delegate serves as a client-side business abstraction, hiding the actual implementation of the business services by providing an abstraction for them. It lessens the connectivity between the system’s Business services and presentation-tier customers.
• Composite Entity Pattern: EJB persistence technique uses the Composite Entity pattern. An EJB entity bean called a composite entity serves to represent a graph of an object. Internally dependent object beans are automatically updated when a composite entity is updated since they are handled by an EJB entity bean
• Data Access Object Pattern: Low-level data accessing APIs or operations are separated from high-level business services using the Data Access Object Pattern.
• Front Controller Pattern: According to the front controller design pattern, each request for a resource in an application will first be handled by one handler before being forwarded to the handler who is most suited to handle that particular sort of request. Other helpers may be employed by the front controller to complete the dispatching mechanism.
• Intercepting Filter Pattern: Having a straightforward system for adding and removing processing components, where each component completes a particular filtering function, is the key to tackling this challenge flexibly and unobtrusively.
• Service Locator Pattern: The service locator pattern is a design pattern used in software development to tightly abstract the steps necessary to access a service. This design makes use of a central register called the Service Locator, which, in response to a request, returns the data required to carry out a certain operation.
• Transfer Object Pattern: Transfer Object Pattern may include all of the data from a source or only a portion of the data. They can store information from a single source or several. When used, DTOs take over as the method for transferring data across systems.

• By implementing Action Interface: The action interface defines one no-argument method and five constants which are Success, None, Error, Input, and Login.  

public interface Action { 
public static final String SUCCESS = "success"; 
public static final String NONE = "none"; 
public static final String ERROR = "error"; 
public static final String INPUT = "input"; 
public static final String LOGIN = "login"; 
public String execute() throws Exception; 
} 

An example of the LOGIN action class: 

<!DOCTYPE struts PUBLIC 
"-//Apache Software Foundation//DTD Struts Configuration 2.0//EN" 
"http://struts.apache.org/dtds/struts-2.0.dtd"> 
 <struts> 
  <package name="user" extends="struts-default"> 
   <action name="Login" class="com.w3spoint.action.Login"> 
  <result name="success">/welcome.jsp</result> 
  <result name="error">/login.jsp</result> 
   </action> 
  </package> 
 </struts> 

Output:

Enter Username and Password:

Click on Login:

• Using Struts2 @Action annotation: The URL pattern for an Action class is defined by the @Action annotation in Struts2. The methods of an action class can each be retrieved using a different URL. The ability to hide the package name in the URL is provided by this feature. 

@Result(name="success",location="/user/user.jsp") 
public class UserAction extends ActionSupport{ 
private static final long serialVersionUID = 1L; 
@Action("/url/one") 
public String one() { 
    return SUCCESS; 
} 
} 

• Extending ActionSupport Class: A number of interfaces, including Action, Validatable, Serializable, and LocaleProvider, are implemented by the ActionSupport class. The action interface is less frequently utilized than the ActionSupport Class.

Any regular Java class that has an execute() method that returns a String can be set up as an action class. 

A staple in J2EE design patterns interview questions and answers, be prepared to answer this one using your hands-on experience.

An interface called externalization lets users create unique guidelines and their own serialization process. Serialization is a method for writing an object’s state into a byte stream. Java serialization isn’t particularly effective to serialize bloated objects that have numerous characteristics and properties, and in cases like these, externalization would be more effective.

For instance, it is possible to externalize the Serialization interface after implementing it in a class using the writeExternal() function. The readExternal() method will be used to generate an instance of the object when users reconstruct an externalized object on their end. Thus, serialization is made available through externalization, making it easy to control object steam and choose what to store there.

In a scenario where only a portion of an object needs to be serialized, externalization is very helpful as only the object’s required fields would be serialized.

There are four development roles in the J2EE Application:

• Presentation Content Developer: Today, one of the issues with most internet application development efforts is that the focus is too much on creating the business logic itself and not enough on creating an appealing and aesthetically pleasing user interface. The outcome is a refusal to utilize the program or just switching to another approach to get the same outcome. These quick yet unsatisfactory contacts can have a long-lasting impact on an organization’s productivity and effectiveness.

Organizations are starting to understand that an application’s actual usability – including its ergonomics and GUI aesthetics – is a crucial component of its success. The majority of Java developers should be able to fully educate themselves in order to give any development value as the intricacy of Web GUI development and the quality of GUI interface needed by business application customers both reach new heights.

To design and implement the J2EE application interface, organizations must work with experts in the fields of art, ergonomics, mass communication, and creative content.

• Web Component Developer: A J2EE compliant web server’s architecture requires that a Web Component Developer create the presentation logic necessary to support a web-based J2EE client interface. A web component developer should ideally have experience creating JavaServer Pages, Servlets, Web-based applets, and other Web-related technologies like HTML and XML
• Business Component Developer: The ability to translate business needs into business logic, which is implemented on the J2EE platform as Enterprise JavaBeans, is the key competency required of business component developers. They should have technical knowledge of the J2EE platform architecture and how it can connect with the EIS tier, as well as knowledge of the business domain they are building for. 
• EIS Integrators: Occasionally, a J2EE project needs to integrate heavily with numerous EIS layer systems that are not Java-based, or perhaps the technologies are more proprietary in nature. In such cases, the design, development, and implementation of the communication pipeline between the J2EE platform and the particular enterprise information system will require the involvement of an EIS integration specialist.

J2EE 1.4 is an enhanced version of J2EE 1.3. It is the most complete web services platform ever.  

J2EE 1.4 includes: 

1. Java API for XML-Based RPC (JAX_RPC 1.1) 
2. SOAP with Attachments API for Java (SAAJ) 
3. Web services for J2EE (JSR 921) 
4. J2EE Management Model (1.0) 
5. J2EE Deployment API (1.1) 
6. Java Management Extensions (JMX) 
7. Java Authorization Contract for Containers (JavaACC) 
8. Java API for XML Registries (JAXR) 
9. Servlet 2.4 
10. JSP 2.0 
11. EJB 2.1 
12. JMS 1.1  
13. J2EE Connector 1.5  

The new JAX-RPC 1.1 API, which allows service endpoints based on Servlets and enterprise beans, is a feature of the J2EE 1.4 that offers whole support for web services. Interoperability with Web services built on the WSDL and SOAP protocols is offered by JAX-RPC 1.1.  

The web services for the J2EE standard (JSR 921), which specifies Web service deployment criteria and makes use of the JAX-RPC programming style, is also supported by the J2EE 1.4 platform. The WS-I Basic Profile 1.0 is supported by the J2EE 1.4 platform in addition to a large number of web service APIs. This indicates that J2EE 1.4 enables platform Web services interoperability in addition to platform freedom and full Web services capability.  

The J2EE Management 1.0 API, which provides the information model for J2EE management and includes the common Management EJB (MEJB), is also introduced by the J2EE 1.4 platform. The Java Management Extensions API (JMX) is utilized by the J2EE Management 1.0 API. The J2EE Deployment 1.1 API, which offers a standard API for deploying J2EE applications, is another addition to the J2EE 1.4 platform. 

The Java Authorization Contract for Containers (JavaACC) was added to part of the J2EE 1.4 platform to improve security. By establishing a uniform method for integrating authentication systems into J2EE containers, the JavaACC API enhances security.  

Thanks to improvements made to the Java Servlet and JavaServer Pages (JSP) technologies, the J2EE platform now makes it simpler to design web front ends. Request listeners and improved filters are now supported by servlets.  

With the advent of a basic expression language, tag files, and a more straightforward tag extension API, among other things, JSP technology has simplified the page and extension development models. This makes it simpler than ever for developers, especially those who are comfortable with scripting languages, to create JSP-enabled pages. 

The web client is a crucial component, and it also has the following two components that describe how it works: 

1. Dynamic portion: This provides dynamic web pages utilizing a variety of markup languages, including HTML, XML, and others. This portion is produced by the web components that are active in the web tier. The pages can only be rendered by a web browser. 
2. Static portion: This delivers static pages to the client from the server that don’t change in response to requests. It provides information that is static and always static, such as support information or information about us. 

The web client is referred to as a “thin client,” which is a very basic web-based client that doesn’t do any queries, business rule execution, or application connection. It offers efficient operations and gives the server’s applications protection, speed, and a variety of services.

The applet is a type of application client that runs on the client side and gives the user a way to manage the task that enables them to use the interface. A graphic user interface is offered, and assistance tools are available. Swing and the advanced window toolkit are used in the command line interface to build the graphical user interface.

The applets were created in Java. This is installed on the web browser and executed on the virtual machine that Java uses. The plug-in is necessary for the client system’s use of security policy, which correctly executes the program in the web browser. The components build web client programs and execute the application on the client side using API keys. The files are not required on the client system because no security is permitted. It offers an application design utilizing applets that is more modular.

The Servlet and JavaBeans component architecture is used by the application client to communicate over the HTTP connection. The application client also comprises a number of components to control the overall data flow for the server and the client’s communication needs.

This, along with other interview questions on J2EE for freshers, is a regular feature in J2EE interviews, be ready to tackle it with the approach mentioned below.

An application client is a program that runs on the client side and gives the user a way to manage the task that enables them to use the interface. A graphical user interface is offered, and assistance tools are available. Swing and the advanced window toolkit are used in the command line interface to build the graphical user interface. 

Due to the application being managed at the business tier, these clients can use them immediately. The servlet and JavaBeans component architecture is used by the application client to communicate over the HTTP connection. The application client also comprises a number of components to control the overall data flow for the server and the client’s communication needs. 

Instance variables can be used with an object by using JavaBeans components. Instance variables are used on the server side to obtain data from the user and set it on the server using get and set methods. It offers a wide range of options and components that can be used for the client tier. The business logic that the server provides to execute the applications is how the client and server communicate.  
 
By browsing the pages that are being created and transferring data from the web layer, the web browser is used to communicate through the server. The J2EE application employs a thin client or thick client that offers the client both light and heavy capabilities while minimizing server load.

A component and the low-level, platform-specific functionality that enables it are connected through containers. A web component, enterprise bean, or application client component must be put together into a J2EE module and deployed into its container before it can be performed.  
 
The J2EE application itself, as well as each component, must have container settings specified as part of the assembly process. The J2EE server’s foundational support, including features like security, transaction management, Java Naming and Directory Interface Trademarked (JNDI) lookups, and remote connectivity, can be tailored using container settings. Some of the highlights are as follows:  

Only authorized users are able to access system resources when a web component or enterprise bean is configured using the J2EE security paradigm. 

To ensure that every method in a transaction is regarded as a separate unit, the J2EE transaction model allows you to declare relationships between the methods that make up a single transaction.  
For application components to access naming and directory services, JNDI lookup services offer a uniform interface to several name and directory services throughout the company.

Enterprise beans and clients’ low-level communications are handled via the J2EE remote connectivity concept. A client can call methods on an enterprise bean after it has been built as though it were located in the same virtual machine.

Due to the flexible services offered by the J2EE architecture, application components inside a single J2EE application can act differently depending on where they are deployed. For instance, an enterprise bean may have security settings that permit it to access database information at one level in a production environment and at a different level in a different production environment.

The container also controls access to the J2EE platform APIs as well as non-configurable services such as database connection resource pooling, data persistence, enterprise bean and servlet life cycles, and access to the J2EE platform APIs.

Although data persistence is a non-configurable service, the J2EE architecture allows you to override container-managed persistence by incorporating the necessary code in your enterprise bean implementation when you need more control than the default container-managed persistence. 

The Enterprise Bean Developer platform utilizes numerous services for various components, and it is always necessary to specify the task, such as:  

The JAR file, utilized by Java itself, is a crucial file that contains all the archived files. It is utilized for the subsequent tasks: 

• The source code needs to be correctly written and compiled. 
• The program that needs to start is specified using the deployment descriptor. 
• A bundle is created by combining class files with the .class file extension so that it may be utilized as a single file. The descriptor must be present in the JAR file for it to work.  

The J2EE API enables the integration of the offered components by the system and applications. It makes this possible in the following ways and manners:

1. All levels of the enterprise bean incorporate the application used using the API. The unified application model is utilized in this.
2. The request and response are presented in a more straightforward way by the J2EE API. This method makes it possible for the JSP page and servlet to be easily represented so that they may be implemented on the server.
3. It adheres to the JAAS-based reliable security model and makes it possible to employ the security mechanism across the board for all application models.
4. It enables simple API integration utilizing JAXP, an XML-based data transfer architecture that has been created to give the new attributes and manage them from a single location.
5. It employs the J2EE connection architecture in a more straightforward way and offers compatibility between the connector.
6. Using the JDBC APIs, enables database connectivity across numerous database systems.