Hibernate vs JPA vs JDO: ¿pros y contras de cada uno? [cerrado]

174

Estoy familiarizado con ORM como concepto, e incluso he usado nHibernate hace varios años para un proyecto .NET; sin embargo, no me he mantenido al día con el tema de ORM en Java y no he tenido la oportunidad de usar ninguna de estas herramientas.

Pero, ahora puedo tener la oportunidad de comenzar a usar algunas herramientas ORM para una de nuestras aplicaciones, en un intento de alejarme de una serie de servicios web heredados.

Me está costando distinguir la diferencia entre la especificación JPA, lo que obtienes con la propia biblioteca Hibernate y lo que JDO tiene para ofrecer.

Entonces, entiendo que esta pregunta es un poco abierta, pero esperaba obtener algunas opiniones sobre:

  • ¿Cuáles son los pros y los contras de cada uno?
  • ¿Cuál sugerirías para un nuevo proyecto?
  • ¿Hay ciertas condiciones en las que tendría sentido usar un marco frente al otro?
java hibernate orm jpa jdo mate b
fuente

Respuestas:

112

Algunas notas:

  • JDO y JPA son especificaciones, no implementaciones.
  • La idea es que puede intercambiar implementaciones de JPA, si restringe su código para usar solo JPA estándar. (Lo mismo para JDO.)
  • Hibernate se puede utilizar como una implementación de JPA.
  • Sin embargo, Hibernate proporciona una API nativa, con características superiores a las de JPA.

En mi opinión, recomendaría Hibernate.

Ha habido algunos comentarios / preguntas sobre lo que debe hacer si necesita usar funciones específicas de Hibernate. Hay muchas formas de ver esto, pero mi consejo sería:

  • Si no le preocupa la perspectiva de un vínculo con el proveedor, elija Hibernate y otras implementaciones de JPA y JDO, incluidas las diversas extensiones específicas del proveedor en la toma de decisiones.

  • Si le preocupa la posibilidad de un vínculo con el proveedor y no puede usar JPA sin recurrir a extensiones específicas del proveedor, entonces no use JPA. (Lo mismo para JDO).

En realidad, es probable que deba compensar cuánto le preocupa el vínculo del proveedor frente a cuánto necesita esas extensiones específicas del proveedor.

Y también hay otros factores, como qué tan bien usted / su personal conoce las tecnologías respectivas, cuánto costarán los productos en las licencias y qué historia cree sobre lo que sucederá en el futuro para JDO y JPA.

kit de herramientas
fuente
8
kit de herramientas, agradable y corto. Otro punto que vale la pena mencionar es que JPA no evita el uso de funciones específicas de implementación si es necesario. Eso significa que JPA le permite usar cualquier función de Hibernate cuando Hibernate es una implementación.
topchef
1
¿Cuáles serían las ventajas de usar JPA si necesito alguna característica específica de Hibernate?
Bruno Reis
22
Se debe agregar una nota importante: si bien JPA y JDO tienen un excelente soporte para RDBMS, JDO es independiente del 'almacén de datos' y, por lo tanto, no se limita al mundo RDBMS. Con la expansión de NoSQL en este momento, una persona sería prudente considerar usar un estándar de persistencia que evite bloquear sus aplicaciones en el mundo tradicional * SQL. Las aplicaciones JDO se pueden implementar fácilmente en áreas de almacenamiento de datos que no sean RDBMS. La lista completa de almacenes de datos compatibles se puede encontrar en: datanucleus.org/products/accessplatform/datastores.html
Volksman
2
@Golfman, ¿por qué elegir según lo que pueda suceder? No hay nada que te impida rodar en algo más tarde si alguna vez terminaste necesitando soporte NoSQL ... KISS
TM.
1
@Bruno: cuando está utilizando partes de Hibernate no específicas de Hibernate, está utilizando JPA. Obviamente, la ventaja de restringirse a JPA puro es que puede cambiar a otra implementación de JPA más fácilmente.
Stephen C
69

Asegúrese de evaluar la implementación de DataNucleus de JDO. Comenzamos con Hibernate porque parecía ser muy popular, pero pronto nos dimos cuenta de que no era una solución de persistencia 100% transparente. Hay demasiadas advertencias y la documentación está llena de 'si tiene esta situación, entonces debe escribir su código de esta manera' que eliminó la diversión de modelar y codificar libremente como queramos. JDO tiene nunca me hecho ajustar mi código o mi modelo para que funcione correctamente. Solo puedo diseñar y codificar POJO simples como si fuera a usarlos 'solo en memoria', pero puedo persistirlos de manera transparente.

