Hibernate vs JPA vs JDO - prós e contras de cada um? [fechadas]

174

Estou familiarizado com o ORM como um conceito e até usei o nHibernate há vários anos para um projeto .NET; no entanto, não acompanhei o tópico do ORM em Java e não tive a chance de usar nenhuma dessas ferramentas.

Mas agora posso ter a chance de começar a usar algumas ferramentas ORM para um de nossos aplicativos, na tentativa de me afastar de uma série de serviços da web legados.

Estou tendo dificuldade em dizer a diferença entre as especificações da JPA, o que você obtém com a própria biblioteca Hibernate e o que o JDO tem a oferecer.

Então, eu entendo que essa pergunta é um pouco aberta, mas eu esperava obter algumas opiniões sobre:

  • Quais são os prós e os contras de cada um?
  • O que você sugeriria para um novo projeto?
  • Existem certas condições em que faria sentido usar uma estrutura versus a outra?
java hibernate orm jpa jdo matt b
fonte

Respostas:

112

Algumas notas:

  • JDO e JPA são especificações, não implementações.
  • A idéia é que você pode trocar implementações de JPA, se você restringir seu código para usar apenas JPA padrão. (Idem para JDO.)
  • O Hibernate pode ser usado como uma dessas implementações da JPA.
  • No entanto, o Hibernate fornece uma API nativa, com recursos acima e além do JPA.

OMI, eu recomendaria o Hibernate.

Houve alguns comentários / perguntas sobre o que você deve fazer se precisar usar recursos específicos do Hibernate. Existem várias maneiras de analisar isso, mas meu conselho seria:

  • Se você não estiver preocupado com a perspectiva de vínculo com o fornecedor, faça sua escolha entre o Hibernate e outras implementações JPA e JDO, incluindo as várias extensões específicas do fornecedor em sua tomada de decisão.

  • Se você está preocupado com a perspectiva de vínculo com o fornecedor e não pode usar o JPA sem recorrer a extensões específicas do fornecedor, não use o JPA. (Idem para JDO).

Na realidade, você provavelmente precisará negociar o quanto está preocupado com o vínculo com o fornecedor e o quanto precisa dessas extensões específicas do fornecedor.

E também existem outros fatores, como quão bem você / sua equipe conhece as respectivas tecnologias, quanto os produtos custarão no licenciamento e cuja história você acredita sobre o que acontecerá no futuro para a JDO e a JPA.

kit de ferramentas
fonte
8
kit de ferramentas, agradável e curto. Outro ponto que vale a pena mencionar é que o JPA não impede o uso de recursos específicos da implementação, se necessário. Isso significa que o JPA permite usar qualquer recurso do Hibernate quando o Hibernate é uma implementação.
topchef
1
Quais seriam as vantagens de usar o JPA se eu precisar de algum recurso específico do Hibernate?
Bruno Reis
22
Uma observação importante que deve ser adicionada: Embora o JPA e o JDO tenham excelente suporte para RDBMSes, o JDO é independente do 'armazenamento de dados' e, portanto, não se limita ao mundo do RDBMS. Com a tendência atual do NoSQL no momento, uma pessoa seria sensata a considerar o uso de um padrão de persistência que evita bloquear seus aplicativos no tradicional mundo * SQL. Os aplicativos JDO podem ser facilmente implantados nos repositórios de dados não RDBMS. A lista completa dos datastores suportados pode ser encontrada em: datanucleus.org/products/accessplatform/datastores.html
Volksman
2
@Golfman Por que escolher com base no que pode acontecer? Não há nada que o impeça de entrar em algo mais tarde, se você precisar de suporte NoSQL ... KISS
TM.
1
@Bruno - quando você está usando partes não específicas do Hibernate do Hibernate, está usando o JPA. Obviamente, a vantagem de se restringir à JPA pura é que você pode alternar para outra implementação de JPA mais facilmente.
Stephen C
69

Certifique-se de avaliar a implementação do JDO DataNucleus. Começamos com o Hibernate porque parecia muito popular, mas logo percebemos que não era uma solução de persistência 100% transparente. Existem muitas advertências e a documentação está cheia de 'se você tiver essa situação, deverá escrever seu código como este', o que tirou a diversão de modelar e codificar livremente da maneira que desejamos. O JDO nunca me levou a ajustar meu código ou modelo para fazê-lo "funcionar corretamente". Posso apenas projetar e codificar POJOs simples como se fosse usá-los 'na memória' apenas, mas posso persistir com transparência.

