JPA Inheritance - Non Entity Super Class

An entity can inherit of a non-entity super class. The consequence is that the non-entity class data is not persisted.

For example:

@AutoProperty
public class NonEntitySuperClass {

 private String s;

    // Setter, Getters, Constructors, Pojomatic...

}

A class extends this non-entity class:

@Entity
@AutoProperty
public class InheritingNonEntitySuperClass
    extends NonEntitySuperClass
        implements Serializable {
 

    @Id
    @GeneratedValue(strategy=GenerationType.AUTO)
    private long id;
 
    private String s2;

    // Setter, Getters, Constructors...

}

The following code:

JPA.INSTANCE.clear();

InheritingNonEntitySuperClass insc
    = new InheritingNonEntitySuperClass();
insc.setS("P1P");
insc.setS2("AZ3");
  
JPA.INSTANCE.save(insc);
JPA.INSTANCE.clear();
  
InheritingNonEntitySuperClass retr = JPA.INSTANCE.get(
    InheritingNonEntitySuperClass.class, insc.getId());

System.out.println("Source == Retrieved: " + (insc==retr));
System.out.println(retr);

Generates the following output:

Source == Retrieved: false
InheritingNonEntitySuperClass{s: {null}, id: {1}, s2: {AZ3}}

Notice that the s value is null, instead of P1P.

The above example is available from Github in the JPA directory. It relies on Pojomatic too. Some errors messages will be displayed because of a known and harmless issue.

JPA Inheritance - Abstract Entity

An abstract class can be made a JPA entity. The only difference is that such classes cannot be instantiated.

For example:

@Entity
@AutoProperty
public abstract class AbstractEntity implements Serializable {

    @Id
    @GeneratedValue(strategy=GenerationType.AUTO)
    private long id;

    private String s;

    // Setter, Getters, Constructors, Pojomatic...

}

A class extends the abstract class:

@Entity
@AutoProperty
public class ConcreteEntity extends AbstractEntity {

    private String s2;

    // Setter, Getters, Constructors...

}

The following code:

JPA.INSTANCE.clear();

ConcreteEntity ce = new ConcreteEntity();
ce.setS("AAA");
ce.setS2("BBB");

JPA.INSTANCE.save(ce);
JPA.INSTANCE.clear();

ConcreteEntity retr = JPA.INSTANCE.get(
    ConcreteEntity.class, ce.getId());

System.out.println("Source == Retrieved: " + (ce==retr));
System.out.println(retr);

Generates the following output:

Source == Retrieved: false
ConcreteEntity{id: {1}, s: {AAA}, s2: {BBB}}

The above example is available from Github in the JPA directory. It relies on Pojomatic too. Some errors messages will be displayed because of a known and harmless issue.

Java Abstract Class vs Interface Pros and Con's

This a quick reminder about pros and con's of Java abstract classes and interfaces:

Interface

• A class can implement multiple interfaces
• An interface cannot provide any code at all
• An interface can only define public static final constants
• An interface cannot define instance variables
• Adding a new method has ripple effects on implementing classes (design maintenance)
• JAXB cannot deal with interfaces
• An interface cannot extends or implement an abstract class
• All interface methods are public

In general, interfaces should be used to define contracts (what is to be achieved, not how to achieve it).

Abstract Class

• A class can extend at most one abstract class
• An abstract class can contain code
• An abstract class can define both static and instance constants (final)
• An abstract class can define instance variables
• Modification of existing abstract class code has ripple effects on extending classes (implementation maintenance)
• Adding a new method to an abstract class has no ripple effect on extending classes
• An abstract class can implement an interface
• Abstract classes can implement private and protected methods

Abstract classes should be used for (partial) implementation. They can be a mean to restrain the way API contracts should be implemented.