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 system.properties file to be found.
Also note ASM code generation is used to replace reflection.
Serialization
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.
|