A outra vantagem do JDO / DataNucleus sobre o hibernate é que ele não possui sobrecarga de reflexão em todo o tempo de execução e é mais eficiente em memória porque usa aprimoramento do código de byte do tempo de construção (talvez adicione 1 segundo ao tempo de construção para um projeto grande) do que o padrão de proxy ativado por reflexão do tempo de execução do hibernate.

Outra coisa que você pode achar irritante com o Hibernate é que uma referência que você tem ao que você acha que é o objeto ... geralmente é um 'proxy' para o objeto. Sem o benefício do aprimoramento do código de bytes, o padrão de proxy é necessário para permitir o carregamento sob demanda (ou seja, evite puxar todo o gráfico de objetos ao puxar um objeto de nível superior). Esteja preparado para substituir códigos iguais e hash, porque o objeto que você pensa que está referenciando geralmente é apenas um proxy para esse objeto.

Aqui está um exemplo de frustrações que você obterá com o Hibernate e que não obterá com o JDO:

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

Se você gosta de codificar para 'soluções alternativas', certamente, o Hibernate é para você. Se você aprecia um desenvolvimento limpo, puro, orientado a objetos e orientado a modelos, onde gasta todo o seu tempo em modelagem, design e codificação e nada disso em soluções alternativas feias, passe algumas horas avaliando o JDO / DataNucleus . As horas investidas serão reembolsadas mil vezes.

Atualização fevereiro de 2017

Por algum tempo, o DataNucleus 'implementa o padrão de persistência JPA, além do padrão de persistência JDO, portanto, a portabilidade dos projetos JPA existentes do Hibernate para o DataNucleus deve ser bastante direta e você pode obter todos os benefícios mencionados acima do DataNucleus com muito pouca alteração de código. , caso existam. Portanto, em termos de pergunta, a escolha de um padrão específico, JPA (somente RDBMS) vs JDO (RDBMS + Sem SQL + ODBMSes + outros), o DataNucleus suporta ambos, o Hibernate é restrito apenas ao JPA.

Desempenho das atualizações do banco de dados Hibernate

Outra questão a considerar ao escolher um ORM é a eficiência de seu mecanismo de verificação suja - que se torna muito importante quando é necessário construir o SQL para atualizar os objetos que foram alterados na transação atual - especialmente quando há muitos objetos. Há uma descrição técnica detalhada do mecanismo de verificação suja do Hibernate nesta resposta do SO: JPA com inserção HIBERNATE muito lenta

Volksman
fonte
3
E como todos sabemos, o aprimoramento é precisamente o motivo pelo qual a JDO foi adotada de maneira tão massiva!
Pascal Thivent 18/03/10
15
O FUD bem divulgado e o astroturfing executados pelos principais jogadores do Hibernate nos primeiros dias em relação ao JDO não são nada menos do que desonestos e nojentos e, sem dúvida, tiveram algum efeito na adoção do JDO. Atualmente, os desenvolvedores sabem que o aprimoramento do código de bytes não é um problema e costumam usá-lo para diversos propósitos, além da persistência. A nova biblioteca de aprimoramento de código de bytes ASM é tão rápida que você nem precisa de tempo para respirar antes de terminar.
Volksman
7
A falha do JDO foi prevista desde o início ( javalobby.org/forums/thread.jspa?forumID=46&threadID=1326 ) e antes do Hibernate, portanto você não pode culpar o Hibernate por isso. O Hibernate / Toplink teve êxito onde os jogadores da Sun e JDO (e seus OODBMS) falharam porque eram melhores respostas naquele momento, não por causa do marketing e do FUD. Período. Quem se importa se o ASM está em alta velocidade hoje , não estava lá há mais de 5 anos, quando necessário, e a JDO simplesmente perdeu a batalha. JDO é conceitualmente superior? Pena que falhou em ter uma implementação vencedora a tempo (e não voltará por causa da JPA).
Pascal Thivent 19/03/10
2
Para ilustrar minhas palavras (mais um post que ilustra a dor que as pessoas estavam sentindo durante o desenvolvimento ou por que o Hibernate venceu a batalha): mail-archive.com/[email protected]/… . Parece-me óbvio que o reflection / cglib foi uma resposta prática para os problemas das pessoas (e as pessoas não se importam se uma API é conceitualmente superior se for difícil de usar) e não vejo nenhum jogador-chave do Hibernate aqui, apenas usuários . Então, com a maravilha final eu quem está se espalhando FUD na verdade ...
Pascal Thivent
7
Bem, isso certamente não é como nos velhos tempos, em que haveria pelo menos 17 postagens pro Hibernate FUD diferentes (mas apenas provenientes de três endereços IP diferentes. Faça o pessoal da matemática =)).
Volksman
54

