Limitations and Objections


JDK5 Only

Ebean is currently only available for JDK5+. It would be nice to port back to JDK1.4 when time permits.

No EJB QL Support

There is no current support for EJB QL Query Language and its not an immediate priority.

Part of the reason for this is that personally I think many report orientated queries are better expressed in SQL and returned as Lists of Maps rather than artifically being forced into Objects.

A full discussion of why there is no EJB QL is covered here.

Only Single Table Inheritance

Current there is only support for single table inheritance. The other two inheritance strategies are considered Enhancement requests and will be introduced in a feature release.

Performance of Reflection

People may be worried about the potential for a large amount of Reflection being used and its performance cost.

The use of reflection has been replaced with code generation (via ASM). So the performance cost of using beans and getters and setters etc is pretty good. I would not expect this to be a noticable issue for people relative to JDBC/database costs.

For people investigating the raw performance cost of ORM queries versus direct JDBC with 'flat' objects I would suggest the ball park of 15%. Suggesting a ball park figure is a little crazy as there is a very large number of factors that effect the ORM overhead including JVM settings, jdbc performance, the nature of the query, the number of scalar values relative to ManyToOne, OneToMany etc type associations.... However a ball park maybe useful and I'd be interested if the relative cost for you was much higher than that.

Byte Code Generation

ASM is used for all the Byte code generation in Ebean. ASM is a stonkingly great product and I have no hesitation in recommending it. It gives the Developer complete control over the byte code generated and is fast and light.

In general byte code generation brings a level of the 'unknown'. As you step through the Ebean code in a Debugger and goto generated code you will goto line 1 of the source. This is done to indicate that you are currently on generated code (which you can not see).

There is no special requirement to modify ClassLoading or use Java Instrumentation with Ebean. You just need to have it in your classpath and enable the file to be found.

Also note ASM code generation is used to replace reflection.


Ebean has the ability to Serialize an Object graph to be 'Plain Vanilla'. That is you can use this mechanism to replace Byte code generated beans with 'plain vanilla' beans and also replace Ebean Collections (BeanList, BeanSet etc) with the underlying List Set and Map implementations.

This will be useful for people who want to send an Object Graph to a JVM without any Ebean dependancy. No Ebean jars need to be deployed to the other JVM.

JPA Deployment

There is no current support for XML deployment and this is an Enhancement request.

Ebean is designed to be compatible with JPA deployment in terms of annotations and XML. However, there are some details of the JPA deployment which do not ring true and have been ignored.

Database Meta data Driven

Deployment information in Ebean is mostly derived from Database Meta data. That means that generally you do not need to specify Joins, targetTypes or Relationship ownership (mappedBy). This information is determined from the schema. You only need to specify a Join if there is more than one Join between the two tables in question (and it can not be guess based on the foreign key column name).

Naming Convention

Ebean has a pluggable NamingConvention rather than using the JPA defined one.

TableGenerator, SequenceGenerator

For a given Database Ebean will know whether to use AutoIncrement/Identity or Sequences with only DB2 known to support both. It is not expected that you would need to use the SequenceGenerator annotation with Ebean except potentially with DB2 and this is currently unsupported.

With Ebean you can use the GeneratedValue annotation to plugin any external Id generator. This includes UUID or anything you care to build. TableGenerator annotation is currently unsupported and I'd always suggest using a native database sequence/identity feature first.

DDL Generation

Ebean does not support DDL generation from annotations and I personally have no interest in this idea. There are good tools to design and document a database and generate the DDL. Whats more it makes the Java code look like a Dogs breakfast - not for me I'm afraid.

Introduction User Guide (pdf) Install/Configure Public JavaDoc Whitepapers
General Database Specific Byte Code Deployment Annotations Features
Top Bugs Top Enhancements