La otra ventaja de JDO / DataNucleus sobre la hibernación es que no tiene toda la sobrecarga de reflexión del tiempo de ejecución y es más eficiente en memoria porque utiliza la mejora del código de bytes de tiempo de construcción (quizás agregue 1 segundo a su tiempo de construcción para un proyecto grande) que el patrón proxy de reflexión de tiempo de ejecución de hibernate.

Otra cosa que puede resultar molesta con Hibernate es que una referencia que tiene a lo que cree que es el objeto ... a menudo es un 'proxy' para el objeto. Sin el beneficio de la mejora del código de bytes, se requiere el patrón proxy para permitir la carga a pedido (es decir, evitar tirar de todo el gráfico de objetos cuando se tira de un objeto de nivel superior). Esté preparado para anular equals y hashcode porque el objeto que cree que está haciendo referencia a menudo es solo un proxy para ese objeto.

Aquí hay un ejemplo de las frustraciones que obtendrá con Hibernate que no obtendrá con JDO:

http://blog.andrewbeacock.com/2008/08/how-to-implement-hibernate-safe-equals.html
http://burtbeckwith.com/blog/?p=53

Si te gusta la codificación para 'soluciones', entonces, seguro, Hibernate es para ti. Si aprecia el desarrollo limpio, puro, orientado a objetos e impulsado por modelos, en el que pasa todo su tiempo modelando, diseñando y codificando, y nada de eso en soluciones desagradables, luego pase unas horas evaluando JDO / DataNucleus . Las horas invertidas se pagarán mil veces.

Actualización de febrero de 2017

Desde hace bastante tiempo, DataNucleus implementa el estándar de persistencia JPA además del estándar de persistencia JDO, por lo que portar proyectos JPA existentes desde Hibernate a DataNucleus debería ser muy sencillo y puede obtener todos los beneficios mencionados anteriormente de DataNucleus con muy poco cambio de código , Si alguna. Entonces, en términos de la pregunta, la elección de un estándar particular, JPA (solo RDBMS) vs JDO (RDBMS + No SQL + ODBMSes + otros), DataNucleus admite ambos, Hibernate está restringido a JPA solamente.

Rendimiento de las actualizaciones de Hibernate DB

Otro tema a considerar al elegir un ORM es la eficiencia de su mecanismo de verificación sucio, que se vuelve muy importante cuando necesita construir el SQL para actualizar los objetos que han cambiado en la transacción actual, especialmente cuando hay muchos objetos. Hay una descripción técnica detallada del mecanismo de verificación sucio de Hibernate en esta respuesta SO: JPA con inserción HIBERNATE muy lenta

Volksman
fuente
3
Y como todos sabemos, la mejora es precisamente la razón por la cual JDO ha sido tan masivamente adoptado.
Pascal Thivent
15
El bien publicitado FUD y el astroturfing ejecutados por jugadores clave de Hibernate en los primeros días en relación con JDO es deshonesto y desagradable y sin duda tuvo algún efecto en la adopción de JDO. En la actualidad, los desarrolladores saben que la mejora del código de bytes no es un problema en absoluto y, a menudo, la utilizan para muchos propósitos diferentes, además de la persistencia. La nueva biblioteca de mejora de código de bytes ASM es tan rápida que ni siquiera tiene tiempo para respirar antes de que esté lista.
Volksman
77
El fracaso de JDO se predijo desde el inicio ( javalobby.org/forums/thread.jspa?forumID=46&threadID=1326 ) y antes de Hibernate, por lo que no puede culpar a Hibernate por eso. Hibernate / Toplink tuvo éxito donde los jugadores de Sun y JDO (y sus OODBMS) fallaron porque eran mejores respuestas en ese momento, no por marketing y FUD. Período. A quién le importa si ASM está ardiendo rápidamente hoy , no estaba allí hace más de 5 años, cuando era necesario y JDO simplemente perdió la batalla. ¿JDO es conceptualmente superior? Lástima, no pudo tener una implementación ganadora a tiempo (y no volverá debido a JPA).
Pascal Thivent
2
Para ilustrar mis palabras (otra publicación más que ilustra el dolor que la gente sentía durante el desarrollo o por qué Hibernate ganó la batalla): mail-archive.com/[email protected]/… . Me parece obvio que la reflexión / cglib era una respuesta práctica a los problemas de las personas (y a las personas no les importa si una API es conceptualmente superior si es difícil de usar) y no veo ningún jugador clave de Hibernate aquí, solo usuarios . Así que al final me pregunto quién está difundiendo FUD en realidad ...
Pascal Thivent
77
Bueno, esto ciertamente no es como en los viejos tiempos donde habría habido al menos 17 publicaciones diferentes de Pro Hibernate FUD (sin embargo, solo provienen de 3 direcciones IP diferentes. Haga las personas de matemáticas =)).
Volksman
54

