Method overloading is a feature that allows a programmer to implement polymorphism in Java. In method overloading, the name of the methods are same, but they differ in number or type of parameters passed to them.

When an overloaded method is invoked, java examines the number or type of parameters passed to the method and matches it with actual arguments to decide which method is to be called.

The example below describes an overloaded method named show():

1. int show(int i) {}
2. void show(String str) {}

Here, method name is the same, but the method at (1) has an int parameter, and the method at (2) has a String parameter.

Note: A parameter is the list of variables passed in a method declaration and arguments are the actual values passed to these parameters when the method is called. Arguments must match with the parameters type and order.

The this keyword refers to the currently executing instance of a class. It is commonly used to access members from within constructors, instance methods, and instance accessors. However, the static member functions do not have a this pointer. For example:

using System;
public class Students
{
public string name;
public string subcode;
//Constructor.
public Students(string name, string subcode)
{
//Use of this keyword to qualify members hidden by similar names.
this.name = name;
this.subcode = subcode;
}
}

The this keyword is used to pass an object as a parameter to other methods. For example:

Cal_Marks(this);

Java allows a method to take a variable number of arguments. This capability is referred to as var-args, varargs variable arguments, variable-length argument lists, or variable-arity parameter.

The syntax for using variable argument lists is as follows:

void fun(int… z){}

The declaration of the varargs follows the type with an ellipse (…) and then name of the array.

Limit: A method can have only one varargs, and it must be the last parameter in the method signature. An example of a varargs declaration is as follows:

void fun(int x, char… y)

Numeric promotions are used to convert the operands in a numeric expression to a common type before an operation is performed between the operands. Numeric promotion is a property of the specific definitions of the built-in operations and not a Java language feature. It is applied to the operands of an arithmetic operator. The two types of numeric promotions are as follows:

1. Unary numeric promotion: The unary numeric promotion takes place in accordance with the following rules:
   1. If the operand is one of the following types: byte, short, or char, unary numeric promotion promotes it to a value of type int.
   2. Otherwise, no promotion takes place.
2. Binary numeric promotion: The binary numeric promotion takes place in accordance with the following rules:
   1. If one of the two operands in a numeric expression is a primitive type double value, the other is promoted to a double value.
   2. Otherwise, if one of the two operands in a numeric expression is a primitive type float value, the other is promoted to a float value.
   3. Otherwise, if one of the two operands in a numeric expression is a primitive type long value, the other is promoted to a long value.
   4. Otherwise, both operands are promoted to int values.

An interface is a reference type that defines a contract. An interface body consists of method declarations and constants. All methods and constants in an interface are public. Interfaces are left completely unimplemented, i.e., no method in the interface is implemented. All methods of an interface are abstract and the method body is absent. A class may access one or more interfaces simultaneously. An interface is defined using the syntax below:

access_modifier interface interface_name extends Super_interfaces{
return_type method1(parameter_list);
.
.
.
return_type methodn(parameter_list);
datatype variable1 = value;
.
.
.
datatype variablen = value;
}

The syntax defined above has two components: the interface declaration and the body of the interface. They are discussed in the following sections:

An interface declaration

An interface declaration consists of the following components:

• access_modifier: An interface can be declared by using the public access modifier or without any access modifier. When an interface is declared as public, it can be accessed by any class in any package. If no access modifier is used in the declaration, the interface is accessible only within the package in which it is declared.
• interface interface_name: The keyword interface in the declaration tells the compiler that it is an interface declaration, and name of the interface is the one that follows the interface keyword. The name of an interface must be a valid identifier.
• extends Super_interfaces: An interface can extend other interfaces in the same way as a class extends another class. The only difference between these two is that whereas a class is allowed to extend only one class, an interface can extend any number of interfaces. The extends keyword in an interface declaration tells the compiler that the interface extends the list of interfaces that follows the extends keyword.

The interface body

The interface body contains method declarations for all the methods included in the interface. A method declared within an interface does not have a body, i.e., the method declaration ends with a semicolon. This is because an interface does not provide implementations for the methods declared within it. Apart from method declarations, an interface contains constant declarations.