Avaliei recentemente e escolhi uma estrutura de persistência para um projeto java e minhas descobertas são as seguintes:

O que estou vendo é que o apoio a favor da JDO é principalmente:

  • você pode usar fontes de dados não-sql, db4o, hbase, ldap, bigtable, couchdb (plugins para cassandra) etc.
  • você pode alternar facilmente de uma fonte de dados sql para não-sql e vice-versa.
  • nenhum objeto proxy e, portanto, menos problemas com relação às implementações hashcode () e equals ()
  • mais POJO e, portanto, menos soluções alternativas necessárias
  • suporta mais tipos de relacionamento e campo

e o apoio a favor da JPA é principalmente:

  • mais popular
  • jdo está morto
  • não usa aprimoramento de bytecode

Estou vendo muitas postagens pró-JPA de desenvolvedores de JPA que claramente não usaram o JDO / Datanucleus oferecendo argumentos fracos por não usar o JDO.

Também estou vendo muitas postagens de usuários do JDO que migraram para o JDO e são muito mais felizes como resultado.

Quanto à JPA ser mais popular, parece que isso se deve em parte ao suporte do fornecedor do RDBMS, em vez de ser tecnicamente superior. (Parece VHS / Betamax para mim).

O JDO e seu Datanucleus de implementação de referência claramente não estão mortos, como mostra a adoção do Google pelo GAE e desenvolvimento ativo no código-fonte (http://sourceforge.net/projects/datanucleus/).

Vi várias reclamações sobre o JDO devido ao aprimoramento do bytecode, mas ainda não há explicação para o motivo.

De fato, em um mundo que está ficando cada vez mais obcecado pelas soluções NoSQL, o JDO (e a implementação do datanucleus) parece uma aposta muito mais segura.

Acabei de começar a usar o JDO / Datanucleus e o configurei para que eu possa alternar facilmente entre o uso do db4o e o mysql. É útil para o desenvolvimento rápido usar o db4o e não precisar se preocupar muito com o esquema do banco de dados; depois, quando o esquema estiver estabilizado para implantar em um banco de dados. Também me sinto confiante de que, mais tarde, eu poderia implantar toda / parte do meu aplicativo no GAE ou aproveitar o armazenamento distribuído / reduzir o mapa a la hbase / hadoop / cassandra sem muita refatoração.

Achei um pouco complicado começar com o Datanucleus - a documentação no site do datanucleus é um pouco difícil de entender - os tutoriais não são tão fáceis de seguir quanto eu gostaria. Dito isto, a documentação mais detalhada sobre a API e o mapeamento é muito boa quando você passa pela curva de aprendizado inicial.

A resposta é: depende do que você deseja. Prefiro ter opções nosql de código mais limpo, sem fornecedor-lock-in, mais orientado a pojo e versos mais populares.

Se você deseja a sensação agitada de estar fazendo o mesmo que a maioria dos outros desenvolvedores / ovelhas, escolha JPA / hibernate. Se você quer liderar em seu campo, teste o JDO / Datanucleus e faça sua própria decisão.

Tom
fonte
9
Na verdade, como eu disse, estava apenas dando minhas impressões sobre o que havia descoberto enquanto tentava escolher uma solução. Sim, eu sou iniciante em Java, por que isso deveria ser tão relevante? Você, por outro lado, postou várias vezes declarando sua opinião de que a JDO está morta sem oferecer fatos ou provas para comprová-la e sem reconhecer as áreas técnicas em que a JDO é claramente superior. Obviamente, você tem algo pessoal contra o JDO / Datanucleus e está usando esses threads como um meio de perpetuar sua postura anti-JDO.
Tom
4
Pascal - você está discutindo em um canto aqui. Acho que você está perdendo o objetivo da seção Publicidade das Perguntas frequentes. O OP solicitou opiniões sobre duas tecnologias. Está convidando aqueles que apóiam os dois lados a apresentarem suas críticas / recomendações construtivas. Para Andy / Datanucleus e outros usuários do JDO, destacar os pontos positivos do JDO e se defender contra críticas não é mais publicidade do que alguém aqui recomendando o uso do hibernate.
Tom
5
Você pode fazer bem em consultar a seção das Perguntas frequentes que diz 'Seja legal', pois suas postagens sobre esse tópico foram acusatórias, de confronto ou rudes. Seu primeiro foi um comentário sarcástico sobre aprimoramento. Segundo; discursa sobre as dificuldades das implementações iniciais e não é mais relevante. Terceiro, foi uma zombaria infantil e um insulto para aqueles que preferem não usar o RDBMS. Quarto: zombar de alguém que tem opiniões diferentes sobre você. Quinto foi um ataque; me chamando de papagaio. Você considera isso 'Ser legal'?
Tom
3
Se você teve uma experiência horrível com o JDO, explique o que foi horrível, reconheça que estava com uma versão anterior e que as coisas podem ter sido melhoradas desde então. Você também precisa reconhecer que outras pessoas podem ter necessidades diferentes para você. Só porque você está "satisfeito" com o JPA e deseja usar um RDBMS não significa que os outros estejam. Talvez com a pressa de aumentar sua reputação, você tenha perdido de vista o que essa reputação existe para premiar? ps. Como desenvolvedor, você realmente deve estar interessado no bem-estar de projetos, pois é isso que impulsiona a inovação e reduz o bloqueio de fornecedores.
Tom
6
Essa será minha resposta final :) 1. Se não foi relevante questionar por que aumentá-la? 2. Nunca questionei sua honestidade, disse que você não estava sendo gentil com outros pôsteres e que se contradizia. 3. ninguém sugeriu que você resumisse mais de 8 anos - mas faça backup de suas declarações com fatos e exemplos, em vez de declarações subjetivas que provavelmente ofenderão. 5. Onde está a atitude 'hibernate / jpa / jboss is evil' neste post? Eu não vejo isso. Eu só vejo seus comentários anti-JDO.
Tom
40