Recientemente he evaluado y elegido un marco de persistencia para un proyecto de Java y mis hallazgos son los siguientes:

Lo que estoy viendo es que el apoyo a favor de JDO es principalmente:

  • puede usar fuentes de datos que no sean SQL, db4o, hbase, ldap, bigtable, couchdb (complementos para cassandra), etc.
  • puede cambiar fácilmente de una fuente de datos sql a no sql y viceversa.
  • sin objetos proxy y, por lo tanto, menos dolor con respecto a las implementaciones de hashcode () y equals ()
  • Se necesita más POJO y, por lo tanto, menos soluciones alternativas
  • admite más relaciones y tipos de campo

y el apoyo a favor de JPA es principalmente:

  • más popular
  • jdo está muerto
  • no utiliza la mejora de bytecode

Estoy viendo muchas publicaciones pro-JPA de desarrolladores de JPA que claramente no han usado JDO / Datanucleus que ofrecen argumentos débiles para no usar JDO.

También estoy viendo muchas publicaciones de usuarios de JDO que han migrado a JDO y como resultado están mucho más felices.

Con respecto a que JPA es más popular, parece que esto se debe en parte al soporte del proveedor RDBMS en lugar de ser técnicamente superior. (A mí me suena como VHS / Betamax).

JDO y su implementación de referencia Datanucleus claramente no está muerto, como lo demuestra la adopción de Google para GAE y el desarrollo activo en el código fuente (http://sourceforge.net/projects/datanucleus/).

He visto una serie de quejas sobre JDO debido a la mejora del código de bytes, pero todavía no hay una explicación de por qué es malo.

De hecho, en un mundo cada vez más obsesionado por las soluciones NoSQL, JDO (y la implementación del núcleo de datos) parece una apuesta mucho más segura.

Recién comencé a usar JDO / Datanucleus y lo configuré para poder cambiar fácilmente entre usar db4o y mysql. Es útil para el desarrollo rápido usar db4o y no tener que preocuparse demasiado por el esquema de base de datos y luego, una vez que el esquema se estabilice para implementarse en una base de datos. También me siento seguro de que más adelante, podría implementar toda / parte de mi aplicación en GAE o aprovechar el almacenamiento distribuido / reducir el mapa a la hbase / hadoop / cassandra sin demasiada refactorización.

Encontré el obstáculo inicial de comenzar con Datanucleus un poco complicado: la documentación en el sitio web de datanucleus es un poco difícil de abordar; los tutoriales no son tan fáciles de seguir como me hubiera gustado. Dicho esto, la documentación más detallada sobre la API y el mapeo es muy buena una vez que pasa la curva de aprendizaje inicial.

La respuesta es, depende de lo que quieras. Prefiero tener un código más limpio, sin bloqueo del proveedor, más orientado a pojo, las opciones nosql y los versos más populares.

Si desea la sensación cálida y quisquillosa de que está haciendo lo mismo que la mayoría de los otros desarrolladores / ovejas, elija JPA / hibernate. Si desea liderar en su campo, pruebe JDO / Datanucleus y tome una decisión.

Tom
fuente
9
En realidad, tal como dije, solo estaba dando mis impresiones de lo que había descubierto al tratar de elegir una solución. Sí, soy un principiante en Java, ¿por qué debería ser eso tan importante? Usted, por otro lado, ha publicado varias veces declarando su opinión de que JDO está muerto sin ofrecer ningún hecho o prueba para corroborarlo y sin reconocer las áreas técnicas en las que JDO es claramente superior. Obviamente tiene algo personal contra JDO / Datanucleus y está utilizando estos hilos como un medio para perpetuar su postura anti-JDO.
Tom
44
Pascal: estás discutiendo en un rincón aquí. Creo que te estás perdiendo el punto de la sección Publicidad de las Preguntas frecuentes. El OP solicitó opiniones sobre 2 tecnologías. Invita a quienes apoyan a cualquiera de las partes a presentar y presentar sus críticas / recomendaciones constructivas. Para Andy / Datanucleus y otros usuarios de JDO resaltar los positivos de JDO y defenderse de las críticas no es más publicidad que alguien más que recomienda usar hibernación.
Tom
55
Puede hacer bien en consultar la sección de Preguntas frecuentes que dice 'Sé amable' porque tus publicaciones sobre este tema han sido acusatorias, de confrontación o simplemente groseras. Su primer comentario fue sarcástico sobre la mejora. Segundo; despotrica sobre las dificultades de las primeras implementaciones y ya no es relevante. El tercero fue una burla e insulto infantil para aquellos que preferirían no usar RDBMS. El cuarto fue la burla sarcástica de alguien que tiene diferentes puntos de vista para ti. Quinto fue un ataque; llamándome loro ¿Considera esto 'Ser amable'?
Tom
3
Si tuvo una experiencia horrible con JDO, explique qué fue horrible, reconozca que fue con una versión anterior y que las cosas pueden haber mejorado desde entonces. También debe reconocer que otros pueden tener diferentes necesidades para usted. El hecho de que esté 'satisfecho' con JPA y quiera usar un RDBMS no significa que otros lo estén. ¿Quizás en su prisa por aumentar su reputación ha perdido de vista lo que esa reputación puede otorgar? PD. Como desarrollador, realmente debería estar interesado en el bienestar de tales proyectos, ya que eso es lo que impulsa la innovación y reduce el bloqueo del proveedor.
Tom
66
Esta será mi respuesta final :) .. 1. Si no fue relevante preguntar por qué plantearlo. 2. Nunca cuestioné tu honestidad, dije que no estabas siendo amable con otros carteles y que te contradecías. 3. nadie sugirió que resumiera más de 8 años, pero respalde sus declaraciones con hechos y ejemplos en lugar de declaraciones subjetivas que puedan ofender. 5. ¿Dónde está la actitud de 'hibernate / jpa / jboss is evil' en esta publicación? No lo veo Solo veo tus comentarios anti-JDO.
Tom
40

