If you write java to model a business application, two issues arise. The first is how you will store and read data. If you inherit legacy data, chances are they are in a relational database, and you need SQL and JDBC to get at them. The data are not usually in an object oriented layout, as you might wish. So the notorious "impedance mismatch" arises. A second issue is that business rules are often coded in EJBs, and specifically in Entity EJBs. The idea is that in a java application, the latter are objects to which you can apply OO methodology. But such EJBs are usually awkward to program, and poor performance has been reported in several development efforts.
An alternative to all this has been proposed. Java Data Objects. It defines an interface to which data can be made persistent. You access the data via the functionality of the interface. On the other side, responding to your queries, is a third party package that gives an instantiation of the interface. Vendors optimise their packages for various things, and they compete on this basis.
Roos explains the API from your standpoint. It really does seem simpler than entity EJBs, SQL and JDBC. His explanations and examples are clear. JDOs do look promising.
But there is no quantitative comparison between JDO and the alternatives. Undoubtedly a reflection of the newness. Roos quotes industry estimates that as much as 20% can be shaved off development time. Well, ok, that would be great if it is true. Be nice to have actual benchmarks. Plus also comparisons of runtime performance versus going the other route.
So if you find JDO intriguing, by all means try it. Be warned that this is cutting edge stuff. The vendor implementations are essentially first generation, compared to second generation or higher for (EJB, SQL, JDBC). There is no guarantee of reduced coding time or higher performance. Alternatively, you could wait for the second generation JDO, though if everyone does that, there will be nonesuch.