O que você sugeriria para um novo projeto?

Eu também não sugeriria! Use Spring DAO's JdbcTemplatejunto com StoredProcedure, RowMappere em RowCallbackHandlervez disso.

Minha experiência pessoal com o Hibernate é que o tempo economizado antecipadamente é mais do que compensado pelos intermináveis ​​dias que você passará na fila tentando entender e depurar problemas como um comportamento inesperado de atualização em cascata.

Se você estiver usando um banco de dados relacional, quanto mais próximo seu código estiver, mais controle você terá. A camada DAO do Spring permite um controle fino da camada de mapeamento, enquanto elimina a necessidade de código padrão. Além disso, ele se integra à camada de transações do Spring, o que significa que você pode facilmente adicionar (via AOP) um comportamento transacional complicado sem que isso se intrometa no seu código (é claro, você também obtém isso no Hibernate).

oxbow_lakes
fonte
4
essa é claramente a opção de mapeamento anti-objeto-relacional (ORM) orientada por grandes usuários e base de códigos acumulados desde os tempos ODBC (início dos anos 90) (leia-se legado). Não há razão para não usar o JDBC (com ou sem Spring), a menos que você opte por seguir em frente e usar a estrutura ORM. Pense nas pessoas que um dia decidiram abandonar o FORTRAN para usar C ou Pascal.
Topchef 10/03/10
23
@grigory - Eu falo com muita experiência em perder dias tentando entender problemas do Hibernate, como atualizações / exclusões em cascata, estruturas de consulta ridiculamente ineficientes etc. As soluções ORM são um "ganho rápido" para aqueles com entendimento insuficiente dos bancos de dados relacionais. Como tal, é improvável que o conhecimento do Hibernate sozinho resulte em um bom produto final. É minha experiência que, ao longo do ciclo de vida do projeto, o Hibernate (e o ORM por extensão) custa mais tempo do que economiza
oxbow_lakes
8
lamento que você tenha tido uma experiência tão ruim com o Hibernate. Estou vindo da escola pesada de banco de dados / SQL / procedimento armazenado / JDBC. Não posso dizer que sou convertido - todas as tecnologias acima ainda têm um lugar para estar. Mas, para uso geral, a aplicação Java de três camadas (independentemente do tamanho) é uma tecnologia ORM - preferencialmente JPA 2. Outras devem ser consideradas com base nesses fatores: código legado, integração, experiência, requisitos de lotes pesados, tempo real desempenho, etc., que podem orientar (ou não) a abordagem de diferentes pilhas de tecnologias de banco de dados.
Topchef
3
Eu discordo completamente da definição de "vitória rápida" acima - basta pegar o Hibernate in Action ( stackoverflow.com/questions/96729/… ) (e é o JPA 1, com o JPA 2 fica ainda melhor) para entender completamente o poder e a cobertura dessa tecnologia tem.
Topchef
7
Fiz uma pequena pesquisa e o Spring não recomenda mais o DAO da Spring ( static.springsource.org/spring/docs/3.0.x/… ): "O estilo de integração recomendado é codificar o DAO com base nas APIs simples do Hibernate, JPA e JDO. o estilo mais antigo de usar os modelos DAO do Spring não é mais recomendado; "... Era isso que você estava recomendando? Se sim, por que eles não recomendam?
usar o seguinte
23