¿Cuál sugerirías para un nuevo proyecto?

Yo sugeriría tampoco! Use Spring DAO's JdbcTemplatejunto con StoredProcedure, RowMappery en su RowCallbackHandlerlugar.

Mi propia experiencia personal con Hibernate es que el tiempo ahorrado por adelantado está más que compensado por los interminables días que pasará en el futuro tratando de comprender y depurar problemas como el comportamiento inesperado de la actualización en cascada.

Si está utilizando una base de datos relacional, cuanto más cerca esté su código, más control tendrá. La capa DAO de Spring permite un control preciso de la capa de mapeo, al tiempo que elimina la necesidad de código repetitivo. Además, se integra en la capa de transacciones de Spring, lo que significa que puede agregar fácilmente (a través de AOP) un comportamiento transaccional complicado sin que esto se entrometa en su código (por supuesto, también lo obtiene con Hibernate).

oxbow_lakes
fuente
44
Esta es claramente una elección de mapeo antirreferencial (ORM) impulsada por una gran base de usuarios y códigos acumulada desde tiempos ODBC (principios de los 90) (legado de legado). No hay ninguna razón para no usar JDBC (con o sin Spring) a menos que elija continuar y usar el marco ORM. Piense en aquellas personas que un día decidieron abandonar FORTRAN para usar C o Pascal.
topchef
23
@grigory: hablo con mucha experiencia de perder días tratando de comprender los problemas de Hibernate, como actualizaciones / eliminaciones en cascada, estructuras de consulta ridículamente ineficientes, etc. Las soluciones ORM son una "ganancia rápida" para aquellos con una comprensión insuficiente de las bases de datos relacionales. Como tal, es poco probable que el conocimiento de Hibernate solo resulte en un buen producto final. Según mi experiencia, durante el ciclo de vida del proyecto, Hibernate (y ORM por extensión) cuesta más tiempo del que ahorra
Oxbow_lakes
8
Lamento que hayas tenido tan mala experiencia con Hibernate. Vengo de una base de datos pesada / SQL / procedimiento almacenado / escuela JDBC. No puedo decir que soy convertido: todas las tecnologías anteriores todavía tienen un lugar para estar. Pero para propósitos generales, la aplicación Java de 3 niveles (sin importar el tamaño) es una tecnología ORM, preferiblemente JPA 2. Otras deben considerarse en función de dichos factores, código heredado, integración, experiencia, requisitos de lotes pesados, en tiempo real rendimiento, etc., que puede dirigir (o no) el enfoque hacia una pila de tecnología de base de datos diferente.
topchef
3
Estoy completamente en desacuerdo con la definición de "victoria rápida" anterior: solo tome Hibernate en acción ( stackoverflow.com/questions/96729/… ) (y es JPA 1, con JPA 2 solo mejora) para comprender completamente el poder y la cobertura de esta tecnología tiene.
topchef
77
Investigué un poco y Spring ya no recomienda Spring DAO's ( static.springsource.org/spring/docs/3.0.x/… ): "El estilo de integración recomendado es codificar DAOs contra APIs simples de Hibernate, JPA y JDO. ya no se recomienda el estilo anterior de usar las plantillas DAO de Spring; "... ¿Es esto lo que estaba recomendando? Si es así, ¿por qué no lo recomiendan?
Usuario1
23

