Do not close this as a duplicate of other questions because I'm not asking the same thing. They're also about a year old. That said, see these links:
http://db.apache.org/jdo/jdo_v_jpa.html
http://www.datanucleus.org/products/accessplatform/jdo_jpa_faq.html
http://www.datanucleus.org/products/accessplatform/persistence_api.html
It seems JPA is the "popular" choice backed by the big vendors (who love to screw you over if they can).
It seems JDO is the more mature, seemingly superior choice which should enjoy more OSS community backing. (But does it?)
So what's a low-risk tolerance organization supposed to do? Is the difficulty of going from one to the other about the same? Has one started to emerge above the other at this point? Also, only because we currently use it, does Hibernate limit you to JPA-only? If so what is the most popular JDO implementation?
#Crusader - what makes you think that anyone on SO has a better crystal ball than you do?
So what's a low-risk tolerance organization supposed to do?
Pick the alternative that it determines to be the low risk solution. How it determines what solution has the least risk is ... unclear ... but I don't think that asking SO is a valid risk assessment procedure.
The other point is that choosing JDO when JPA is the "winner" (or vice versa) probably won't kill your project in the short or long term. The consequences of making the wrong choice are most likely limited to greater staff training costs, and being stuck with base ORM platform where development has stagnated and support is increasingly expensive. [I'd protect myself against the latter by picking an open source ORM platform ... either way.]
Is the difficulty of going from one to the other about the same?
Probably yes. Especially when you consider data migration issues.
Has one started to emerge above the other at this point?
JPA seems to dominate these days. The JDO folks would say that their way is technically superior, but that's not the point.
Also, only because we currently use it, does Hibernate limit you to JPA-only?
JPA plus Hibernate-specific extensions. Certainly Hibernate does nor support JDO and it probably never could.
If so what is the most popular JDO implementation?
Pass.
If you use a lightweight dependency injection and ORM wrapping framework like the open source exPOJO it allows you to bypass that question altogether. Your main code base remains completely agnostic of the underlying persistence interface/technology (JDO, Hibernate implementations currently supported, JPA on the way - like to lend a hand?).
All persistence technology specific code is encapsulated within Repository and Service classes as per Chris Richardson's excellent book "POJOs in Action" and exposed using the "exposed domain model" pattern he discusses in the book - which turns out to be pretty awesome and the most productive approach I've ever used.
Using exPOJO 99% of your code remains gloriously and instantly portable between JDO, JPA, Hibernate plus you get extremely lightweight and very simple dependency injection (no annotations or XML required) as an added bonus.
It comes with it's own extremely lightweight and easy to use servlet filter that can provide "open session/persistence manager/entity manager in view" without the XML hell. Each HTTP request is automatically attached to a ModelExposer object that provides convenient access to the repository and service components that allow generic access to your objects.
exPOJO is at http://www.expojo.com - yeah ok, I wrote it so I am biased slightly =]
Related
I am building a web application using JSF 2.0 tomcat 7.0.20 and a MySQL DB, My application is for a small company actully starting its business.
Now I see that there is Many implementations of JPA 2.0, now in my Case which one would be the most suitable ? or should I use pure JPA 2.0 and create my own implementation?
I want somting that would work best for the company now and wouldn't make trouble when it grows in the future, i was considering Hibernate or do you have another suggestion?
The following former questions will give you some insight about the pro and cons for each JPA implementation, and choose the one which is the best for your company.
https://stackoverflow.com/questions/2569522/hibernate-or-eclipselink
JPA 2.0 Implementations comparison : Hibernate 3.5 vs EclipseLink 2 vs OpenJPA 2
I believe that Hibernate is actually more popular nowadays, and many industries are using Hibernate.
Depends how you want to judge "most suitable" ... license? most users? fewer known bugs?. Most used doesn't necessarily mean most reliable, but then it can mean there are more people who understand its problem areas and how to avoid them. All would likely do the job for many applications, though some have long-standing issues. DataNucleus JPA is another choice for you to consider, providing for all that you need there but also allowing much more flexibility than others in terms of input and in terms of which datastores you can persist to, should these be factors in your application.
I was asked this question in an interview. My answer was as follows.
Spring makes Java/J2EE development easier, more efficient and more productive. Hibernate helps to get rid of complex and tedious data access code and reap the benefits of object oriented principles.
By blending spring with hibernate we can create scalable, robust, maintainable and database independent enterprise applications at lightning speed thus reduce time to market.
I am not satisfied with my answer as interviewer was expecting answer in business perspective and my answer was far away and has technical details.
Some of the key points I'd say is cost (it's open source, which means no licensing fees), speed of application development (turnaround time from getting an idea to having a deliverable is much shorter compared to other frameworks), portability (you can move the application to any server and it will more likely than not just work out of the box), flexibility (making changes to business logic is quick and easy), maintainability (java has been around for a long time and probably will be around for much longer, finding developers to work on the project in the future won't be that difficult as it is when using legacy code), stability (since the architecture is build upon a stable platform, downtime should not be an issue), scalability (if the userbase grows rapidly, moving to a cloud environment is straight forward, no extra cost changing the application)
If you agruee with Business Guyes you must use the terms:
cost (total cost of owner ship)
time to market
productivity
All what you said was right, but you missed the business related conclution:
"Spring, Hibernate, ... help to develop applications faster and in a very porductive style, so the time to market is reduced. On the other hand Spring and Hibernate tend the programmer to produce more maintainable and tested code. This will reduce the cost to maintain the software and provide the posibility to enhance the application at realative low cost."
spring + hibernate framework with jpa is provided a productive application. Because the framework is divided in to the layer that's why the new programmer can easily understand and can change easily in to the enterprises project. spring framework provides the dependency injection that means no need for the manually creation of object through the new key word. while spring provide the object and only programmer focus on the used of object. And hibernate is a orm framework which is fully rich in relation database. It used save/update/delete the data into the table by taking the java object only. It reduce the java code for the database connectivity and writing the sql query and much more . hibernate provide the methods for dml(data manipulation language) operations.
the Spring is the ultimate framework, and the hibernate supoort of it is just amazing,
it help a lot,
security features, helpful in TDD programing,
unit test, integration testing etc.
it is very helpful in maintaining very bulky project very easily.
today most of the heavy projects managers prefer spring with hibernate
hope it is helpful to you
thanks
I want to develop my project on Google App Engine with Struts2. For the database I have two options JPA and JDO. Will you guys please suggest me on it? Both are new for me and I need to learn them. So I will be focused on one after your replies.
Thanks.
The GAE/J google group has several posts about this very thing. I'd do a search on there and look at people's opinions. You will get a very different message to the opinions expressed above. Also focus on the fact that BigTable is not an RDBMS. Use the right tool for the job
JPA is Sun's standard for persistence, JDO is IMHO dying (actually, it's dead but still moving). In other words, JPA seems to be a better investment on the long term. So I guess I'd choose JPA if both were new to me.
Just saw this comparison between JPA and JDO by DataNucleus themselves:-
http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html
An eye-opener.
I'm a happy user of JDO. Keep up the good work guys.
People claiming JDO is dead is not without merit. Here is what I read in the book Pro EJB 3 Java Persistence API: "Shortly thereafter Sun announced that JDO would be reduced to specification maintenance mode and that the Java Persistence API would draw from both JDO and the other persistence vendors and become the single supported standard going forward.". The author Mike Keith is the co-specification leader on EJB3. Of course he is a big supporter of JPA, but I doubt he is biased enough to lie.
It is true that when the book was published, most major vendors were united behind JPA rather than JDO, even though JDO does have more advanced technical features than JPA. It is not surprising because big players in the EE world such as IBM/Oracle are also big RDBMS vendors. More customers are using RDMBS than non-RDMBS in their projects. JDO was dying until GAE gave it a big boost. It makes sense because GAE data store is not relational database. Some JPA features does not work with bigtable such as aggregation queries, Join queries, owned many-to-many relationships. BTW, GAE supports JDO 2.3 while only support JPA 1.0. I will recommend JDO if GAE is your target cloud platform.
For the record, it is Google App Engine (GAE), so we play with the Google rules not with the Oracle/Sun rules.
Under it, JPA is not suitable for GAE, it is unstable and it does not work as expected. Neither Google is willing to support it but the bare minimum.
And for other part, JDO is quite stable in GAE and it is (in some extend) well documented by Google.
However, Google does not recommend any of them.
http://code.google.com/appengine/docs/java/datastore/overview.html
Low-level API will give the best performance and GAE is all about performance.
http://gaejava.appspot.com/
For example, add 10 entity
Python :68ms
JDO :378ms
Java Native :30ms
In race between JDO vs JPA I can only agree with the datanucleus posters.
First of all, and also most importantly, the posters of datanucleus know what they are doing. They are after all developing a persistent library and are familiar with data models other than the relational, e.g. Big Table. I am sure that id a developer for hibernate were here, he would have say: "all our assumptions when building our core libraries are tightly coupled to relational model, hibernate is not optimized for GAE".
Secondly, JPA is unquestionably in more widespread use, being a part of the official Java EE stack helps a bit, but that does not necessarily mean that it is better.
In fact, JDO, if you read about it, corresponds to a higher level of abstraction than JPA. JPA is tightly coupled to the RDBMS data model.
From a programming stand point, using the JDO APIs is a much better option, because you are conceptually compromising a lot less. You can switch, theoretically to any data model of your desire, provided the provider you use supports the underlying database.
(In practice you rarely achieve such a high level of transparancy, because you will find yourself setting your primary keys on GAE's object and you will be tying yourself to a specific database provider, e.g. google). it will still be easier to migrate though.
Thirdly, you can use Hibernate, Eclipse Link, and even spring with GAE. Google seems to have made a big effort to allow you to use the frameworks you are used to building your applications on. But what people realize when they build their GAE applications as if they were running on RDBMS is that they are slow. Spring on GAE is SLOW. You can google Google IO videos on this topic to see that it is true.
Also, adhering to standards is a good sensible thing to do, in principle I applaud. On the other hand, JPA being part of the Java EE stack makes people, at times, lose their notion of options.
Realize, if you will, that Java Server Faces is also part of the Java EE stack. And it is an unbelievably tidy solution for web GUI development. But in the end, why do people, the smarter people if I may say so, deviate from this standard and use GWT instead?
In all of this, I have to sate that there is one very significant thing going for JPA. That is Guice and its convenient support for JPA. Seems that google was not as smart as usual in this point and are content, for now in not supporting JDO. I still think that they can afford it, and eventually Guice will engulf JDO as well,... or maybe not.
Go JDO. Even if you don't have experience in it, it is not hard to pick up, and you will have a new skill under your belt!
What I think is terrible about using JDO at the time of writing this is that the only implementation vendor is Datanucleus and the drawbacks of that is the lack of competition which leads to numerous issues like:
A not very detailed documentation about some aspects like extensions
You usually get sarcastic responses from the authors like (Have you checked the logs ? May be there is a reason for having them) and annoying responses like that
You don't get an answer to your question in a helpful amount of time, sometimes if you get an answer in less than 7 days, you should consider your self lucky, even here on StackOverflow
I'm always hoping for someone to start implementing the JDO specification themselves, may be then they'll offer something more and hopefully more free attention to the community and not always bothering about being paid for support, not saying that Datanucleus authors only care about commercial support, but I'm just saying.
I personally consider Datanucleus authors has no obligation whatsoever to Datanucleus itself nor it's community. They can drop the whole project at anytime and no one can judge them for it, it's their effort and their own property. But you should know what you are getting into. You see, when one of us developers look for a framework to use, you cannot punish or command the framework's author, but on the other hand, you need your work done ! If you had time to write that framework, why would you look for one in the first place ?!
On the other hand, JDO itself has some complications like objects life cycle and stuff which isn't very intuitive and common (I think).
Edit: Now I know also JPA enforces the object life cycle mechanism, so it looks like its inevitable to deal with persisted entities life cycle states if you wish to use a standard ORM API (i.e. JPA or JDO)
What I like most about JDO is the ability to work with ANY database management system without considerable effort.
GAE/J is slated to add MYSQL before the end of the year.
JPA is the way to go as it seems to be pushed as a standardized API and has recently got momentum in EJB3.0.. JDO seems to have lost the steam.
Neither!
Use Objectify, because is cheaper (use less resources) and is faster.
FYI: http://paulonjava.blogspot.mx/2010/12/tuning-google-appengine.html
Objectify is a Java data access API specifically designed for the
Google App Engine datastore. It occupies a "middle ground"; easier to
use and more transparent than JDO or JPA, but significantly more
convenient than the Low-Level API. Objectify is designed to make
novices immediately productive yet also expose the full power of the
GAE datastore.
Objectify lets you persist, retrieve, delete, and query your own typed objects.
#Entity
class Car {
#Id String vin; // Can be Long, long, or String
String color;
}
ofy().save().entity(new Car("123123", "red")).now();
Car c = ofy().load().type(Car.class).id("123123").now();
ofy().delete().entity(c);
So I have taken over a Java Web project. The application was written by another developer who now works for another company. Generally speaking, the application is straightforward, well designed and the code is documented enough. The only issue is that the previous developer decided to built his own database access library instead of using a popular framework. Over the years of his programming career he has build an impressive framework to access any database (something similar to a lightweight Hiberbate).
Now, I have no reason to throw away his code and replace the data layer with a more conventional JPA layer since the current code work just fine (although it is tempting!). But I was wondering if I should use a more conventional framework with new features. The application stack is straightforward and I could easily plug Hibernate or JPA. So old pages (with new bugfixes) would use the old framework, and the new page would use the new framework.
One of the drawback of this approach however is that it can get confusing to new developer. However, I can also continue to use the old framework, expanding/fixing it as necessary. Like I said, it works!
You certainly don't want to add frameworks at a whim, but the opposite is also bad, writing your own psuedo-framework when an acceptable alternative exists. In my job, we had to a do a conversion from JPA to a more JDBC style using Spring. During the conversion, I didn't delete or modify any of the JPA code, I simply re-wrote it in JDBC. Once I was comfortable that particular method worked, I would swap out the implementation. This allowed me to piece-meal the conversion over, without pulling the rug out from under the service layer, so to speak. So to fully answer your question, it is okay to have 2 frameworks as long as the plan is to migrate to one or the other.
Eldimo,
You should balance the decision to incorporate a new framework based on the return of investment of such change. The longevity of the current project is one way to look at it.
If the project is stable and on maintenance phase then you shouldn't make drastic changes.
But if the project will continue to incorporate new features and continue to grow, then you should consider adopting a supported framework if it increases the return of investment.If you foresee changes in the current home grow framework in order to support new requirements and if those requirements are supported by other existing frameworks, then you have a strong reason to adopt them.
However, the adoption of a new persistence framework will destabilize the current project for a short period of time, increasing the volume of bugs due to the lack of team experience with the framework and can also affect the velocity of the development team.
"it works" - don't touch!
It might be worthwhile building up a case for doing this work - performance tests, scalability investigations, etc. If you find no good reason, leave it be for projects that are currently using it. If enough bugs are raised that boil down to the DB, then there is a case there for migration to a well supported backend. If performance is low for both, then maybe raw JDBC is the way to go rather than switching abstraction frameworks.
In this case, I think the answer is "yes"....if you truly can make use of the features Hibernate or JPA possess that the legacy library does not and if you're certain you won't be breaking anything that currently exists.
By incorporating either Hibernate or JPA not only are you offloading some of the maintenance responsibility on those development teams, but it sounds like you'll be happier in terms of moving forward.
Just document all your changes and your reasoning behind them, for the sake of the developer who follows you.
If it works and is impressive, why give in to the temptation to switch to another framework for no reason? Unless the current framework has some negatives (hard to maintain, hard to understand, impossible to debug etc), I say leave it alone.
The real drawback to doing something like this is the risk that one framework will make changes to the database that the other framework will not pick up immediately. I've run into this before using a combination of NHibernate + ADO.NET: if NHibernate has cached something, it may ignore ADO.NET changes.
If you can mitigate that, there's nothing technically wrong with doing this.
I have recently heard a lot of praise for Apple's Core Data architecture.
Is there something similar in Java land, so that I can play around with Core Data's ideas (in order to evaluate how it stacks up against something like Hibernate) without having to get into Cocoa/Objective-C first?
Keep in mind that Core Data is not primarily an object persistence framework, as I understand Hibernate et al. to be. Rather, it is an object graph management framework (it maintains relationships and changed state for objects subject to the model constraints), though it is not a dependency injection framework (like Groovy or Springs). It just so happens that it can persist this object graph to disk using one of several back-end formats (including SQLite). Core Data is also not meant for multi-user systems, as was the original Enterprise Object Framework. It is meant specifically for single-user desktop applications and automates much of the work of writing a Model layer for that type of app. For anything else, it's probably not a good fit.
What are you considering Core Data for? Perhaps we can provide a more specific answer if you give us a more specific use case.
If you have a Mac, install WebObjects — which is included with Xcode — and you'll have access to the Java-based Enterprise Objects Framework.
Not at the moment - one of the reasons they moved away from the Java conversion of EOF was the complications that arose from the translation (http://en.wikipedia.org/wiki/Core_Data).
While I only know about Core Data what I have just read, it sounds like the Eclipse Modeling Framework and the Graphical Modeling Framework would do something similar, as they also provide automatic generation of a GUI from a schema, and take care of persistence of schema instances. To get relational database persistence, they could maybe be combined with EclipseLink (which is based on Oracle's TopLink), or some other ORM framework.