Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Java Data Objects

timothy posted more than 11 years ago | from the concentrate-on-the-beans dept.

Java 165

Reader java1dev submits the following brief review of O'Reilly's Java Data Objects, which he says provides excellent coverage of JDO. His capsule description of the book: "First, a high-level overview, followed by an in-depth coverage of the core features, and concluding by describing the more complex concepts in detail. Running throughout the book is an excellent intuitive example application that illustrates the features being covered." Read on for more of his review.

Craig Russell, at Sun Microsystems, is the specification lead for JDO and David Jordan, at Object Identity, has been an active member of the JDO expert group since its inception.

Java Data Objects provides a thorough coverage of JDO and explains how it can be used in various architectures. The reader is expected to be familiar with Java but needs only a limited knowledge of databases. In brief, Java Data Objects (JDO) insulates you from needing to know a lot about databases. JDO permits you to develop applications using your preferred Java object-oriented model, without you having to write code to translate between Java objects and how the data is stored in the database--JDO takes care of all of that for you.

The first three chapters provide a high level overview of JDO by walking through a small application, exploring each of its interfaces at a high level, and introducing the architectures it might be used in. Even if you have been away from code for a while you will be able to follow most of the code example. You can stop here if you just want to understand what JDO is all about and where it can be used. These are recommended reading for a manager.

Chapters 4 through 9 are required reading if you want to start developing JDO applications. They really get you into JDO, so you can understand it and start using it. The first three of these cover how to define persistent classes and fields, how they can be mapped to various databases (done for you) and the class enhancement process (which makes a lot of JDO transparent to you). The next three (chapter 7 through 9) bring home the power of JDO. These cover how to connect with a database, establish a transaction context and create, read, query, update and delete database objects. The material is made concrete by illustrating it with a detailed and intuitive example application. This example is carried throughout the book with sections of it explained as the concepts are covered.

Each remaining chapter covers a different JDO concept or feature (including optional features) that were introduced earlier but not covered in detail to keep the earlier chapters more understandable. These remaining topics are identity, lifecycle states & transitions, field management, cache management, nontransactional access and optimistic transactions. You can read these chapters as you feel the need for a more in-depth understanding of these concepts.

The last two chapters explain how to use JDO in an application-server environment and an Enterprise Java Beans environment. These two chapters assume you are already familiar with these environments, but I think a lot of it is understandable even if you are not.

There are five appendices with everything from the lifecycle state transitions to the collected source code for many of the classes used in the example application.


You can purchase Java Data Objects from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Sorry! There are no comments related to the filter you selected.

OMFG LOL FROST PISSY (-1)