JDO está muerto

JDO no está muerto en realidad, así que por favor verifique sus hechos. JDO 2.2 fue lanzado en octubre de 2008 JDO 2.3 está en desarrollo.

Esto se desarrolla abiertamente, bajo Apache. Más lanzamientos que JPA ha tenido, y su especificación ORM aún está por delante de incluso las características propuestas por JPA2

DataNucleus
fuente
12
Ciertamente, las personas lo usan, como lo demuestran los muchos usuarios que DataNucleus tiene, no importa Xcalia, Kodo. Echas de menos la idea básica de que JDO y JPA no están llenando el mismo mercado. JPA es exclusivamente RDBMS. JDO es independiente del almacén de datos y se usa para RDBMS, pero también LDAP, XML, Excel, OODBM, etc.
DataNucleus
3
Me gusta el factor que no es RDBMS, particularmente con el aumento de popularidad de las soluciones que no son RDBMS, es un gran problema. Esto significa que si JPA no evoluciona lo suficientemente rápido, la disponibilidad de una alternativa "más abierta" y flexible (JDO) significa que la popularidad de JPA tenderá a la baja, por necesidad. No importa los argumentos técnicos de que JDO es más completo, superior, maduro o cualquier otra cosa, no será una cuestión de preferencia . Tiene sentido que los proveedores de RDBMS se comporten de manera sospechosa: los días de dominio del mercado de RDBMS pueden estar llegando a su fin.
Manius
¡Todavía estamos usando JDO / DataNucleus en 2019! Ahora es hasta la versión 5.xy aún supera a Hibernate por la productividad del desarrollador y el rendimiento en tiempo de ejecución. Recientemente tuve que hacer algunas consultas en una aplicación web grande usando Hibernate y recordé el dolor que sufrí cuando era un usuario y promotor activo de Hibernate hace muchos años. Un líder del equipo no me creyó cuando le dije que su campo BLOB siempre se buscaba con entusiasmo a pesar de que estaba marcado como vago. La completa falta de conocimiento "bajo el capó" por parte de un experto en Hibernate autoproclamado "experimentado" fue tristemente inquietante pero esperado.
Volksman
10

Estoy usando JPA (implementación de OpenJPA de Apache que se basa en la base de código KODO JDO que tiene más de 5 años y es extremadamente rápida / confiable). En mi humilde opinión, cualquiera que le diga que omita las especificaciones le está dando malos consejos. Puse el tiempo y definitivamente fui recompensado. Con JDO o JPA puede cambiar de proveedor con cambios mínimos (JPA tiene mapeo de ormas, por lo que estamos hablando de menos de un día para cambiar de proveedor). Si tienes más de 100 mesas como yo, esto es enorme. Además, obtienes caché integrado con desalojos de caché en clúster y todo está bien. SQL / Jdbc está bien para consultas de alto rendimiento, pero la persistencia transparente es muy superior para escribir sus algoritmos y rutinas de entrada de datos. Solo tengo alrededor de 16 consultas SQL en todo mi sistema (50k + líneas de código).


fuente
8