All the constants defined in an interface are by default static and final. Therefore, there is no need to explicitly use these keywords to declare variables inside the interface body. All methods and variables in an interface are implicitly public if the interface is declared as public. It is also not necessary to declare the methods as abstract as well. The following example demonstrates how to define an interface:

public interface MyInterface{
void method1();
int method2(int k);
int x = 1;
int y = 2;
}

The following table summarizes the differences between method overriding and method overloading:

According to method overriding, an overriding method must follow the following rules:

• It must have the same argument list.
• It must have the same return type, new to Java 5. The return type can be a subclass – this is known as covariant return.
• It must not have a more restrictive access modifier.
• It may have a less restrictive access modifier.
• It must not throw new or broader checked exceptions.
• It may throw fewer or narrower checked exceptions, or any unchecked exception.

JavaBean is a reusable software component that can be visually manipulated using the builder tool. The following are the JavaBean Listener naming rules:

• Listener method names that are used to register a listener with an event source must use the prefix add followed by the listener type.
• Listener method names that are used to remove a listener must use the prefix remove followed by the listener type.
• The type of listener to be added or removed must be passed as the argument to the method.
• Listener method names must end with the word “Listener”.

JavaBean is a reusable software component that can be visually manipulated using the builder tool. The JavaBean property naming rules are as follows:

• Setter method signatures must be marked public, with a void return type and an argument that represents the property type.
• Getter method signatures must be marked public, take no arguments, and have a return type that matches the argument type of the setter method for that property.

The getHandle() method is used to obtain a serializable handle to the timer. The handle belongs to the TimerHandle interface and can be used later to re-obtain the timer reference. The general form of this method is as follows:

public TimerHandle getHandle() throws java.lang.IllegalStateException, NoSuchObjectLocalException, EJBException

This method returns a serializable handle to the timer. It will throw the java.lang.IllegalStateException if this method is invoked while the instance is in a state that does not allow access to this method. It will throw the NoSuchObjectLocalException if invoked on a timer that has expired or cancelled. It will throw the EJBException if this method could not complete due to a system-level failure.

The Web service endpoint interface is used to define the ‘Web services methods’. It is necessary for an enterprise bean that implements the Web service to implement methods having the same signature, as the methods of the Web service endpoint interface. There are a numbers of restrictions exist on which types to use as parameters and results of service endpoint interface methods. It provides the client’s view of the Web service, hiding the stateless session bean from the client. A Web service endpoint interface must conform to the rules of a JAX-RPC service definition interface. A Web service endpoint interface must conform to the following rules:
It should extend the java.rmi.Remote interface.
It must not have constant declarations, such as public, final, or static.
The methods must throw the java.rmi.RemoteException or one of its subclasses. Method parameters and return types must be supported JAX-RPC types.
For example:

package bookaccount;
import java.rmi.RemoteException;
import java.rmi.Remote;

public interface BookAccount extends Remote {

public String sayBook(String name) throws RemoteException;
}

Here, BookAccount is the Web service endpoint interface and the class that implements this interface must implement the sayBook() method defined by the BookAccount interface. The interface decouples the implementation class from the type of client access. For example, if a remote and home interface is added to a class named BookAccountBean, the methods of the BookAccountBean class could also be accessed by remote clients.

A remote client is a location independent client of an enterprise bean. A client that runs in the same JVM as a bean instance uses the same API to access the bean as a client that runs in a different JVM on the same or different machine. The remote client uses a remote interface that specifies the remote business methods that a client can call on an enterprise bean. It also uses a remote home interface that specifies the methods used by remote clients for locating, creating, and removing instances of enterprise bean classes. The following are the characteristics of a remote client:
It is allowed to run on a different machine and a different Java virtual machine (JVM) than the enterprise bean it accesses.

It can be used as a web component, an application client, or another enterprise bean.

The location of the enterprise bean is transparent to the remote client.