JDO está morto

Como o JDO não está morto, verifique seus fatos. O JDO 2.2 foi lançado em outubro de 2008. O JDO 2.3 está em desenvolvimento.

Isso é desenvolvido abertamente, no Apache. Mais lançamentos do que o JPA, e sua especificação ORM ainda está adiantada, mesmo dos recursos propostos pelo JPA2

DataNucleus
fonte
12
As pessoas certamente o estão usando, como evidenciado pelos muitos usuários que o DataNucleus possui, não importa Xcalia, Kodo. Você perde a ideia básica de que JDO e JPA não estão preenchendo o mesmo mercado. O JPA é exclusivamente RDBMS. JDO é armazenamento de dados agnósticos e é usado para RDBMS, mas também LDAP, XML, Excel, OODBMS etc
DataNucleus
3
Gosto do fator não RDBMS, principalmente com o aumento da popularidade de soluções não RDBMS, é um grande negócio. Isso significa que, se a JPA não evoluir rápido o suficiente, a disponibilidade de uma alternativa "mais aberta" e flexível (JDO) significa que a popularidade da JPA tenderá para baixo, por necessidade. Não importa os argumentos técnicos de que o JDO é mais completo, superior, maduro ou qualquer outra coisa - não será uma questão de preferência . Faz sentido que os fornecedores de RDBMS estejam se comportando de forma suspeita - os dias de domínio no mercado de RDBMS podem estar chegando ao fim.
Manius
Ainda estamos usando o JDO / DataNucleus em 2019! Agora está na versão 5.xe ainda supera o Hibernate para produtividade do desenvolvedor e desempenho de tempo de execução. Recentemente, tive que fazer uma consultoria em um aplicativo Web grande usando o Hibernate e lembrei-me da dor que sofri quando era usuário e promotor ativo do HIbernate há muitos anos. Um líder de equipe não acreditou em mim quando disse a ela que seu campo BLOB sempre foi buscado com avidez, mesmo que marcado como preguiçoso. A completa falta de conhecimento "por baixo do capô" de um especialista em Hibernate auto-proclamado "experiente" era tristemente perturbadora, mas esperada.
Volksman
15

O JDO possui recursos avançados que o JPA, consulte http://db.apache.org/jdo/jdo_v_jpa.html

Sandeep Manne
fonte
Muito verdadeiro! Mas ninguém parece saber isso ...
marcolopes
10

Estou usando o JPA (implementação OpenJPA do Apache, que é baseada na base de código KODO JDO, que tem mais de 5 anos e é extremamente rápida / confiável). IMHO quem disser para ignorar as especificações está dando um mau conselho. Eu dediquei o tempo e fui definitivamente recompensado. Com o JDO ou o JPA, é possível alterar os fornecedores com alterações mínimas (o JPA possui mapeamento orm, portanto, estamos falando menos de um dia para possivelmente mudar de fornecedor). Se você tiver mais de 100 mesas como eu, isso é enorme. Além disso, você obtém o cache built-in com despejos de cache em cluster e tudo é bom. O SQL / Jdbc é adequado para consultas de alto desempenho, mas a persistência transparente é muito superior para escrever seus algoritmos e rotinas de entrada de dados. Eu só tenho cerca de 16 consultas SQL em todo o meu sistema (mais de 50k linhas de código).


fonte
8