Fecal Troll Matter (445929) | more than 11 years ago | (#5891767)

Java is strictly for gays.

suggestion (4, Insightful)

newsdee (629448) | more than 11 years ago | (#5891770)

Would it be possible to add the suggested retail price (MSRP) of a book in a review?
Yes, it can be found by searching the web, but it's just extra comfort brought by a small database tweak. :-)

It can be found by searching the web, duh! (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5891883)

Try a quick search on yahoo - here [yahoo.com] for example.

Hope this helps!

Re:suggestion (1)

Greyfox (87712) | more than 11 years ago | (#5891910)

Amazon no waza [amazon.com]

second post!!! (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5891773)

Seconded!!!!!!

JDO vs EJB Entity Beans? (4, Insightful)

kisrael (134664) | more than 11 years ago | (#5891782)

I've heard that JDO is much better, tighter solution to O/R mapping than EJB Entity Beans, that the latter are designed to be SO flexible that you can use them as a wrapper to your legacy mainframes, but the former is a lot closer to the problem most Java folks need to solve. Anyone know if that's a reasonable viewpoint?

(For the record, at this point I hate, hate EJBs. I think they're speficially responsible for the failure of multitudinous Java server projects, way to much overhead for 95% of all things you'd want to do in Java on the server, and the bad apple that risks spoiling the whole J2EE barrel.)

Re:JDO vs EJB Entity Beans? (1)

pmcevoy (10501) | more than 11 years ago | (#5891908)

I have to agree - its got to the point where I question _anyones_ use of EJBs - that last 5% is far too specialized.

I've started using Castor which aint quite JDO, but very close and a damn site easier than EJBs...

Re:JDO vs EJB Entity Beans? (4, Informative)

ideonode (163753) | more than 11 years ago | (#5891925)

There's an interesting thread [theserverside.com] over at TheServerSide which discusses JDO vs. Entity beans.

Re:JDO vs EJB Entity Beans? (2, Insightful)

digerata (516939) | more than 11 years ago | (#5891926)

You are right on. EJBs are very easy to miuse and generally are cumbersome to wrap around smaller projects. It looks like JDO might be a nice alternative to rolling your own persistance layer. I'd like to see a comparision between JDO and other products like Toplink.

Re:JDO vs EJB Entity Beans? (2, Interesting)

rutledjw (447990) | more than 11 years ago | (#5892049)

EJBs are very easy to miuse -

This is what I've seen being the biggest issue with Entity EJBs. Where I work, they've taken a bunch of old mainframe coders (who weren't very good there as far as I can tell), sent them to _a_ Java class, then to _an_ IDE class and turned them loose.

They all heard EJB and went wild. So the result is a bunch of junior programmers with little understanding of Java, much less J2EE writing "Enterprise Applications". Needless to say we've had some problems - performance and maintainability come to mind...

"Baby with a gun" isn't extreme enough to really describe the current situation...

Re:JDO vs EJB Entity Beans? (1)

pmz (462998) | more than 11 years ago | (#5893009)

"Baby with a gun" isn't extreme enough to really describe the current situation...

So, who gave that baby the gun? EJB is hardly at fault, here.

Re:JDO vs EJB Entity Beans? (1)

rutledjw (447990) | more than 11 years ago | (#5893955)

Ah yes, well one cannot really "type expression", things like sarcasm can easily be mis-interpreted. My point was that this is clearly the fault of the company.

However, I do feel that the overhead, complexity and hence pitfalls of ENTITY EJBs (Stateless Session beans are fine, really) made a bad situation MUCH worse

Re:JDO vs EJB Entity Beans? (0)

Anonymous Coward | more than 11 years ago | (#5893031)

Do you work at Enterprise Rent-A-Car perchance?

Toplink is becoming JDO (3, Informative)

olip (203119) | more than 11 years ago | (#5892922)

Comparing is not the best way to go.
From what I've heard, Toplink is due to implement somehow the JDO specs in a few months.
Seems they are trying to change the spec (making the "code enhancement" feature optional), since enhancement is not the way they have chosen. And since they are backed by Oracle, their voice has become louder.
Probably there will be two levels of JDO spec : level one for Toplink, level 2 corresponding to JDO as we now know it.
Anyway JDO is the thing all Java developpers have been waiting for, especially those who have tried EJBs : a well designed framework. And the transactionnal cache feature (in some products, like Lido) may lead to excellent perfs for most apps.

Re:JDO vs EJB Entity Beans? (5, Informative)

haystor (102186) | more than 11 years ago | (#5891938)

I've been using torque (from Apache, under the DB project).

One row in the db equates to one object with all the appropriate getters and setters.

I haven't been using Torque for anything too complicated, but it definitely passes the test of making the simple things simple, and area I find Java to be weak in.

For instance:
Torque.init("Torque.properties");
Empl oyee emp = new Employee();
e.setName("Dave");
e.save();

That's all there is to creating a row in the db. There are correspondingly simple operations for select, update and delete so long as you are working on one table at a time. Its a bit messier working with joins.

Its also messy and poorly documented when doing work on the select side of the statement. While "select max(emp_id) from employees" is doable, its not as simple as it could be considering how common select max() is.

Re:JDO vs EJB Entity Beans? (1)

MSBob (307239) | more than 11 years ago | (#5892711)

Its a bit messier working with joins.

That's a giveaway. If it can't deal with joins there is probably a lot more it can't deal with. Views, class hierarchies, transactions etc. I don't know torque but your example isn't enough to sell me on its simplicity.

Re:JDO vs EJB Entity Beans? (2, Insightful)

billtom (126004) | more than 11 years ago | (#5893068)

JDO and Torque are both the same sorts of tools, Object-Relational Mapping (O-RM) tools. In the Java world there are also about a few dozen other O-RM tools (Apache Jakarta hosts two different ones even). (Note, we could split hairs here. JDO is an API specification, there are several vendors implementing it.)

However, the difference between JDO and all the other ones is that JDO, for better or worse, is now the "standard" O-RM interface. Standard in the sense that it's the one Sun is promoting through the JCP. As such, it's probably the one in the long run that is going to dominate.

I'm not entirely happy about that. Like yourself, we use Torque on our projects. But we're seriously considering changing to JDO (once the JDO implementations have stabilized, and maybe wait 'til JDO 1.1). Why? Implementation independance, tools support, potential employee skills availability. All the usual reasons why one might choose a "standard" interface over a "non-standard" one.

Re:JDO vs EJB Entity Beans? (3, Insightful)

Furry Ice (136126) | more than 11 years ago | (#5891947)

I think your rant against EJB probably has more to do with entity beans than EJB in general. You can actually use JDO as the persistence layer from session beans, and that's pretty much what my company does. We wrote our own JDO-like code which works pretty well. Perhaps I'll pick this book up to see if it's worth switching, or maybe just to get some ideas to enhance our JDO-like code.

Re:JDO vs EJB Entity Beans? (1)

kisrael (134664) | more than 11 years ago | (#5892167)

Well, I've heard the official recommendation is to use stateless session beans whenever possible. And if you're in a Serverside situation (actually, getting a Swing frontend to access EJBs seems a little strange to me, but it might just be I've been in Servlet/JSP land for so long), why not just use static methods and classes to provide your service???

Re:JDO vs EJB Entity Beans? (1)

easter1916 (452058) | more than 11 years ago | (#5892984)

I don't think it's all that strange to access EJBs from Swing... perhaps the end-users demanded a UI richer than a browser-based UI.

Re:JDO vs EJB Entity Beans? (1)

kisrael (134664) | more than 11 years ago | (#5893735)

It's not really that strange, mostly just not my experience. It would make sense for a lot of applications. Though I wonder how lightweight an EJB-client can be.

Re:JDO vs EJB Entity Beans? (1)

serano (544693) | more than 11 years ago | (#5892001)

[EJBs are] the bad apple that risks spoiling the whole J2EE barrel

I thought that was Swing.

Re:JDO vs EJB Entity Beans? (1)

kisrael (134664) | more than 11 years ago | (#5892192)

My perspective is tinted by the way I've been making and using Java backends behind Servlet/JSP/Struts "frontends". Actually, Swing doesn't seem all that J2EE-ish to me.

I think Swing is more at risk of having spoiled the whole "Java on the desktop" barrel (after AWT already made it smell kinda funny...)

Re:JDO vs EJB Entity Beans? (1)

GreggBert (89663) | more than 11 years ago | (#5892788)

No. Swing is the bad apple that has spoiled the whole J2SE barrel.

Re:JDO vs EJB Entity Beans? (3, Informative)

Brian Blessed (258910) | more than 11 years ago | (#5892037)

I've heard the opposite.

Of course he's biased, but Marc Fleury (of JBoss) is very enthusiastic about CMP (Container Managed Persistence) v2.0 EJB's.
In his "Blue" Whitepaper on the subject he wrote that the CMP (Container Managed Persistence) v1.1 of EJBs was seriously lacking in various critical aspects, and goes on to say the following:

From Marc Fleury's "Why I love EJB's" [jboss.org] (PDF, page 7):

In other words, if the CMP2.0 engine s applicability goes beyond EJB alone, why couldn t we imagine a CMP engine working on abstract plain old java objects? We will look at making it the default service for persistence in JBoss. In fact I would argue that CMP2.0 is doing what JDO failed to do, providing a robust and frameworkworthy persistence engine for java (once generalized). While it was widely used in designs a year ago, JDO will probably go down in history as the proverbial chicken that crossed the road when the CMP2.0 truck came along.

- Brian

Re:JDO vs EJB Entity Beans? (4, Interesting)

awhite (179035) | more than 11 years ago | (#5892352)

While it was widely used in designs a year ago, JDO will probably go down in history as the proverbial chicken that crossed the road when the CMP2.0 truck came along.

If you read a lot of Marc Fleury's public comments carefully, it is clear that he doesn't know what JDO is. He equates JDO with Castor JDO [exolab.org] , which is a relatively simplistic persistence solution that happens to have "JDO" in its name; it is not a Java Data Objects implementation. The quote above is a perfect example: the JDO spec is barely a year old! So JDO was not widely used a year ago: Castor, however, was getting a lot of publicity around that time.

Fleury would do well to research the JDO spec, because a lot of the things he's proposing in his new vision for CMP are things that real JDO already does. JDO can persist vanilla Java classes with no code changes. Persistent fields and relations are completely transparent. Just declare a field of some other persistent type, and the relation is managed for you. Same with Collections and Maps and so forth (including collections and maps of relations to other objects). Data is lazily loaded as you access it, and change tracking is automatic. The runtime API for managing persisting objects consists of only a few classes. The query language looks just like Java boolean expressions. The whole system is elegant, but powerful. It stays out of your way. It's everything EJB is not :)

Re:JDO vs EJB Entity Beans? (2, Interesting)

ProfKyne (149971) | more than 11 years ago | (#5893776)

Is there an open source implementation of JDO?

Re:JDO vs EJB Entity Beans? (1)

pbur (88030) | more than 11 years ago | (#5892219)

The one thing I think that kills Entity Beans for me is that they don't scale very well, in their design alone.

For example: Say you have a findBy method that returns a 10000 row result set, but since it's EJB, it just returns the Primary Keys, then there's a second lookup for each of the 10000 keys to refresh the bean information. Now, take that to 100000. It really starts to get slow.

I know no one said Entity Beans are a magic bullet, but when I think of "Enterprise Applications", I think large data sets and Entity beans clearly aren't made for that.

Now, as other posters have said, I love Session Beans and use our own custom persistence to get the data in and out of the DB.

Re:JDO vs EJB Entity Beans? (2, Informative)

MSBob (307239) | more than 11 years ago | (#5892738)

1+n lookup issue that you're referring to has long been resolved in CMP2.0. Move on.

Re:JDO vs EJB Entity Beans? (0)

Anonymous Coward | more than 11 years ago | (#5893108)

Sure, we'll just stop the world and rewrite all our EJB code - no fucking thanks. It would be just as easy to throw it all away and go with JDO or another mechanism.

Re:JDO vs EJB Entity Beans? (3, Informative)

javajedi (81810) | more than 11 years ago | (#5892339)

I did a pretty extensive evaluation of both. Turned out the 2 technologies were very similar, as long as you use XDoclet with CMP Entity Beans. JDO's biggest advantage over CMP is built-in support for polymorphism and inheritance. CMP Entity Beans' biggest advantage over JDO is Container Managed Relationships. The code base for both sets of code was basically the same. JDO doesn't have declarative transactions, but I was able to simulate this using an Aspect. We ended up going with EJB, largely because it was more mature, and more good, open-source implementations existed (e.g. JBoss). There isn't even a full open-source JDO implementation yet.

We are going live with the first release of this system on Friday, and the CMP Entity Beans are working like a champ. I'm really sick of people complaining about how terrible Entity Beans are. Everyone who does is either using a crappy implementation or doesn't understand how to use them right. There is nothing "tighter" about JDO.

Re:JDO vs EJB Entity Beans? (2, Interesting)

oops (41598) | more than 11 years ago | (#5892414)

My main gripe with EJBs is that once you use them you're tied to a platform. That platform is an application server.

Using JDO (or Hibernate or other solutions) allows you to deploy your solution inside an app container, inside a web container, or simply standalone.

The biggest benefit I've seen from deploying standalone comes from unit testing (using JUnit). My most recent projects have all had sizeable sets of standalone functionality tests. Once those several hundred tests succeed in a standalone context I can then deploy into my container and perform further tests using Cactus. But the majority of testing takes place outside without any deployment grief or the extra pain of writing client/server (Cactus) tests.

Re:JDO vs EJB Entity Beans? (3, Insightful)

MSBob (307239) | more than 11 years ago | (#5892688)

EJB is simple. Really. It isn't as bad as people say. Entity beans make sense once you read the spec and understand it.

The sucky part of J2EE is deployment. If I don't have to look at another 500K deployment descriptor file I'll be a happy man. They moved so much functionality out of code into deployment descriptors that now it's more complicated to manipulate descriptors than code! We went full circle. Instead of keeping complexity in the code it has been shifted to XML i.e. the weakly typed, unchecked format that's responsible for 90% of J2EE project delays.

Kill deployment descriptors and we'll all be winners. The tools to manipulate deployment descriptors have not materialised. It's time to cut the losses and ditch that XML madness in J2EE.

Re:JDO vs EJB Entity Beans? (1)

hax4bux (209237) | more than 11 years ago | (#5892871)

Amen. This is the voice of experience. "weakly typed, unchecked format that's responsible for 90% of J2EE project delays" Oh, ya.

Re:JDO vs EJB Entity Beans? (2, Informative)

deogee (671397) | more than 11 years ago | (#5892883)

Try hibernate http://hibernate.bluemars.net.
Inheritance, composition, lazy loading, proxies. Very easy. Sun seems to treat JDO as the black sheep of the J2EE family and who knows what they'll do with it. Besides, there's no truely compliant open source implementations availible.

JDO usability (2, Informative)

elindauer (520825) | more than 11 years ago | (#5893191)

I've been working with JDO essentially since it was released, and have found it to be a very effective tool. As with any technology, it takes some time to learn, and it has areas which aren't as transparent as you'd like them to be.

I have always been the "JDO-guru" for my development team. As such, I've spent a lot of time trying to smooth out the various issues we've run into, so that other members of the team can work with this technology as transparently as possible. The main thrust of this work has been to make transaction handling easier, and to deal with PersistenceManagers. My company has been generous enough to allow me to open-source this work (which I've named "Stomp"), so if you are serious about using JDO, you may want to check it out [slashdot.org] . Even if you don't use the code here, there is a page explaining how Stomp works [sourceforge.net] which describes the motivation behind this toolkit, the problems we ran into, and how we solved them. You'll have to solve similar issues yourself if you use JDO, so this might be a good way to get a handle on what you'll face when you use JDO.

This stuff works very well for us, but of course has the risk of being non-standard. Even if you don't use Stomp, the ideas presented may help you use JDO more effectively.

PS Stomp is written to work with Kodo (from Solarmetric) but could easily be made to work with other JDO vendors. Write to me if you are interested.

Re:JDO vs EJB Entity Beans? (2, Interesting)

f00zbll (526151) | more than 11 years ago | (#5893867)

I'm no expert on JDO, but I feel EJB's have gotten a really bad PR from mis-use. I've slammed EJB's myself when lead architects think using EJB's is a good idea when the app doesn't require transactional support. The thing is, JDO and EJB can work together, though not necessarily. If you have a multi-query/transaction process, JDO will provide some level of benefit, but it won't allow you to handle the transactional aspects. Again, most people don't have these kinds of requirements, but say you have to access 4 different databases. Each database has a slightly different data model. For a transaction to be valid, all the databases must be updated.

Now with EJB's you can manage this using a standard framework and container. If you had to do this with JDO, you would need to either use it with EJB or write your own. The thing is, many architects don't understand when to use EJB's. Lead architects with the skills and technical chops know when to use EJB's. I've seen EJB's used well and use poorly. Those who use it well are programmers who understand EJB's at all levels, not just a high level over-view of what EJB's could do. One of the most common mis-uses of EJB is for simple non-transactional cache. Data that is updated weekly or monthly doesn't need EJB's and often is better off using a custom cache with specialized search/index algorithm to improve performance. This probably accounts for 50% of the apps. Without EJB's, doing transactions that require choreography would be a major pain and extremely difficult.

Most developers have only had to deal with one database and one connection. In those cases, if the connection is interrupted, the transaction isn't commited. What happens when you have to connect to several databases? and the commit threshold varies between transactions? Those situation require something like EJB's where state is maintained in memory, so that selective or full rollbacks is possible. Don't believe what MS or other marketing driods preach. Serious software development is hard and takes dedication. It's not something that can be thrown together.

gay anal sex (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5891786)

I like gay anal sex

JDO (5, Insightful)

HunkyBrewster (578901) | more than 11 years ago | (#5891810)

"In brief, Java Data Objects (JDO) insulates you from needing to know a lot about databases."

First of all, I wouldn't want to hire that developer. Secondly, that is not entirely correct. O/R frameworks are useful in that they provide a consistent interface

Re:JDO (2, Insightful)

rutledjw (447990) | more than 11 years ago | (#5892116)

First of all, I agree - on both points. However, I think a batter description of JDO is that is provides a model which logically abstracts a persistence layer. Within the model it provides a good method of implementing DB interaction along the same "thought lines" of Entity EJB function.

IMHO, the concept of encapsulating DB interactions (CRUD) in objects is a no-brainer. But the EJB implementation was out of control as far as overhead and complexity. JDO brings us back to the basics and eliminates a lot of that complexity and overhead...

Re:JDO (1)

pmz (462998) | more than 11 years ago | (#5893066)

"In brief, Java Data Objects (JDO) insulates you from needing to know a lot about databases."

First of all, I wouldn't want to hire that developer.


Agreed. The quote about JDO above is like saying VisualBasic frees programmers from needing to know, well, basically anything. It's marketing statements like this that get embedded in the minds of project managers, who, then, send a project free-wheeling into a pit of despair. I find it immensly disappointing that for each step the software industry takes forward, there is an equal step back.

Sigh, are we (society) really truly moving forward with software? I don't really mean to be cynical, but I don't know the answer to that question any more.

Re:JDO (1)

ansonyumo (210802) | more than 11 years ago | (#5893556)

That's a gross generalization. A better statement would be "JDO insulates you from needing to know a lot about database implementations". That is, your businless logic need not be concerned with which SQL dialect it needs to use depending on which RDBMS you are talking to. JDBC syntax goes a long way towards insulating you from quirky non-standard syntax, but java to SQL type mappings are a different story altogether. When you know that you are always going to deploy against a certain flavor of database, then these aren't issues. However, for those of us that don't like to tell our bosses that we can't change database vendors without a major development effort, vendor neutrality is a hot button issue.

What JDO provides is a "standardized" implementation of the abstraction that most software engineers would write to insulate business logic from persistence, rather than having JDBC code strewn throughout all layers of the application.

The GUI coder needn't know how the objects are persisted any more than the server-side coder needs to know about widgets and whatnot. Somebody on your team needs to understand SQL, because even with JDO you are going to need to delve into some sort of SQL coding to get a workable solution (e.g. DDL for the production database, specialized queries not supported by the JDO specification).

BTW my company uses TJDO [sourceforge.net] as the O/R mapper for our J2EE application. We were able to migrate from PostgreSQL to Oracle 8 in the period of a few days. YMMV, but that says a lot towards the utility of JDO and maintaining vendor neutrality.

Java Data Objects are nice but Hibernate is Better (4, Informative)

TheNarrator (200498) | more than 11 years ago | (#5891844)

I looked into JDO and was excited. Here was a much simpler alternative to EJB. In EJB there are many many things that can go wrong during deployment of beans which leads and quite a bit of replication. YOu define your object once in the bean, once in the remote interface, once in the local interface, etc. It seems to take a while to debug. JDO is better but it requires a class file enhancer. Hibernate [bluemars.net] is a lot better. There is 1 config file that defines your whole object model and it requires no special class file enhancer. That and unlike EJB it supports inheritance in object models well.

Re:Java Data Objects nice but Hibernate Better (1)

alienmole (15522) | more than 11 years ago | (#5892018)

I agree - anyone looking for a Java solution for database access that makes sense, instead of just following the latest corporate craze for cookie-cutter coding, should check out Hibernate.

Re:Java Data Objects are nice but Hibernate is Bet (3, Insightful)

mprudhom (111101) | more than 11 years ago | (#5892205)

Hibernate [bluemars.net] is a lot better. There is 1 config file that defines your whole object model and it requires no special class file enhancer.

That is precisely the problem with the majority of non-JDO persistence architectures that use standard reflection (Toplink, Hibernate, CocoBase, Castor). While people tend to get nervous about bytecode enhancement, it is just an additional step in the compilation process.

Bytecode enhancement allows JDO to perform change tracking without intruding on the application. Reading 1000 objects in a transaction and changing a single one, a reflection based framework will need to perform comparisons on each and every field of each of the instances. JDO will just need to do a single one. Reflection-based persistence frameworks are fine for "hello world" applications, or if you do not mind intruding persistence details into the application, but for true transparent and scalable persistence, JDO is the way to go.

Of course, there are many other comparison points between persistence frameworks, such as the degree to which JDO is datastore-agnostic, the number of JDO vendors vs. non-JDO vendors, the issue of JDO being based on an increasingly important standard, the lack of vendor lock-in, etc. Many of these issues are discussed on JDOcentral.com [jdocentral.com]

Cayenne Solution [Re:Java Data Objects are nice..] (1)

Andrus (671399) | more than 11 years ago | (#5893113)

While I am trying to stay away from commenting on EJB (the whole state of affairs in this area is just making me sad), among the real O/R frameworks (be it JDO-compatible or not), there are 3 major solutions:
  1. Use bytcode "enhancements" (JDO)
  2. Use reflection
  3. Use common superclass

Personally I am in favor of (3). This allows to solve a problem mentioned by the parent - tracking object changes - with as little overhead as possible, and still keep your system clean OO. This is how Cayenne O/R Framework works:

http://objectstyle.org/cayenne/ [objectstyle.org]

This allows to track changes to objects as they occur, instead of doing a blanket analysis of all objects on commit. And in general this allows a better control of objects persistence behavior by the framework. There is another (commercial) product that uses the same approach: NeXT/Apple's WebObjects [webobjects.com] . The downside of (3) is that you must have a common superclass for all your business objects, but I still have to see the case when this is undesirable.

Andrus

Disclaimer: I am personally involved with Cayenne and therefore not impartial :-)

Re:Java Data Objects are nice but Hibernate is Bet (1)

teneighty (671401) | more than 11 years ago | (#5893405)

In EJB there are many many things that can go wrong during deployment of beans ... It seems to take a while to debug.

EJB development doesn't have to be that way. I agree, without the right tools, EJB development can be a painfully laborious exercise in bitter profanity - and that's just the "hello world" EJB.

There's generally two reasons for this - firstly, there's a lot of classes to create (and more importantly maintain). This is where XDoclet [sourceforge.net] comes into its own. XDoclet is a real labour-saver and I recommend every EJB developer add this tool to their bag of tricks.

The second thing that can be painful about the EJB development process is that the edit-compile-test loop [joelonsoftware.com] can be maddeningly slow. To run your application you generally need to set up an EJB container, configure it and then ou have to package the app in an EAR and then deploy your app to the container and... you get the idea. Some vendors have integrated EJB containers with their IDEs, but they still run at the speed of diseased livestock.

There's a couple of solutons to this - the free solution is to run JBoss and deploy your app to it (JBoss's hot deploy feature is nice for this sort of thing). I am one of the developers working on a better, albeit - commercial (but fairly inexpensive) - solution, Glider [ensemble-systems.com] . The key thing about Glider is that it has an EJB container simulator so there's no separate deployment step, so you can compile and run/debug your code very quickly. Obviously, I'm biased, but I can honestly say I would use it even if I wasn't one of the developers who has worked on it.

Rob

good book, bad topic (2, Informative)

Anonymous Coward | more than 11 years ago | (#5891854)

I read this book a couple weeks ago. It's a good book (some o'reilly's are essential, some were a waste of paper and ink, and some are good). However, Java Data Objects should be avoided if possible.


I know that sounds like a harsh statement to the uninitiated. I'll admit, the idea sounds good. But the implementation is a headache and maintenance nightmare.


I've worked with Java Data Objects for 3 years now, and everyone I know who has experience with it feels the same.

Re:good book, bad topic (3, Informative)

mprudhom (111101) | more than 11 years ago | (#5892281)

I've worked with Java Data Objects for 3 years now,

FUD. The specification was released only one year ago [jcp.org] .

and everyone I know who has experience with it feels the same.

FUD. See JDOCentral.com [jdocentral.com] and TheServerSide [theserverside.com] for real-world discussions.

Re:good book, bad topic (1)

dth (17900) | more than 11 years ago | (#5892549)

Bzzzt! Thanks for coming. the spec has been around a lot longer than that. I was using Castor [exolab.org] back in early 2001.

I won't bother boring you with my experiences using it.

Re:good book, bad topic (3, Informative)

Anonymous Coward | more than 11 years ago | (#5892576)

Castor IS NOT Java Data Objects. Caster does not follow the specification for Java Data Objects.

Repeat.
Caster is NOT Java Data Objects

I'm too much of a Star Trek fan (3, Funny)

product byproduct (628318) | more than 11 years ago | (#5891887)

I read the title as "Java Android Complains".

Re:I'm too much of a Star Trek fan (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#5891928)


"I'm too much of a Star Trek fan"

Yes, yes you are. Now FUCK OFF.

Re:I'm too much of a Star Trek fan (0)

Anonymous Coward | more than 11 years ago | (#5892172)

These "ooh aren't I'm funny! I can't read" comments are quickly becoming trolls.

[OT} java1dev slashdot user? (1)

cpfeifer (20941) | more than 11 years ago | (#5891892)

according to slashdot, the user 'java1dev' doesn't exist. What does this mean?

Re:[OT} java1dev slashdot user? (0)

Anonymous Coward | more than 11 years ago | (#5892144)

You suck dicks.

Annoying book (2, Insightful)

Anonymous Coward | more than 11 years ago | (#5891903)

I read this and thought that it was very much a downer on C++. In fact the authors even go so far as to suggest that Java is simply better in all but the rarest of cases. There is also a brief mention of JDK availability and also VMs in Red Hat, but I really didn't see how this was relevant.

Java sucks ball sap! (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5891980)

Important Question (0, Offtopic)

snatchitup (466222) | more than 11 years ago | (#5892021)

Let's clear this up early.

Is it pronounced: JAY DUE

or: JAY DEE OH

Re:Important Question (1)

gkAndy (81647) | more than 11 years ago | (#5892179)

In American English, that is. Using British pronounciation, that would be pronounced like 'JAY DEU'.


A better way to describe that pronounciation would be 'JAY DOO'. But I think 'JAY DOH' is better :)

gay anal sex (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5892064)

I like gay anal sex!

Another Query Language (1, Informative)

boxhead609 (671383) | more than 11 years ago | (#5892157)

I am concerned about learning another query language. Each has its limitations and that is why I was slow to adopt EJB-QL. EJB-QL is odd to learn and still not as feature rich as pure SQL. Now there's JDO-QL... yet another query language to learn. I found that in my previous projects, it is not that bad to embed SQL into DAO objects. You have complete power and control that way. You don't have to learn another QL, and you have the benefits of SQL.

Re:Another Query Language (1)

FatherOfONe (515801) | more than 11 years ago | (#5893315)

The above post is by no means off topic! You bring up a great point. I believe in EJB session beans you can still write your own SQL. Not sure if that is what you meant by DAO objects...

In my experience every one of these "Java Architects" seem to spew the same old crap.
1. With this you don't care what DB you use.
2. Speed won't be an issue because of cacheing.

Yeah right... These are the same people that haven't written more than a 1,000 lines of code in their life.

Do I think JBO deserves a look? Yep. Do I think that I may use it for some apps? Maybe, but I have the same huge concern that you have. If I have a SQL tuning problem, I can go to about a million different resources and get help with it. With another query language I am on my own.

Well, for those who missed it (5, Interesting)

WndrBr3d (219963) | more than 11 years ago | (#5892160)

I've said it once, and i'll say it again.

These book reviews on Slashdot, at times informative, really just are letting people know about the book and not as much reviewing that.

This demonstrated is that in the last two months, no book has received less than a 80% approval rating by the author (unless you rate a 'very good' as < 8). It's like Homer Simpson is writing these reviews, "This (book) gets my lowest rating ever, seven thumbs up."

I mean honestly, a review needs to have a few lemons on its record. I think someone should review a Wrox book on Linux and have it summarized with, "This book really gobbled the cob. it wouldn't be fit to line the kitchen floor for my puppy to soil in the evenings."

Instead of calling it 'Slashdot Book Review', it should just be called 'Slashdots list of books that rule'.

That's just my opinion though, I could be wrong.

Re:Well, for those who missed it (1)

Master_Wu (266994) | more than 11 years ago | (#5892770)

It really makes the most sense to post the reviews of books that are actually good. If I'm interested in a new topic, I really don't care to read or wade through a detailed review of a book that is bad. Just give me one or two good books to start me in the right direction.

If I'm buying a car, sure list what's good and bad for my money, but if I'm looking for a book on new technology I'm into, just send me the ones people are passionate enough about to send in a glowing review.

Re:Well, for those who missed it (2, Insightful)

roalt (534265) | more than 11 years ago | (#5892797)

This demonstrated is that in the last two months, no book has received less than a 80% approval rating by the author

To have an honest book review, you should read the full book. Unfortunately, it's very difficult to fully read a book when it sucks.

So maybe this is the reason slashdot readers review only books that rule...

Alternatives (5, Informative)

tdrury (49462) | more than 11 years ago | (#5892188)

Before you commit to JDO or entity beans, do yourself a favor and also look at OJB [apache.org] and Hibernate [bluemars.net] . Both of these object-relational mapping (ORM) tools offer unintrusive presistence to your existing beans (unlike Toplink and Cocobase which require you use their collection types) and don't require you to run a byte-code mangler like JDO.

Re:Alternatives (1)

dolanh (64212) | more than 11 years ago | (#5892834)

I agree with the Hibernate suggestion. However, I'm not so sure about the collection type comment. Yes, in a sense the interface is a standard Collections interface (Set, List, etc) but the actual underlying implementation is a Hibernate data type. IIRC, this was done to allow lazy-loading of collections.

Re:Alternatives (1)

pmz (462998) | more than 11 years ago | (#5893088)

Before you commit to JDO or entity beans, do yourself a favor and also look at OJB [apache.org] and Hibernate [bluemars.net].

Okay, everyone, get it out of your system: reply, now, with the other 1,345 APIs that we should consider in addition to EJB, JDO, and, now, OJB and Hibernate. Don't be shy, now. Post!

fud again? (4, Informative)

geoff_hendrey (655157) | more than 11 years ago | (#5893426)

here we go with the FUD again. "Mangler"??? I suppose you consider javac a "mangler" or aspectj a "mangler". I think the "mangler" you refer to is the bytecode enhancer. What you forgot to mention is what the "mangler" does. Rather than scare people off, I'd like to explain the clear advantage to bytecode enhancement over reflection for dirty detection. Let's say you do a query which returns a single object. Your application then modifies a single field of the object and commits the transaction. Before commit you have to perform "dirty detection" to find out what fields have been dirtied, and need to be updated in the DB. If you don't use an enhancer you have to compare the object, field by field, with either a cached copy of the object, or worse, issue a select into the database to get the old values. The latter is particlularly bad not just for the obvious performance hit, but because it forces the table or rows to be locked for the duration of the transaction, thus making optimistic transactions impossible. Now imaging your select returned 100 objects, or 1000 objects. With an enhancer, the bytecodes for 'putfield' and 'getfield' are replaced with calls to the bvendor provided state manager. The JDO driver knows instantly what fields were dirtied, needs to keep no cached copies and never hits the database with a select before update. Furthermore, with enhancement you don't force the user to extend any classes. There is zero intrusion on the domain model. I understand that Castor, Hibernate, etc. are good open source projects, and very viable. I do, however, think that JDO is elegant and has advantages, on paper at least, over other methods.

Re:fud again? (1)

tdrury (49462) | more than 11 years ago | (#5893669)

Get a grip. Am I not allowed to complain about an aspect of a technology I don't like? Do I have to be politically correct here? And I have used aspectj and I do consider it a mangler. In my opinion its drawbacks outweights its advantages. I consider javac a "compiler".

I have use Toplink and Cocobase extensively on two very large, commercial projects. I liked Toplink and hated Cocobase. Can I call Cocobase total crap without being blamed for spreading FUD? I can provide numerous details if I need to defend myself.

I am currently using both OJB and Hibernate on a commercial product. I do not develop open-source other than submitting bugs/patches for the tools I use. Neither product requires you extend a base class, neither requires your beans know _anything_ about the persistence mechanism. In my architecture I do have a base class that all persistent objects inherit and that base class holds a handle to a generic ORMManager I wrote that abstracts both OJB and Hibernate so I can switch between the two via a single line in a property file. At the moment I prefer OJB because of its query-by-criteria API which Hibernate is supposed to be getting in the next rev.

For the record, I have no issues with JDO other than the byte code mangler. Call it an "enhancer" if you want, but then you sound like a starry-eyed zeolot as much as I sound like a dissenter. I understand some JDO implementations provide a source-code enhancer as opposed to a byte-code one - this sounds interesting and I may look at it.

I can't believe I even bothered to respond to this. Once you've used these technologies in real projects and not just "on paper", you can tell me if JDO suits you.

Re:fud again? (1)

geoff_hendrey (655157) | more than 11 years ago | (#5893810)

So which "real projects" have you used JDO in? I'd be interested in knowing how it compared to OJB. What JDO impementation did you use? Yes, feel free to call CocoBase crap, because you have actually used it. I have no problem with people criticizing when they know what they are talking about. When you say that you don't like the enhancer, it's important to provide some information on why you don't like it. Otherwise your post could be misinterpreted. One might even think you have never used JDO. The enhancement process is a major advantage of JDO's architecture, as I explained in my previous post. The implementation of JDO I used was Kodo from Solarmetric, and the reference implementation, though that is not as relevent. I have not used Cocobase or Toplink on real projects (I have experimented), which is why I did not comment on them, nor make negative references to the open source varients.

How do you .. (2, Insightful)

1337_h4x0r (643377) | more than 11 years ago | (#5892198)

Tell it which objects are mapped to which tables? And what about objects that map to multiple tables? Seems like you'd still have to have SOMEONE who knew how to do a proper database schema to set up your object structures and mappings, and make the database itself. :)

That said, this would free your developers from having to be intimately knowledgable about your database schema, which, if you have done any outsourcing, you would recognize the benefits of right away.

Re:How do you .. (0)

Anonymous Coward | more than 11 years ago | (#5893227)

JDO is basically specs an interface and some requirements (supported features) of any implementation calling itself JDO. You tell what objects are mapped to what tables 1) when you choose which JDO implementation (from a vendor or open-source project) you are gong to use (maye the answer is "none" because it's implemented on top of a real object db and 2) when you setup whatever implementation-specific configurations your JDO implementation offers. The whole point of JDO is really to factor out worrying about the database from workng with your objects on a business-logic basis.

The idea is that at any point in your project you could decide "hey, I don't like how vendor X's product is mapping my data objects to tables" and then you can switch to vendor Y's JDO product instead and not have to change any of the code that actually uses your data objects.

erm (0, Offtopic)

VAXGeek (3443) | more than 11 years ago | (#5892209)

What has happened to anonymous coward? Also, why am I being nagged about a subscription at the top of all the stories?

Re:erm (1)

snatchitup (466222) | more than 11 years ago | (#5892585)

Your sig:
a funny comment: 1 karma
an insightful comment: 1 karma
a good old-fashioned flame: priceles


My sig:
Some twit/nerd/geek that thinks he's witty, but has a mispelling in his sig: (Even better)

Re:erm (1)

VAXGeek (3443) | more than 11 years ago | (#5892651)

alas, i am from the time when slashdot sigs could be longer than however many characters they limit us to.

Just a thought (0, Redundant)

srboneidle (648298) | more than 11 years ago | (#5892271)

Is it me or do practically all the reviews posted come to the conclusion that the reviewed book was good/interesting/worth buying?

I guess it could be accounted for if the reviewers are paying for the book themselves - even if you do buy a book with the intention of reviewing it, you aren't likely to buy it if you think it isn't worthwhile. Unfortunately, while this might not always result in a biased review, it does make it harder to be negative, as well as cutting out on books that the reviewer doesn't like the look of to start with.

Still in love with Java? (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5892347)

Still earning money with Java? Still getting bankrupt with Java innovations?

Good.

Sometimes I get word about a programming language that has been there since more than 30 years now. They say it needs *SKILLS* to write code with this language. But it is said that it has proven sufficient all the time.

Re:Still in love with Java? (0, Flamebait)

giantsquidmarks (179758) | more than 11 years ago | (#5892510)

here here... ever see a shrink wrapped Java application which sells...? Ever see one on the shelves of Best Buy or Comp USA...? Ever see one that wasn't slower than molasses...?

Want to dedicate your valuable life learning a language totally controlled by Sun Microsystems...?

Java is a solution waiting for a problem... and not a very good solution at that!

Not a flame... just the truth.

Re:Still in love with Java? (1)

Anonymous Coward | more than 11 years ago | (#5892727)

Well well well, you don't see shrinkwrapped Java applications because the focus of Java in the past few years has been in the server-side arena, where in Mid-Enterprise scale businesses it dominates.

I use several Java applications on the desktop that are NOT slower than molasses, IDEA from IntelliJ would be a perfect example. Maybe not a flame, definitely not the truth, but most likely a troll

Re:Still in love with Java? (3, Interesting)

JackMonkey (631985) | more than 11 years ago | (#5893005)

"Want to dedicate your valuable life learning a language totally controlled by Sun Microsystems...?"

Ever heard of .NET? The "write in any language we give you, but it's all the same and only runs on Windows" framework. Even C++ is basically controlled by MS now.

From my experience, Java is much nicer for enterprise-level web applications than anything MS offers. As for desktop apps, it's fruitless to write desktop apps in Java when 95% of your customers are running Windows and MS has meager support for Java, at best. So you may not find Java apps on store shelves, but you don't have to look very hard to find desktop Java in the open source community.

Almost every program I run at work is Java-based and smokes the Windows-only counterparts most people use. So please don't go spouting your "truth" on something you know nothing about.

Re:Still in love with Java? (1)

ProfKyne (149971) | more than 11 years ago | (#5893841)

From my experience, Java is much nicer for enterprise-level web applications than anything MS offers. As for desktop apps, it's fruitless to write desktop apps in Java when 95% of your customers are running Windows and MS has meager support for Java, at best.

Dude, you should see Java on MacOS X. It makes Java apps running on the Windows JVM look like native code. Even the SWT libraries of Eclipse run like molasses.

Re:Still in love with Java? (1)

FortKnox (169099) | more than 11 years ago | (#5893656)

Shrink wrapped, try Weblogic, websphere, JBuilder.

Speed, try JBuilder (every C++ user complains about how horrible java is, then they code in JBuilder, and bitch again. Then you tell them JBuilder is built COMPLETELY with java, not C++, and they don't believe you).

And Java is enormous in the enterprise setting (online banking systems, etc...). It wasn't meant to be something you sell in a store. Why? Too easy to decompile. Its mostly used in internal only or backend websites.

If you truely care to argue about this (instead of a blatant troll), I'd be happy to argue back.

Hard problem... (3, Insightful)

Hard_Code (49548) | more than 11 years ago | (#5892420)

There are several Object-Relational mapping packages for Java out there. Hibernate is another one.

However, I have to say, that I have not found any complete O/R mapping package that implements everything transparently. In specific, I'm talking about recursive map structures, and "long transactions". Most of these packages are aimed towards short lived transactions on one object, or on a unidirectional tree of relationships.

I sunk absolutely OBSCENE amounts of time and effort into trying to make various packages work with a many-to-many self-recursive database structure only to realize it cannot currently be done with the packages out there. I would be glad to be proven wrong.

I would love to be able to keep a cache of a recursive map structure in memory (indefinately!) and have modifications automatically cascade the required updates to all nodes and revoke/expire any checked out nodes.

Finally I gave up trying to cache the actual structure in memory and now I just cache data, descend over the structure in the database for each request (it's not so bad, it turns out to be rather fast anyway).

Re:Hard problem... (1)

pmz (462998) | more than 11 years ago | (#5893185)

I would love to be able to keep a cache of a recursive map structure in memory (indefinately!) and have modifications automatically cascade the required updates to all nodes and revoke/expire any checked out nodes.

Haven't some of these problems already been solved in the RDBMS systems themselves? Are databases really so slow (meaning misapplied, misdesigned, and misconfigured) that all these layers upon layers upon layers of APIs and abstractions are necessary to get the job done?

Why not just two racks of computers: one rack with a database cluster, whose database vendor has solved all the data integrity issues, and one rack of apache webservers with gool ol' fashioned CGI programs? Wouldn't the raw simplicity of this configuration pay for itself? Stick a god-awful fast interconnect in there and bandwidth shouldn't be a limiting factor. I've never done this--it's just an idea.

Apple's Enterprise Object Framework (2, Informative)

Agave (2539) | more than 11 years ago | (#5892439)

Object-Relations Mapping isn't very new, even in the realm of Java. Apple, TopLink, CocoBase, have been there for years without JDO. I haven't had much time to evaluate JDO but I'd be surprised if it's as well designed or as comprehensive as Apple's Enterprise Objects Framework [apple.com] and EOModeler [apple.com] .

EOF is available with WebObjects [apple.com] which is a much easier way to build 100% Java web applications than any jsp/ejb solution.

in summary:
Object-relational mapping - good.
WebObjects/EOF - good.
JDO - undecided.

JDO, not for me (1)

pcraven (191172) | more than 11 years ago | (#5892625)

I tried putting JDO in an app I was using. Seemed pretty cool initially. The OQL through me off at first. Despite being around for a really long time (10+ years), there was little documentation on the Object Query Language.

This got me into what I thought was the biggest problem. Too much abstration. JDO ran too slow for me. And rather than making things simple, it made them more complex.

Bottom line: Object databased and query languages have been around for a long time. Few people use the, prefering the relational model. Despite the fact that Object databases are sexy. There is a reason for the fact there are few apps built this way.

Re:JDO, not for me (1)

awhite (179035) | more than 11 years ago | (#5892749)

I believe you are confusing JDO with something else. JDO does not use OQL. It has its own query language that looks exactly like Java boolean expressions. For example:

name == "John" && address.zip == 77096 && nickNames.contains ("JJ")

Also, JDO is certainly not slow. In fact, a good implementation with object caching and (if relational) prepared statement pooling and statement batching can be as fast or faster than staight JDBC.

You might be thinking of Castor JDO, which has "JDO" in its name, but is not a Java Data Objects implementation.

Re:JDO, not for me (1)

pcraven (191172) | more than 11 years ago | (#5892884)

I was thinking of Castor JDO. Thank you, you are wise.

Re:JDO, not for me (1)

Jhan (542783) | more than 11 years ago | (#5893174)

Also, JDO is certainly not slow. In fact, a good implementation with object caching and (if relational) prepared statement pooling and statement batching can be as fast or faster than straight JDBC.

Thank you ever so much for elaborating on a long standing joke of mine.

More than ten years ago I heard the first cries of "... given the complexity of current processors, modern C compilers outperform hand coded assembly in most cases.".

Then "... just-in-time compilation allows Java to be optimized further than statically compiled languages such as C".

(Missing link, anyone have a sound bite?) JDBC is faster than using SQL directly with the database.

A good object caching scheme (and statement pooling) will make JDO faster then JDBC.

So, my new JDO application is faster than a hand-coded assembler application! Yay! Only, why does it take 10 minutes to... <THUNK>

Thought Police! Circulate! There's nothing to see here!

OJB is better... (2, Informative)

JohnnyCannuk (19863) | more than 11 years ago | (#5892787)

While JDO is interesting, the Apache OJB (Object Relational Bridge) [apache.org] project is even better. It provides a JDO implementation as well as an ODMG impelemtation and a low level PersistenceBroker API. Lots of choice. More than one way to do things, allowing the developer to trade-off make trade-off when they are appropriate. It is fully transactional and supports the latest JDO as well as ODMG specs.

And it can be used to persist objects transparently...you can set it up to persist objects you already have and completely control how the object relation mapping takes place in a few config files.

We've used it on projects since November, and I don't think we'll ever go back to Entity Beans. This project allows you to choose when you would like to use byte code enhancment techniques (JDO) or reflection techniques(ODMG) or even combine the two.

Best of both worlds.

ado?? (1)

Billly Gates (198444) | more than 11 years ago | (#5893004)

Question:

Is Jdo a clone of Ado?

It seems to provide the same kind of functionality.
If sun was smart they would release newer libraries to compete with C#.net as well. You can create apps with similiar functionality like Microsofts petshop demo with 1/4th the code compared to java. Bussiness customers notice this. Especially if project deadlines are always a problem. The quicker something is done the better.

Yes (0)

Anonymous Coward | more than 11 years ago | (#5893141)

JDO is patterned after the very successful Microsoft ADO. Read the specs - every ADO function has an eerily similarly named JDO equivalent. Sun - the true innovators! (ha).

Re:ado?? (2, Informative)

f00zbll (526151) | more than 11 years ago | (#5893321)

Bussiness customers notice this. Especially if project deadlines are always a problem. The quicker something is done the better.

I'll bite. Although this statement may seem accurate it is not. Let's take for example companies that provide application services, be it insurance, financial or enterprise resource management. There's nothing wrong with hardcoding everything and removing abstraction layers all together, if the application will stay that way for 1-2 yrs. Having said that, none of the projects I've worked on had static requirements. If anything, the requirements change rapidly. Hardwiring everything in the petshop demo mean you'll have to change 50-80% of the code to support a new feature.

putting in abstraction layers increase code size right. adding comments to your code so that it is self-documenting and easy to maintain adds to the code size also. It's great model of development if your goal is to charge as much as possible and spend 80% of your time maintaining and fixing the system. It only works if you don't have competitors. If some one else take 15% more time to build the same system, but their maintenance cost is only 25%, you'll loose the battle in the long run. So the quicker something is done isn't necessarily better.

If sun was smart they would release newer libraries to compete with C#.net as well.

This statement is mis-informed. there are plenty of libraries that provide better standard compliance to XML, SCHEMA, and SOAP in Java than Microsoft. Try to do Object-relational mapping that follows standard OR techniques. What I mean by this is, take relational data and map it to an object hierarchy which reduces repetition/duplication of values. Guess what, if you use the stock VS.NET tool it only generate flat tables. This means rowsets that have similar/same columns will be duplicated. this is because ADO flattens everything and doesn't maintain OR mapping, therefore the Schema tool in VS.NET generates flat tables.

I could be wrong, but every time I've tried using VS.NET schema tool with database tables that is what it does. The only way to get around that is to build your own OR mapping and write the schema by hand using complexTypes instead of elements the way VS.NET does it.

Re:ado?? (1)

rreyelts (470154) | more than 11 years ago | (#5893887)

No - about the only thing that JDO and ADO have in commonality is the fact that they are both used to access data in a persistent store.

ADO is Microsoft's implementation of a thin veneer for querying a relational database (for example, in the same space as ODBC).

JDO is an object-oriented, vendor-neutral specification for transparent data persistence. It guarantees important levels of support for transaction management, identity management, and caching.

JDO is particularly interesting, because it achieves optimal dirty-detection and lazy loading as a transparent service - i.e. you don't have to muck with your object model to support it.

Want to know more? Download the free specification or any number of free books on JDO.

Re:ado?? (0)

Anonymous Coward | more than 11 years ago | (#5893977)

No, I don't think so ...

My understanding is that JDO attempts to address the difficulty of developing an application in OOP and then storing those objects in a relational database. No small feat. The translation can be confusing.

ADO provides objects which give access to the relational database.

this is just an advertisement (0)

Anonymous Coward | more than 11 years ago | (#5893451)

There is no java1dev user to be found on /.

This is probably just David Jordan (the author) reviewing his own work...

I don't understand why the the slashdot editors would allow a review that is so low on details to make it to the front page. I mean, this review sounds like it came straight from the book jacket.

Hibernate is a lighter, nicer implementation (1)

puppetman (131489) | more than 11 years ago | (#5893676)

Hibernate [bluemars.net]

It uses XML files to map between databases and Java. Good support for transactions, and more complicated cases.

A good overview can be found here [bluemars.net] ...
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?