My JPA 2.0 Wish List

Until now we have enjoyed easy persistence using JPA 1.0. It's true that JPA 1.0 has some limitations, but now our friends from JSR-317 are working hard to give us a better standard persistence for Java.

I'm part of OpenXava project team, OpenXava produces a full application using as source only Java classes annotated with JPA, so the JPA 2.0 specification is very important for OpenXava. But, JPA 2.0 specification is also very important for all Java developers, because the expressivity of our model will be directly proportional to the expressivity of the new JPA 2.0.

The JPA 2.0 has a lot of new great features, and some of them like me a lot. You can see it by download the draft of the specification from JCP, or by reading the two (part I and part II) articles of Mike Keith here, in JavaLobby.
But this article is for talking about the missing features of JPA 2.0. I'm going to say you my wish list for JPA 2.0. Please, if some of the features like you, send your comment to jsr-317-comments@jcp.org. Maybe, we can influence in the new JPA 2.0.

This is my wish list for JPA 2.0:

1. Restriction in callback methods.
2. @ManyToOne, @OneToMany and @ElementCollection implicits.
3. Converters.
4. Method in EntityManagerFactory for obtaining the list of all entities.
5. Composite keys without key class.
6. UUID as GeneratedType for @GeneratedValue.
7. Default fetch value for @ManyToOne.
8. @ElementCollection.
9. Qualified properties in @OrderBy.

1. Restriction in callback methods

I'm waiting for JPA 2.0 only for seeing the next paragraph from 3.5 Entity Listeners and Callback Methods removed from the specification:

In general, the lifecycle method of a portable application should not invoke EntityManager
or Query operations, access other entity instances, or modify relationships within the same persistence context.

But, it still remains there. Horror!

Each time my developers need to use callback methods is for querying or saving data. And they need to use JPA to do it. And just it is forbidden. The conclusion after a time working with JPA is that callback methods are simply useless.

That is, these scenarios are typical:

• In order to remove some entity I need to verify if some data exists, and we want do it using a JPA query.
• When a entity is saved, some other entities must be automatically created and saved, and we want to use JPA query to do so.

Why not remove this restriction from @PrePersist or @PreRemove at least?
Or, we can create other annotations (executed always before the flush) where we can use Query and EntityManager.

2. @ManyToOne, @OneToMany and @ElementCollection implicits

This another suggestion is that @ManyToOne, @OneToMany and @ElementCollection can be implicit, just as @Basic annotation already is in JPA 1.0.
That is, instead of writting:

@Entity

public class Invoice {

    ...

    

    @ManyToOne

    private Customer customer;

    @OneToMany (mappedBy="invoice")

    private Collection<Delivery> deliveries;

} 

We can write the next code:

@Entity

public class Invoice {

    ...

    

    private Customer customer;

    private Collection<Delivery> deliveries;

}

And JPA will assume a @ManyToOne for customer and a @OneToMany for deliveries.
This approach has at least two advantage:

1. Easy migration from non-JPA code to JPA.
2. Less code to write in the hand of the programmer.

3. Converters

In my world it's usual to develop Java applications against legate database, designed in many case by RPG or COBOL programmer. When types of the data are not suitable for good Java model classes. For example, some databases uses 3 numeric values for a data, or a VARCHAR with arbitrary values that can be mapped to a boolean. A standard type converter mechanism is needed for this so common scenarios.
Custom value type of Hibernate or Converters of OpenXava 2 (for single value, for multiples values) are two valid options.

Another useful feature is the possibility of declaring conversion policies by default. Look the default converters of OpenXava.

4. Method in EntityManagerFactory for obtaining the list of all entities

In OpenXava project we need the next code:

private static Collection obtainManagedClassNamesUsingHibernate() {
    // The next code is Hibernate dependent.
    // This code has to be modified in order to work with Glassfish, OpenJPA, etc.       
    EntityManager manager = XPersistence.createManager();
    org.hibernate.impl.SessionImpl impl = (org.hibernate.impl.SessionImpl) manager.getDelegate();
    Collection result = impl.getSessionFactory().getAllClassMetadata().keySet();
    manager.close();
    return result;
}

As you can see, this code is ugly and dependent on Hibernate implementation
OpenXava is a framework for creating business application from POJOs annotated with JPA, in order to work it needs to know, at least, the list of the entities managed by JPA.
To have a standard way to do it would be nice. Maybe a method in EntityManagerFactory.
Moreover, obtaining the metadata without connecting to database will be really great.

5. Composite keys without key class

the idea is that we can define an entity with composite key in this simple way:

@Entity

public class Invoice {

    @Id 

    private int year;

    

    @Id 

    private int number;

    ...

}

Map key = new Map();
key.put("year", 2008);
key.put("number", 3);
Invoice invoice = manager.find(Invoice.class, key);

Invoice invoice = manager.find(Invoice.class, new Object[] { 2008, 3} );

3. Varargs

Invoice invoice = manager.find(Invoice.class, 2008, 3);

4. Refresh

Invoice invoice = new Invoice();
invoice.setYear(2008);
invoice.setNumber(3);
manager.refresh(invoice);

My favourite is the 4.

6. UUID as GeneratedType for @GeneratedValue

Why is not included UUID as GeneratedType for @GeneratedValue ?

Hibernate JPA includes it.
In my organization we develop applications that need to work on AS/400, Informix, Postgres, MS SQL and MySQL. Using UUID for generating id is very useful for us, because is very easy migrating from a database product to another.
I wonder it is not included in JPA.

7. Default fetch value for @ManyToOne

This proposal for JPA 2.0 is about to change the default value of ManyToOne(fetch ), or even better the possibility to declare it in the orm.xml, or persistence.xml files.

The next paragraph:

The recommanded approach is to use LAZY onn all static fetching definitions and override this choice dynamically through JPA-QL. JPA-QL has a fetch keyword that allows you to override laziness when doing a particular query. This is very useful to improve performance and is decided on a use case to use case basis.

8. @ElementCollection

Adding embedded collections to JPA 2.0 are very, very good idea.
Until now we have to use collection to entities as alternative.
But the annotation to mark it is really ugly:

@ElementCollection 
protected Set<String> nickNames = new HashSet(); 

It's ugly.
Why not:

@ManyToOne @Embedded
protected Set<String> nickNames = new HashSet(); 

Or still better:

@Embedded
protected Set<String> nickNames = new HashSet(); 

9. Qualified properties in @OrderBy

Qualified properties in OrderBy are needed sometimes.
I want to write something as this:

@OneToMany (mappedBy="invoice", cascade=CascadeType.REMOVE)
@OrderBy("product.description desc")
private Collection<InvoiceDetail> details;

Where InvoiceDetail has a product reference:

@Entity
public class InvoiceDetail {

    @ManyToOne(fetch=FetchType.LAZY, optional=false)
    private Product product;

    ...

}

In fact, OpenXava adds this support with its own XOrderBy annotation just for supporting qualified properties.

Conclusion

What do you think about these suggestion ?

If you like some of them please send your comment to JSR: jsr-317-comments@jcp.org

References

• JSR-317: Java Persistence API:
• OpenXava: Model-driven framework based on JPA.