If you like to build easy to install JPA-applications - start with TopLink essentials

Java Persistence API (JPA) allows persisting objects in Java SE and EE environments. But JPA is only the API - the SPI (service provider) ist still needed. JPA is already supported by openJPA, Hibernate and TopLink essentials (a part of the Java EE RI).
Hibernate comes with 38 Jars (the core) and 5 additional jars for the Entity-Manager. So you need about 45 Jars in the classpath which has to be downloaded from 2 locations. openJPA comes with 11 jars - but it needs a setup of the javaagent (-javaagent:.[path]openjpa-all-0.9.6-incubating.jar). All jars can be downloaded from one location.
TopLink essentials comes with 2 Jars - and can be downloaded from one location - not javaagent settings are needed. The good news are: you can switch the persistence provider every time - only the classpath and one entry in the persistence.xml has to be set.
Sample (unmanaged enviroment):

  <persistence-unit name="pdoPU">
            <!-- Provider-specific connection properties -->
            <property name="toplink.jdbc.driver" value="org.apache.derby.jdbc.EmbeddedDriver"/>
            <property name="toplink.jdbc.url" value="jdbc:derby:./javaee5patterns;create=true"/>
            <property name="toplink.jdbc.user" value="javaee5"/>
            <property name="toplink.jdbc.password" value="patterns"/>
            <!-- Provider-specific settings -->
            <property name="toplink.logging.level" value="FINE"/>
            <property name="toplink.ddl-generation" value="drop-and-create-tables"/>

I use TopLink together with JavaDB for the examples of my book "Java EE 5 Architectures" - also because of simplicity. BTW: Netbeans 5.5 and 6.0 supports the development of Java EE 5 apps with integration of JavaDB, glassfish, generation of persistence.xml and built-in SQL-explorer very well. Only the JPA support of standalone, unmanaged, JPA-applications could be better (you have to choose one appserver first...).  You can also use Eclipse 3.X with Dali (eclipse.org/dali) with similar functionality. You can even use both and map the projects to the same directory...

NEW: Online Workhop Effective WebApps without Frameworks is also coming to: MUC Airport.

Airport MUC workshops: Web (SPA, PWAs, Offline, Desktop, Mobile) Applications Essentials and Effective Web Applications. No migrations. #usetheplatform

Podcast: airhacks.fm and newsletter: airhacks.news

A book about rethinking Java EE Patterns


Although i agree that Hibernate is bloated in terms of jar dependencies, the required jars for JPA implementation is minimum 13, not 38. but i must say i am impressed with toplink then.

here are the list and comments (may include mistakes):

commons-logging --> unnecessary. use JDK logger.
commons-collections --> totals unnecessary.
dom4j --> unnecessary, use JDK
ehcache -> required if no ither cache is around.

c3p0 or equivalent connection pool. if you use the stupid dbcp, it has 2 more dependencies.

ejb3-persistence --> not required if under JEE5 server
hibernate-annotations --> annotations implementaion

jdbc2_0-stext.jar -> i dunno why this is required.
jta.jar -> required if not exist in server

hibernate.jar -> huge jar (2.5Megs)

entity manager requires two additional jars.

---- this ones are required if you want faster reflection. ---

Posted by aakin on February 08, 2007 at 02:07 AM CET #

Hibernate does not require 43, 38, or even 13 JARs. Maybe you guys should check the README.txt. The minimum for a project using native Hibernate in Java SE is:

(some JDBC connection pool)

If you want cglib instead of Javassist proxy generation (not because you want "faster reflection"), you can replace javassist.jar with:


If you want to use annotations instead of XML mappings, you also need:


If you want to use full JPA in Java SE, you also need:


If you run inside a J2EE or Java EE application server, you need fewer libraries, depending what your appserver already supports (connection pool, JTA API, EJB3 API).

If you think one of these dependencies is unnecessary, provide a patch that replaces it with an equivalent JDK feature available in JDK 1.4 and 5.0. If it is well tested, it would certainly be considered for integration. Some of these dependencies will go away naturally, for example, the next Antlr version can create parsers that are runtime-independent.

Posted by Christian on February 12, 2007 at 09:09 PM CET #

Hi Christian,

I know the Readme, but a JPA-beginner has to go through the doc an remove superfluos jars. This can potentially change in every release. So the easiest way at beginning is to add everything, and optimize later.

Thank you for your comment! (Der Spam-Filter is schrott -> nichtmal meine Kommentare werden akzeptiert :-))

Posted by Adam Bien on February 14, 2007 at 10:45 AM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
Online Workshops
...the last 150 posts
...the last 10 comments