He estado investigando esto yo mismo y no puedo encontrar una gran diferencia entre los dos. Creo que la gran opción es en qué implementación utilizas. Para mí, he estado considerando la plataforma DataNucleus , ya que es una implementación independiente de ambos para el almacenamiento de datos.

tapi
fuente
66
+1 para DataNucleus, no para la respuesta.
WolfmanDragon
8

Cualquiera que diga que JDO está muerto es un traficante de FUD astroturfing y lo saben.

JDO está vivo y bien. La especificación es aún más poderosa, madura y avanzada que la JPA mucho más joven y limitada.

Si desea limitarse solo a lo que está disponible en el estándar JPA, puede escribir a JPA y usar DataNucleus como una implementación de persistencia más transparente y de alto rendimiento que las otras implementaciones de JPA. Por supuesto, DataNucleus también implementa el estándar JDO si desea la flexibilidad y eficiencia de modelado que trae JDO.

Volksman
fuente
1
O usa otra implementación (fina) con una comunidad mucho más grande y, en consecuencia, más receptiva. Sí, a algunas personas también les importa eso.
Pascal Thivent
1
Y hablas de FUD> :) Divertido.
Pascal Thivent
2
Su comentario parece suponer que no he usado tanto Hibernate como JDO.
Volksman
2
Este hilo parece tener una gran cantidad de referencias de un par de personas sobre lo genial que es DataNucleus. No utilice este lugar como su plataforma publicitaria.
TM.
3
Nada sorprendente de Golfman que está pegando las mismas cosas de marketing desesperadas una y otra vez en cada hilo que involucra JPA o DataNucleus (que está usando desde 1996 , ¡ incluso antes de que existiera !).
Pascal Thivent
2

He usado Hibernate (implementación JPA) y JPOX (implementación JDO) en el mismo proyecto. JPOX funcionó bien, pero se encontró con errores bastante rápido, allí donde algunas características del lenguaje Java 5 no eran compatibles en ese momento. Tuvo problemas para jugar bien con las transacciones XA. Estaba generando el esquema de la base de datos a partir de los objetos JDO. Quería conectarse a una base de datos cada vez, lo cual es molesto si su conexión de Oracle no funciona.

Luego cambiamos a Hibernate. Jugamos un poco con solo usar JPA puro por un tiempo, pero necesitábamos usar algunas de las características específicas de Hibernate para hacer el mapeo. Ejecutar el mismo código en múltiples bases de datos es muy fácil. Hibernate parece almacenar en caché los objetos agresivamente o simplemente tiene un comportamiento de almacenamiento en caché extraño a veces. Hay algunas construcciones DDL que Hibernate no puede manejar y, por lo tanto, se definen en un archivo adicional que se ejecuta para inicializar la base de datos. Cuando me encuentro con un problema de Hibernate, a menudo hay muchas personas que se han encontrado con el mismo problema, lo que facilita la búsqueda de soluciones en Google. Finalmente, Hibernate parece estar bien diseñado y confiable.

Algunos otros respondedores han sugerido simplemente usar SQL. El caso de uso real para el mapeo relacional de objetos es la prueba y el desarrollo. Las bases de datos que se crean para manejar grandes volúmenes de datos suelen ser costosas o difíciles de instalar. Son difíciles de probar. Hay muchas bases de datos Java en memoria que se pueden usar para realizar pruebas, pero generalmente son inútiles para la producción. Ser capaz de usar una base de datos real, pero limitada, aumentará la productividad del desarrollo y la confiabilidad del código.

Sean McCauliff
fuente
1
Por lo que puedo decir, JPOX cambió su nombre a DataNucleus (y ha tenido lanzamientos desde entonces).
Donal Fellows
2
Piense que realmente encontrará que DataNucleus tiene muchos menos errores abiertos que el otro software al que se refiere. Creo que también encontrará que el desarrollo de DataNucleus está reduciendo la cantidad de errores a un ritmo más rápido que ese otro software también.
DataNucleus
1

Hice una WebApp de muestra en mayo de 2012 que usa JDO 3.0 y DataNucleus 3.0. Observe lo limpia que está: https://github.com/TorbenVesterager/BadAssWebApp

De acuerdo, tal vez sea un poco demasiado limpio, porque uso los POJO tanto para la base de datos como para el cliente JSON, pero es divertido :)

PD: contiene algunas anotaciones SuppressWarnings (desarrollado en IntelliJ 11)

Torben Vesterager
fuente