Enum serves as a type of fixed number(meaing limited to certain number) of constants and can be used at least for two things:


public enum Month {


This is much better than creating a bunch of integer constants.

creating a singleton

public enum Singleton {

   // init



Choosing and developing a Session Bean

Use a session bean if:

  1. Only one client has access to bean at any given time
  2. State of bean is not persistent
  3. Bean represent a web service

Use a Stateful Session bean if:

  1. Bean state represent client interaction
  2. Bean needs to hold client data across interactions
  3. Bean acts as a client mediator to other beans
  4. Need thread-safe interactions

Session Bean cardinality(taken from DevelopIntelligence)

bean cardinality.PNG

From the diagram, you can see that Stateless and Singleton beans looks very similar when it comes to Client-bean instances, except that in singleton all the clients access single object while in Stateless some objects are uses by clients and returned back to pool.

Developing a Session Bean

Steps to create a session bean:

  1. Define business logic interface
  2. Annotate the business interface
  3. Create the session bean, implementing the interface
  4. Annotate class defining type
  5. Compile, deploy and debug as discussed above

Dependency injection in EJB

After an EJB is instantiated inside the Java EE container, but before it is handed out to a client, the container may initialize property data on the instance according to rules defined for that enterprise bean. This feature is called dependency injection, an external provider initializes the properties of an object instance instead of by the class itself.

■Note Injection uses a “push” model to push data out to the bean, and it occurs regardless of whether the bean actually uses the data. If there is a chance that the data will not be used, the bean may elect to avoid incurring the cost of the resource derivation by performing a Java Naming and Directory Interface (JNDI) lookup in Java code to “pull” the
data, only if it is actually (or likely to be) used.

Common examples of dependency injection use in EJB are as follows:
• Injecting an EntityManager into a session bean for interacting with entities in a persistence unit
• Injecting a UserTransaction into a session bean that manages its transaction demarcation

Even though, the video below is for Spring framework, which is actually EJB’s alternative, it covers the Dependency Injection(DI) pretty well.

XML and Annotations in EJB

XML vs Annotations

A simple rule we follow is this: if we need to decouple our entity and bean classes from their EJB metadata, as when we want to use the same entity classes with two different entity inheritance strategies, we put our metadata in XML.

Otherwise, we stick with annotations. Don’t forget—you can always mix and match, relying on the firm policy that whenever metadata is specified for an element using both XML and annotations, the XML always wins. This allows any role (see the “EJB Roles” section later in the chapter) downstream of the bean developer to override metadata settings without having to update the Java source, since overrides can be applied exclusively to the XML descriptors.


uses ejb-jar.xml or server specific file.


more annotations is better


A more advanced strategy, which is also recommended, is to use annotations only when defining behavior of an enterprise bean or an entity that is truly integral to its definition, such as the relationship type of an entity relationship field, or the transactional requirements of a method on a session bean. Anything that could reasonably be overridden, such as the name of the table to which an entity maps, or the details of a value generator used for populating the primary key on an entity, would go in the XML descriptor, where it can be specified at deploy time by an application assembler, perhaps in consultation with a database administrator. While there is no harm in specifying default values using annotations in the Java source file, this approach recognizes the difference between firm metadata, which ought not to be modified, and loose metadata that may be freely modified without changing the behavior of the enterprise bean or entity.

Good naming in programming

It should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent.

steps for good naming

  1. write the method
  2. rename the attributes to meaningful names
  3. be careful with names that are different only a little bit ex.: XYZabcdStorageHandling and XYZabcdLocationHandling
  4. no l or 0 letters in variable names since they look like digit 1 and 0
  5. Noise words are redundant. The word variable should never appear in a variable
    name. The word table should never appear in a table name. How is NameString better than Name? Would a Name ever be a floating point number? If so, it breaks an earlier rule about disinformation. Imagine finding one class named Customer and another named CustomerObject. What should you understand as the distinction? Which one will represent the best path to a customer’s payment history?
  6. WRONG!
    1. getActiveAccount();
    2. getActiveAccounts();
    3. getActiveAccountInfo();
    1. Class Names
      Classes and objects should have noun or noun phrase names like Customer, WikiPage, Account, and AddressParser. Avoid words like Manager, Processor, Data, or Info in the name of a class. A class name should not be a verb.
    2. Method Names
      Methods should have verb or verb phrase names like postPayment, deletePage, or save. Accessors, mutators, and predicates should be named for their value and prefixed with get,set, and is according to the javabean standard.
      string name = employee.getName();
      if (paycheck.isPosted())
  7. However one might decide to use the word add for “consistency” when he or she is not in fact adding in the same sense. Let’s say we have many classes where add will create a new value by adding or concatenating two existing values. Now let’s say we are writing a new class that has a method that puts its single parameter into a collection. Should we call this method add? It might seem consistent because we have so many other add methods, but in this case, the semantics are different, so we should use a name like insert or append instead. To call the new method add would be a pun. Using the same term for two different ideas is essentially a pun.