Eu estive investigando isso sozinho e não consigo encontrar uma forte diferença entre os dois. Eu acho que a grande escolha é em qual implementação você usa. Para mim, estive considerando a plataforma DataNucleus , pois é uma implementação independente de armazenamento de dados de ambas.

tapi
fonte
6
+1 para DataNucleus, não para a resposta.
9409 WolfmanDragon
8

Quem diz que JDO está morto é um vendedor de FUD para astroturismo e sabe disso.

JDO está vivo e bem. A especificação ainda é mais poderosa, madura e avançada do que a JPA muito mais jovem e restrita.

Se você deseja limitar-se apenas ao que está disponível no padrão JPA, pode gravar no JPA e usar o DataNucleus como uma implementação de persistência mais transparente e de alto desempenho do que as outras implementações do JPA. É claro que o DataNucleus também implementa o padrão JDO se você deseja a flexibilidade e a eficiência da modelagem que o JDO traz.

Volksman
fonte
1
Ou você usa outra implementação (ótima) com uma comunidade muito maior e consequentemente mais responsiva. Sim, algumas pessoas se importam com isso também.
Pascal Thivent
1
E você fala sobre FUD> :) Engraçado.
Pascal Thivent
2
Seu comentário parece presumir que eu não usei o Hibernate e o JDO.
Volksman
2
Esse tópico parece ter muitas referências de algumas pessoas sobre o quão grande é o DataNucleus. Não use este local como sua plataforma de publicidade.
TM.
3
Nada de surpreendente em Golfman, que cola o mesmo material desesperado de marketing repetidamente em todos os tópicos que envolvem JPA ou DataNucleus (que ele usa desde 1996 , antes mesmo de existir !).
Pascal Thivent 23/08/10
2

Eu usei o Hibernate (implementação JPA) e JPOX (implementação JDO) no mesmo projeto. O JPOX funcionou bem, mas encontrou erros rapidamente, onde alguns recursos da linguagem Java 5 não eram compatíveis no momento. Ocorreu um problema ao executar o bom funcionamento com transações XA. Eu estava gerando o esquema do banco de dados a partir dos objetos JDO. Ele queria se conectar a um banco de dados toda vez que é irritante se a sua conexão Oracle não estiver funcionando.

Em seguida, mudamos para o Hibernate. Brincamos com o uso de JPA puro por um tempo, mas precisamos usar alguns dos recursos específicos do Hibernate para fazer o mapeamento. Executar o mesmo código em vários bancos de dados é muito fácil. O Hibernate parece armazenar objetos em cache de maneira agressiva ou, às vezes, apresenta um comportamento estranho de armazenamento em cache. Existem algumas construções DDL que o Hibernate não pode manipular e, portanto, são definidas em um arquivo adicional que é executado para inicializar o banco de dados. Quando me deparei com um problema de hibernação, muitas vezes há pessoas que se deparam com o mesmo problema, o que facilita a busca de soluções no Google. Finalmente, o Hibernate parece ser bem projetado e confiável.

Alguns outros respondedores sugeriram apenas o uso de SQL. O verdadeiro caso de uso matador para o mapeamento relacional de objetos é teste e desenvolvimento. Os bancos de dados criados para lidar com grandes volumes de dados geralmente são caros e são difíceis de instalar. Eles são difíceis de testar. Há muitos bancos de dados Java na memória que podem ser usados ​​para teste, mas geralmente são inúteis para produção. Ser capaz de usar um banco de dados real, mas limitado, aumentará a produtividade do desenvolvimento e a confiabilidade do código.

Sean McCauliff
fonte
1
Até onde eu sei, o JPOX mudou o nome para DataNucleus (e teve lançamentos desde então).
Donal Fellows
2
Pense que você realmente descobrirá que o DataNucleus tem muito menos bugs abertos do que o outro software ao qual você se refere. Pense que você também descobrirá que o desenvolvimento do DataNucleus está reduzindo o número de bugs a uma taxa mais rápida do que o outro software também.
DataNucleus
1

Fiz uma amostra do WebApp em maio de 2012 que usa o JDO 3.0 e o DataNucleus 3.0 - veja como está limpo: https://github.com/TorbenVesterager/BadAssWebApp

Ok, talvez seja um pouco limpo demais, porque eu uso os POJOs tanto para o banco de dados quanto para o cliente JSON, mas é divertido :)

PS: Contém algumas anotações do SuppressWarnings (desenvolvidas no IntelliJ 11)

Torben Vesterager
fonte