Local accessibility is the default accessibility of an enterprise bean. If the bean’s business interface is not decorated with @Local or @Remote, and the bean class does not specify the interface using @Local or @Remote, the business interface is by default a local interface. An enterprise bean that allows only local access can be created in any of the following two ways:

By annotating the business interface of the enterprise bean as a @Local interface:

@Local
public interface InterfaceName { … }

By decorating the bean class with @Local and specifying the interface name.

@Local(InterfaceName.class)
public class BeanName implements InterfaceName { … }

Remote access allows an enterprise bean to run on a different machine with a different Java virtual machine (JVM). An enterprise bean that allows remote access can be created in any of the following ways:
By decorating the business interface of the enterprise bean with the @Remote annotation:

@Remote
public interface InterfaceName { … }

By decorating the bean class with @Remote, and specifying the business interface or interfaces:

@Remote(InterfaceName.class)
public class BeanName implements InterfaceName { … }

Following are the characteristics of a message-driven bean:
It executes upon receipt of a single client message.
It is invoked asynchronously.
It is relatively short-lived.
It does not represent directly shared data in the database, but it can access and update this data.
It can be transaction-aware.
It is stateless.
Client components invoke methods directly and they do not locate message-driven beans.
It allows JMS messages to be sent asynchronously.
A message can be delivered to a message-driven bean within a transaction context.
The instance variables of the message-driven bean instance can contain some state across the handling of client messages.

A Web container
B EJB container
C Application client container
D Applet container
E Java EE server

begin(): This method is used to start a new transaction. The general form of the method is as follows:

void begin()

This method will throw an IllegalStateException if it is called on an active transaction.

commit(): This method is used to commit a transaction and write any unflushed data to a database. The following is the general form of the commit() method:

void commit()

This method will throw a RollbackException if the commit operation fails due to some reason. This method will throw an IllegalStateException if called on a non-active transaction.

The getTransaction() method is used to get the instance of the EntityTransaction interface. The following is the general form of the method:

EntityTransaction getTransaction()

This method returns an EntityTransaction instance. This instance may be used serially to begin and commit multiple transactions. This method will throw an IllegalStateException if invoked on a JTA EntityManager.

The isActive() method is used to indicate whether a transaction is in progress. This method is used by the begin(), commit(), rollback(), setRollbackOnly(), and getRollbackOnly() methods to perform execution. The following is the general syntax of the method:

boolean isActive()

This method will throw the PersistenceException if an unexpected error condition is encountered.

Persistence unit packaging specifies that a persistent unit can be packaged as part of a WAR or EJB JAR file, or can be packaged as a JAR file that can then be included in a WAR or EAR file. The rules for packaging a persistent unit are given below:

1. If a persistent unit is packaged as a set of classes in an EJB JAR file, persistence.xml should be put in the EJB JAR’s META-INF directory.
2. If a persistence unit is packaged as a set of classes in a WAR file, persistence.xml should be located in the WAR file’s WEB-INF/classes/META-INF directory.
3. If a persistence unit is packaged in a JAR file that will be included in a WAR or EAR file, the JAR file should be located at the following locations:
   1. In the WEB-INF/lib directory of a WAR
   2. In the top-level of an EAR file
   3. In the EAR file’s library directory

The persistence.xml file contains the configuration information of one or several persistent units. This file must be present inside the META-INF directory of the ejb deployment. The persistence.xml file has as the root element of the file. This element has two attributes, namely name and transaction-type. The name attribute is mandatory and defines the name of the persistence unit. The transaction-type attribute is optional and specifies whether Java EE transactions (JTA) or the resource local (RESOURCE_LOCAL) transaction will be used. The default transaction type is JTA. The element has the following optional sub-elements:

The EntityManager interface contains methods to interact with the persistence context. The life of an entity instance is managed inside the persistence context. An entity manager uses the interface to create, manage and remove the entity instance. This interface has methods to find entities using their primary keys, to find whether or not an EntityManager is open, and to make an entity instance managed and persistent.