Java Data Objects

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. Java Data Objects author David Jordan & Craig Russell pages 356 publisher O'Reilly & Associates rating 9 reviewer java1dev ISBN 0596002769 summary Excellent, example-filled introduction and practical guide to Java Data Objects.

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.

Comments

suggestion

[newsdee]

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. :-)

Re:suggestion

[Greyfox]

Amazon no waza

JDO vs EJB Entity Beans?

[kisrael]

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?

[pmcevoy]

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?

[ideonode]

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

Re:JDO vs EJB Entity Beans?

[digerata]

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?

[haystor]

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?

[Furry Ice]

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?

[serano]

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

I thought that was Swing.

Re:JDO vs EJB Entity Beans?

[Brian Blessed]

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" (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?

[rutledjw]

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?

[kisrael]

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?

[kisrael]

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?

[pbur]

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?

[javajedi]

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?

[awhite]

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, 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?

[oops]

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?

[MSBob]

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?

[MSBob]

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?

[MSBob]

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

Re:JDO vs EJB Entity Beans?

[GreggBert]

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

Re:JDO vs EJB Entity Beans?

[hax4bux]

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?

[deogee]

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.

Re:JDO vs EJB Entity Beans?

[easter1916]

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?

[pmz]

"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?

[Anonymous Coward]

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

Re:JDO vs EJB Entity Beans?

[billtom]

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?

[Anonymous Coward]

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?

[kisrael]

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?

[ProfKyne]

Is there an open source implementation of JDO?

Re:JDO vs EJB Entity Beans?

[f00zbll]

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.

Re:JDO vs EJB Entity Beans?

[rutledjw]

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?

[rutledjw]

No, but I'm glad this happens at other places. For a moment I was worried my description would give my employer and hence myself away

Re:JDO vs EJB Entity Beans?

[rossifer]

JDO is a massive step up from EJB entity beans, giving you inheritance, sophisticated state behavior, fairly low overhead (especially at the object layer) and several advantages besides.

But JDO's goal, of insulating you from the database, means that you can't get to the database even if you need to. In my opinion, this limits JDO apps to the same "toy" class of applications that entity EJB's are limited to.

For instance, the way JDO stores a polymorphic reference is to store the object id and the object type (as a text string with the fully qualified class name) as two separate columns in the referrer's table. That's horrible in several ways (including db bloat and the fact that you've lost most of the ability to report against the database), but because the JDO spec refuses to let you give it any hints, it has very few other options. This particular problem made JDO infeasable for the last app I worked on (a security manager that pulled in 30-50 million snort events per day). JDO would have doubled the database size, on a database that grew at 2-3GB/day!

Other solutions, like Hibernate or OJB give you the ability to ignore the database if you so wish (by providing schema generating tools) but also give you the option of writing a great object model, writing a performant database schema, and then describing the best possible mapping between them. And believe me, when it comes time to make your application scalable to hundreds of simultaneous users and hundreds of millions of rows, you'll appreciate the ability to design the database yourself.

JDO's real problem is that it pretends that there's no need for relational programming now that we've got object oriented programming and it's another restatement of the object-oriented database. Relational programming has several distinct advantages over OO programming in several problem areas, the most obvious being arbitrary search (which the OO model intentionally prevents with encapsulation). True object relational mapping tools don't make this mistake. They let the object model do what it's good at, the data model do what it's good at, and then help them talk to each other.

One thing that JDO did do a good job of was the application interface. The query is nice and the rest of the semantics are clean. And luckily for the rest of the world, there's no reason why an ORM tool can't provide a JDO interface but do the mapping more intelligently. In all actuality, this is what will happen to JDO very shortly (if it already hasn't). The vendors will provide systems that comply with the spec and then customers will demand that they have more control over the db and mapping and each vendor will extend their implementation in some nonstandard way to give them that power.

Regards,
Ross

Re:JDO vs EJB Entity Beans?

[rossifer]

Sorry to reply to my own post, but the super killer that JDO doesn't manage and falls flat on is the update problem.

Sometimes called "object evolution", "schema evolution", "schema upgrade", or a few other names, this is the problem you have when your objects (and therefore your schema) change from V1.0 to V1.1. Your customers will expect the upgrade to happen and the app to keep running, but a schema change will require that you do db manipulations to preserve their data across changing columns and tables.

JDO gives you no help in solving this problem, and because it "helped you out" by keeping you away from the schema in the first place, you're in a worse position than you would be if you had written both versions of the schema. At least then you'd be able to know exactly what you changed and why. With JDO, you get the exciting and error prone task of reverse engineering what JDO helped you out with and hoping that you don't misunderstand something that corrupts your customer's data.

Hiding the relational model doesn't help you at all and ends up biting you in the ass. As I mentioned in my previous posting, most vendors will quickly find that their customers need direct control over the database as well as the object model and "spec JDO" will only be used for toy and one-off applications.

Regards,
Ross

Re:JDO vs EJB Entity Beans?

[Mindbridge]

Here is a one that is under Apache license: TJDO

And this one is free for non-commercial use: Libelis

Also, there are a number of open source implementations that are "in-progress" -- Apache's Object Relational Bridge, etc.

This is one thing about Java that OSS advocates should appreciate -- open specs, multiple implementations. Standardising less than 10% of your APIs without commitment to allow competing implementations to the rest of the platform is simply showmanship.

Re:JDO vs EJB Entity Beans?

[awhite]

Actually most relational JDO implementations already let you bypass the JDO layer and deal with SQL when you want to, and let you map classes to an existing schema (or even generate classes and O/R mapping data from an existing schema). At least, I know you can do all this with Kodo JDO. If you haven't checked out JDO lately, I'd say you should give it another shot. Keep in mind that the spec is barely a year old... implementations are adding features very rapidly.

Re:JDO vs EJB Entity Beans?

[pbur]

Yeah, that's great for CMP 2.0, but our design requires BMP...seeing as how CMP can't switch DBs based on criteria, which our app does.

And how exactly has CMP 2.0 managed to get passed 1+n? Please, do tell.

Re:JDO vs EJB Entity Beans?

[rossifer]

That's what I figured would happen. But what I don't get is why being able to ignore the db is touted as one of the advantages of JDO. It's a serious problem in the spec which leaves you tied to the vendor-specific extensions.

By leaving the gap in the specification, they prevent someone who's using JDO from easily swapping vendors. At that point, I still say that the application interface is nice, but I'll take an approach that blew off the cruft the first time around and did it the right way from the start.

Regards,
Ross

Re:JDO vs EJB Entity Beans?

[awhite]

But what I don't get is why being able to ignore the db is touted as one of the advantages of JDO.

Because 99% of the time you can ignore the DB. And because JDO retains its API regardless of the back-end data store. You can use JDO on top of relational DBs, flat files, Object DBs, etc.

By leaving the gap in the specification, they prevent someone who's using JDO from easily swapping vendors. At that point, I still say that the application interface is nice, but I'll take an approach that blew off the cruft the first time around and did it the right way from the start.

What approach? JDO is the standard. The only other options are certain vendor's products. I'd rather write to JDO + vendor extensions and then be able to port to different JDO vendors and even different data stores just by re-doing the parts that needed vendor-specific support... than to code my whole project to some non-standard API! Then you have no ability to switch at all!

Re:JDO vs EJB Entity Beans?

[Anonymous Coward]

Yeah, that's great for CMP 2.0, but our design requires BMP...seeing as how CMP can't switch DBs based on criteria, which our app does.

Deploy your CMP entity per DB, and build a session facade (well, you already have one, don't you?)

And how exactly has CMP 2.0 managed to get passed 1+n? Please, do tell.

Any serious implementation includes read-ahead strategies for finding and loading entities.

Re:JDO vs EJB Entity Beans?

[Anonymous Coward]

Migrating from CMP 1.1 to 2.0 is not a big deal. Make your bean implementation class abstract (most people were doing this already long before CMP 2.0 spec came out -- at least those who knew what they were doing...) and add abstract accessors in place of your public fields. Add couple elements to your deployment descriptors and you're done.

Pretty easy.

Re:JDO vs EJB Entity Beans?

[Anonymous Coward]

And how exactly has CMP 2.0 managed to get passed 1+n? Please, do tell.

Any serious implementation includes read-ahead strategies for finding and loading entities.

And this, BTW, is the reason why CMP rocks over BMP -- unless you plan hand-coding all that caching into your BMP implementations.

Using BMP is pointless -- you end up writing all that SQL code for what? You might just as well execute it from a SLSB.

Re:JDO vs EJB Entity Beans?

[Trinition]

A. There is nothing stopping a container from using JDO as its persistence implementation EJB Entity Beands.

B. Entity beans also offer security, transactions and remoteness. None of that you get inherently with JDO.

Re:JDO vs EJB Entity Beans?

[grommet_tdi]

Kill deployment descriptors and we'll all be winners.

Better yet, fully utilize that database your company paid so much money for and implement your transactional code in stored procedures. Deploying patches are as easy as recompiling a procedure, and you'll support almost any client written in almost any language.

Re:JDO vs EJB Entity Beans?

[rossifer]

Because 99% of the time you can ignore the DB.

I'd put that number closer to 20%. Personally, I've never developed an app where I could ignore the app after the "dog and pony" prototype had served it's purpose. Don't get me wrong, I know there's a place in the world for Perl, so I know there's a place in the world for small database-aware Java systems that don't deal with a lot of data and rarely if ever change the schema.

But I've never developed one of them. Every time I've needed a persisted store in one of my projects, I've had high concurrency demands, a need to scale to deployments as large as a branch of the US Military, or a Fortune 100 company, or... and there's never a simple query requirement. It's always some path following, weighted edge graph evaluation model that can be done in the object model if you've got big enough iron, or in a fairly small database if you've got the relational programming skills. And I don't notice anyone correcting my observation about schema evolution (though I was hoping that someone would and I would learn something new). If you haven't had to push a schema change down against a 100GB database with a backup that takes three days to finish restoration (in case you screwed up), you haven't lived.

What approach? JDO is the standard. The only other options are certain vendor's products.

Three comments:

1) The great thing about standards is that there are so many to choose from. (blatantly stolen, I know :)

2) JDO is a standard, not the standard. Besides all of the vendors aiming for defacto standard status, ODMG has had an ORM standard too. Been around for a few years, actually. The OJB project already fully implemented it in Java and OJB works pretty darned well.

3) JDO isn't a very mature standard. More of an experimental effort at this point. I see JDO as Sun's first pass at fixing JDBC's big problems. As an architect/developer who's been around the ORM block a few times, this first pass has some nice contributions to the ORM space (and don't think they haven't noticed), but got stuck in the OO-limited perspective.

The sooner Sun drops the "JDO let's you ignore the database and do the neat stuff!", the sooner they'll be on the right track to the right balance. JDBC was too far the other way, but I'm confident they'll get it right one of these days. After trying everything else :)

Regards,
Ross

Re:JDO vs EJB Entity Beans?

[Anonymous Coward]

Not necessarily better. There's no going back from middleware and application server -- application logic that lies on the server side in an n-tier architecture.

Applications like these suffer the most whenever serialization is involved, having to marshal and unmarshal state between in memory to network. Meaning you want to optimize this. Using stored procedures (essentially putting application logic at DB level) forces you to hit that DB every time -- no caching, secondary step of serialization between the app server and the DB. Not a good solution.

I can live without tx logic at the DB. I find it hard to live in a 2-tier architecture anymore though. Meaning I want to minimize the amount of CPU cycles spent on serialization and the only way of doing that is caching at the app server level; minimizing the traffic between the app server and DB.

Stored procedures with tx logic at the DB server goes against this. You either increase the amount of CPU cycles spent on a useless serialization process or you go back to 2-tier architecture.

Both are bad solutions as neither scales particularly well. Going with stored procedures is the quickest way to legacy maintenance hell.

Re:JDO vs EJB Entity Beans?

[canuckistani]

I spent the last year working on a project that used Torque as its persistence layer. It's OK when you've got a basic one object = one table model. (You can also map an object to a view.) It's fairly easy and fairly flexible, within a paradigm that assumes one table per class.

The mechanics of using Torque are that you define your objects using an XML schema from which it generates both code and SQL CREATE TABLE statements using ant tasks. It uses another Jakarta project (the Velocity template engine) for code generation.

Torque generates five classes. Three are basically internal and shouldn't be messed with. Of these, one is a helper class, one is a base class for the object, and one is a base for the table. (If you will, one class represents rows of the table and one represents the table itself.) The classes you actually use are subclasses of this, and are basically empty stubs to which you can add code. Torque is smart about not overwriting these if they already exist.

You can alter the base classes by changing the Velocity templates or by providing a class that the generated code extends. (This class must extend Torque's BaseObject class.) ISTR that it also supports tables that extend other tables, but we never needed to explore that.

Oh, it also provides its own connection pooling. This could be a problem if you're wanting to make use of application-server supplied transaction management (e.g. for managing distributed transactions.) We did prototype an interface to make it use XA transactions acquired from JBOSS, which worked in unit testing, but was never used in production because we didn't need the functionality.

My only serious caveats with Torque are that (a) it doesn't support SQL aggregate functions (min, max, sum, etc.), (b) it feels like it's designed for a fairly simplistic model where one web page equals one screen, and (c) the documention is a bit skimpy in places. Good for getting started but less helpful on the meaty problems. Not supporting aggregates is a nuisance; we had to drop down to JDBC for those (which Torque allows; just make sure you return the connection to the pool instead of closing it!) The one page = one screen paradigm was less of an issue, more just a sense of what it was originally designed for.

It also relies on a number of other Jakarta projects, which may be a problem in initially configuring it. We were using Turbine and some others, so I'm not sure just what would be involved in using it outside that context.

The other major caveat is that it has no caching, so if you fetch the same object twice you'll end up with two copies which is potentially a problem in a multi-threaded environment. However, this something you might expect to pay big bucks for. As a free product that provides a good and easily-maintained alternative to hand-rolling your JDBC interfaces, Torque is a pretty good solution.

See http://db.apache.org/torque

JDO

[HunkyBrewster]

"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

[rutledjw]

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

[pmz]

"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

[ansonyumo]

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 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.

Re:JDO

[Tablizer]

"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

Databases can be a great tool. Many Java developers want to use the database ONLY for persistence, but databases provide many other services such as querying, multi-user concurrency management, auto-backups, and so forth. If you use it as mere persistence, then you end up re-inventing a lot of DB-like features in your apps, like indexes (arrays of object links), finds, joins, semaphores, etc.

Most OO-R mapping tools require you to "dumb down" your usage of the DB.

Don't isolate yourself from RDBMS, use them to their full potential to save you time and money. Make your "noun model" dynamic and virtual instead of hard-coding it into entity classes.

Re:JDO

[Anonymous Coward]

We were able to migrate from PostgreSQL to Oracle 8 in the period of a few days.

How large is your database? In my experience, just migrating a production database itself from PostgresSQL to Oracle (let alone any code changes) for a serious enterprise application takes more than "a few days."

Re:JDO

[studerby]

Nice to hear that someone else is basing their business on TJDO (my company puts the the "T" in TJDO, though the bulk of active development is now coming from outside the co.)

Your remark about "JDO insulates..." is spot-on; JDO isn't a panacea, by any means. It uses some resources that a hand-coded approach wouldn't, and naive programmers can tie a program in knots with bottlenecks or even resource deadlocks if they're sufficiently "inventive". However, being able to run the same code base against Oracle 8 or MySQL is worth a little cost, and the "inventive" programmer can screw things up in any language. It does seem to make persistence more mundane, freeing developer time for more work on business/feature logic.

Java Data Objects are nice but Hibernate is Better

[TheNarrator]

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 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.

good book, bad topic

[Anonymous Coward]

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

[mprudhom]

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

FUD. The specification was released only one year ago.

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

FUD. See JDOCentral.com and TheServerSide for real-world discussions.

Re:good book, bad topic

[dth]

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

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

Re:good book, bad topic

[Anonymous Coward]

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

Repeat.
Caster is NOT Java Data Objects

Re:good book, bad topic

[Anonymous Coward]

I believe Castor originally implemented a fuzzy ODMG (Object Database Management Group) Java binding. The ODMG spec was later dumped by the Java community for what is now JDO. Correct... Castor is not JDO.

I'm too much of a Star Trek fan

[product byproduct]

I read the title as "Java Android Complains".

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

[Anonymous Coward]

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

[OT} java1dev slashdot user?

[cpfeifer]

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

Re:[OT} java1dev slashdot user?

[Anonymous Coward]

You suck dicks.

Annoying book

[Anonymous Coward]

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.

Re:Annoying book

[radish]

So that's one more plus point for this book. Your point being? ;-)

Re:Annoying book

[Anonymous Coward]

Please explain how Slashdot and it's affiliates could accept advertising dollars on a show about exploitation of teens and not also be guilty of the same thing they accuse these web sites of. It would appear that this single show earned more money than any of these girls could ever hope for modeling on the internet. No story like this should be done for income or profit if the true reason is to prevent such things from being done. Or if you honestly want to practice what you preach, at least make a disclaimer at the beginning of the show stating your intention to either donate the procedes of the show to these girls or to organizations who can help stop these girls from putting themselves at risk in this way. It may have also harmed in a way because of those who may get the idea to do the same thing. Setting up a way to prevent this or a better way for the girls to get legitimate modeling exposure would help but finger pointing only creates monsters and enemies in peoples minds. It doesn't change things to just call people names or tell parents how dumb they are if you aren't going to help them out.

Re:Java Data Objects nice but Hibernate Better

[alienmole]

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.

Important Question

[snatchitup]

Let's clear this up early.

Is it pronounced: JAY DUE

or: JAY DEE OH

Re:Important Question

[gkAndy]

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 :)

Another Query Language

[boxhead609]

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

[FatherOfONe]

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

[WndrBr3d]

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

[Master_Wu]

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

[roalt]

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

[tdrury]

Before you commit to JDO or entity beans, do yourself a favor and also look at OJB and Hibernate. 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

[dolanh]

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

[pmz]

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!

Re:Alternatives

[pierreg0]

OJB now claims to be "A JDO compliant API", which is achieved through using Sun's Reference Implementation as a plugin. If you look at their tutorial, they do use a bytecode enhancer for this. They also still have an ODMG 3.0 compliant API, which does not require enhancement, however.

Re:Alternatives

[psykocrime]

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!

Just do it with the database vendor's db specific interface API.. CLI for DB2, for example.

Better yet, just use low-level ODBC calls.

Or, better yet, do it in ADO, or DAO or OLE-DB ,or whateverthehellmicrosoftiscallingitthismonth, and write a JNI wrapper around it for Java....

How do you ..

[1337_h4x0r]

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 ..

[Anonymous Coward]

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.

Re:How do you ..

[grommet_tdi]

That said, this would free your developers from having to be intimately knowledgable about your database schema

Why are people so quick to shield developers from knowing the database? The data *is* your application, presentation/application tier technologies come and go. Developers all too often treat databases as bit buckets, and 9 times of out 10 those their applications are not scabable, perform like dogshit, don't support a wide variety of presentation technologies, and have to be refactored every few years to accomidate the J2EE tech de-jour. No thank you.

Re:Java Data Objects are nice but Hibernate is Bet

[mprudhom]

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

erm

[VAXGeek]

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

Re:erm

[snatchitup]

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

[VAXGeek]

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

Re:erm

[jjgm]

That would be the old-fashioned part; "misspelling" being misspelled.

Just a thought

[srboneidle]

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.

Hard problem...

[Hard_Code]

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...

[pmz]

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.

Re:Hard problem...

[Hard_Code]

Like I said, the performance wasn't all that bad anyway. Object-Relational Mapping does not (typically) solve a performance problem, it solves the impedence mismatch between Object Oriented Programming (the way most anything important is written these days) and relational databases and their declarative[ish] languages like SQL.

I also had the good fortune that the application I was writing had VERY little data, so the iteration was very fast, even when hitting the db each time, and was 99.999% read-only (and my final write solution was "blow away the cache entirely and don't even bother with integrity").

Re:Hard problem...

[alienmole]

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?

The goal is to make life easier and more productive for developers, and to handle more complex systems with less code, less repetition, and just generally better-engineered solutions.

Database languages, i.e. the vendor-specific varieties of SQL such as Oracle's PL/SQL, suffer from a number of problems. For a start, they're proprietary, non-standard, vendor-specific languages. Most database users are seriously tied to their database - in most cases, it would be easier to switch server OS than switch databases.

In addition, database languages are not very good programming languages. They've evolved from SQL to become poor, legacy-ridden general-purpose languages which suffer from most of the spaghetti-code problems which languages like Java were designed to alleviate. Not that Java is the most wonderful language ever, but it's a lot better than PL/SQL or TSQL for many tasks.

So, one major goal for these mapping and abstraction layers is to allow a more robust programming language to be used, to provide better functionality and reduce or eliminate dependency on specific databases.

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?

This can work fine for some applications, when the database design requirements are fairly straightforward. It doesn't scale well to more complex applications. Also, even if you're not writing incredibly complex applications, a good mapping layer can still simplify things, reduce the amount of code you have to write, and give you greater flexibility.

Re:Hard problem...

[pmz]

The goal is to make life easier and more productive for developers, and to handle more complex systems with less code, less repetition, and just generally better-engineered solutions.

Has this actually occurred in practice? I have yet to see it. The explosion in the number of APIs with these goals has arguably made the developer's job much much harder, where the learning curve leading to informed decision making is becoming impassable. Specialization of jobs is not improved from before, where the "Oracle developer" is replaced with a "J2EE developer" or, worse, an "EJB developer". And, now, there needs to be both the "Oracle developer" and the "J2EE developer", because both systems are so complex that one person can hardly do both jobs competently. Using something like J2EE or .NET hardly relieves the project of needing its database-specific expertise.

Net reduction in complexity: nil. All we have accomplished is sweeping the pile of complexity to the other side of the room and adding new staff to document where the pile went.

Most database users are seriously tied to their database - in most cases, it would be easier to switch server OS than switch databases.

Similarly, most (insert API name) users are seriously tied to their (insert API name). Again, in most cases it would be easier to switch the server OS than switch (insert API name). Additionally, the lock-in is now not only database-specific but application-server-specific, as well, because I have yet to see an abstraction layer so well concieved that the database doesn't leak through.

So, one major goal for these mapping and abstraction layers is to allow a more robust programming language to be used, to provide better functionality and reduce or eliminate dependency on specific databases.

But they add literally millions of lines of code that is opaque to its users, tens of thousands of nuances, and hundreds of new things to learn. How can this be called progress, when complexity is actually going up rather than down?

I really think the software industry needs to step back and take a breath.

Re:Hard problem...

[Aapje]

Have you tried EOF (part of WebObjects)? It uses an extensive caching structure and cascades modifications. It's not completely transparent though, but I doubt that any package can provide that given the complexities of such a solution. This explains how to extract EOF for use in a pure Java app.

Re:Hard problem...

[erlorad]

Try EJB CMRs. Specifically, I know Weblogic has some very interesting caching capabilities.

Re:Hard problem...

[alienmole]

I really think the software industry needs to step back and take a breath.

I think it needs more than that. Where my perspective is coming from, though, is getting work done within the confines of the current software industry.

Has this actually occurred in practice? I have yet to see it.

I've seen it in some systems, and I try to develop systems like that. However, it doesn't happen automatically, by any means. A big aspect is being sensible about choice of tools. E.g., the obvious one that most people know: avoid EJBs.

Similarly, most (insert API name) users are seriously tied to their (insert API name).

Yes, but there's a difference. If you imagine an ideal system, it would involve an application written in code which relies on an abstraction boundary that's very close to the needs of the application. Put simply, SQL does not provide such an abstraction - too low-level - whereas writing code that uses objects that are transparently persisted, can.

But using an object persistence mechanism, your code is going to be dependent on that mechanism, as you say. Given that, it's important to make sure that the API you depend on is at least to some extent, under your control. One way to do that is by using an open source framework. Yes, your code will become dependent on that framework, but you have more control over the code you're dependent on, and you won't be writing large amounts of code in a poorly-designed proprietary language over which you have no control whatsoever.

But they add literally millions of lines of code that is opaque to its users, tens of thousands of nuances, and hundreds of new things to learn. How can this be called progress, when complexity is actually going up rather than down?

That's where choice of tools comes in. Avoid overly complex systems, and use open source frameworks. Two systems that I've been working with are Resin (as the application server) and Hibernate, for transparent persistence. The codebases of both don't add up to a million lines, and both are well-conceived and well-written. Code doesn't have to be dependent on Resin unless you particularly want it to, because it's a standards-compliant Java application server - a commodity item, essentially. Code will certainly become dependent on a tool like Hibernate, though. So let's examine that.

Before I began using Hibernate, I worked on and used a number of home-grown persistence frameworks (developed by clients of mine, in some cases with my assistance) of varying degrees of sophistication. Why do companies develop such frameworks, since they're only going to suffer from the issues you mention, of complexity etc? The answer is that the need arises from the kind of code you end up writing without them - for example, you get repetition, which creates maintenance problems, and you want to factor that repetition out. So it's pretty natural for even many naive projects to end up with something that qualifies as a persistence framework, even if only an unsophisticated, simple one. These libraries tend to make life easier for the projects that rely on them, but they tended to be one-off efforts which had many shortcomings.

For companies using such frameworks, switching to a comprehensive open source solution is a no-brainer - it provides better functionality all around, has a larger developer base, and the source is still available for customization, tuning etc. if neccessary.

In this area, a big reason the problems you're concerned about exist is because we rely on databases which impose severe restrictions on the kind of code that can be run "within" the database, but running "outside" the database entails a huge semantic gap between the client language and the database. Middleware such as persistence mechanisms are a fix designed to bridge this gap. Do they add to total complexity? Sure. But they also reduce complexity in some important areas.

Besides, what's th

Apple's Enterprise Object Framework

[Agave]

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 and EOModeler.

EOF is available with WebObjects 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.

Re:Still in love with Java?

[giantsquidmarks]

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.

JDO, not for me

[pcraven]

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

[awhite]

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

[pcraven]

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

Re:JDO, not for me

[Jhan]

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!

Re:JDO, not for me

[Hard_Code]

I dunno, maybe because software does so much more today? Are you really suggesting writing database-backed applications in assembler?

Re:Still in love with Java?

[Anonymous Coward]

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

OJB is better...

[JohnnyCannuk]

While JDO is interesting, the Apache OJB (Object Relational Bridge) 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.

Toplink is becoming JDO

[olip]

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.

ado??

[Billly Gates]

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.

Re:ado??

[f00zbll]

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??

[rreyelts]

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??

[Anonymous Coward]

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.

Re:ado??

[sheldon]

You've confused ADO with OleDB.

OleDB is the data access technology. ADO is the object-oriented, vendor-neutral specification for transparent data persistence. It guarantees important levels of support for transaction management, identity management, and caching.

Sounds like JDO.

Re:ado??

[Anonymous Coward]

Actually since dot net supports 26 languages and counting it would be only proper to included them all in the tally. You see if you do Java that's all you do. Where as if you do Dot net you are language independent. Foxpro, AIDA, COBAL, Pascal, Python on and on the list goes. So pretty much anybody can Dot Net. While only a few can JAVA. And it is only the beginning. Lets face it MS first real Enterprise OS was 2000 and it is now only 2003. So you can see that Java has had some time in the market. And That's okay because it take awhile for the market to catch on. And really it is all about time in the end. Programmers that already have a language just want to go home not study a new one. Visual Studio Dot Net gives them that option. Why because they just use what they know and still do what the JAVA guy is doing. One box one set of tools and pick your poison. Need something that is not in the box go to a third party vendor buy the tool kit. Let see can third parties extend Java? Lets say I wanted to use some of the built in APIs in windows so I do not have to spend a whole bunch of my time writing custom msgbox routines. Can I do that? Last time I looked Sun was sending mixed signals suing one company and threatening others. So can you extend Java without Sun being involved. The dot net environment let's you. And that really is the point. Sun is the owner of JAVA and they control it. Since it has been in the market place for so long right now should be the time for it to shine. But look. Is it? Remember Novell was going to rebuild Netware from the ground up using Java. Well? How about Oracle they too were going to do the same thing. Still waiting.

Re:ado??

[f00zbll]

How about Oracle they too were going to do the same thing. Still waiting

I believe this statement is mis-informed. In fact most of the response is mis-informed from an enterprise application perspective. I'm not talking about office productivity here. Back end enterprise applications that run 24/hrs a day with less than 2-4 hours down time a year. When java first came out, Oracle promised tight integration. They never said they would write Oracle with java. The first release of oracle 8i did have java tightly integrated. In fact, java runs at the same level as sql. Not only that, Oracle provided java triggers, so that triggers could be written in sql or java. The benefit of that is you can then hook traditional triggers to Java, which can then send messages to a messaging system like IBM messaging server.

Does MS SQL server have that kind of integration with .NET and C#? Right now, the only thing SQL Server 2K has is SQL SERVER notification, which uses COM+. I don't know if SQL SERVER 64bit is any different, but I doubt it. I could be wrong.

Actually since dot net supports 26 languages and counting it would be only proper to included them all in the tally. You see if you do Java that's all you do.

The whole argument about multi-language support doesn't hold water. There are certain classes of applications which are not well suited AIDA, COBAL or Foxpro. Not because the language is bad, but because it would require too much effort to hack a system to use 8 different languages. If you've ever tried to do cross language development, you'll know that having a way to use a library written in another language is just the tip of the ice berg. I'm not suggesting a person should avoid C# or .NET. On the contrary, if you can use an existing library written with foxpro, go ahead. But if the application has out grown foxpro, then you're better off using stock ADO.net with SQL Server. Or better yet, use something that meets the same functional requirements. Again, when you're talking about enterprise applications, most of the heavy stuff comes with mature Java support natively. The same isn't true of .NET right now. It will mature obviously over the next 10 yrs. Using libraries written in other languages isn't as simple as "recompile with .NET". Say for example you're using an existing C module that forks a new process, instead of threads. How much work is required to rework that piece? Again, not a simple task.

From what I've seen first hand. Being able to hook into a component written in another language is just the beginning. In many cases, you're better off wrapping those pieces, or rewriting it. Nothing is ever as simple as marketing slogans. There are entire class of applications that really should sit on the mainframe using the original COBOL code base. The argument of multi-language support is a moot point and doesn't accurately describe the complexity of integrating legacy code written in other languages. No one in their right mind would recompile a COBOL application for .NET. Writing a webservice for it and then hooking it to other .NET webservices makes sense. I don't know if a COBOL .NET compiler really exists or not, but recompiling a COBOL backend app to .NET is a dangerous and stupid idea.

Re:ado??

[rreyelts]

No, I'm sorry, you're the one who is confused. ADO isn't object-oriented in any sense of the word. It is also not vendor-neutral. It also does not make the same level of guarantees that JDO makes. Perhaps if you actually wrote some code using JDO you might begin to understand the differences?

Re:ado??

[sheldon]

Ahh perhaps if you actually wrote some code using ADO you might begin to understand the differences.

Re:ado??

[rreyelts]

Lol. I've written both my fair share of Java and C++ on the Microsoft platform (including ActiveX and ADO). And that, my friend, is why I know better - and you apparently don't.

Re:Still in love with Java?

[JackMonkey]

"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.

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

[Andrus]

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/

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. 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:Still in love with Java?

[multi io]

ever see a shrink wrapped Java application which sells...?

http://www.allianceonline.jp/productimgall/weblogi c.jpg

Yes

[Anonymous Coward]

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:Yes

[ChannelX]

ADO and JDO are nothing alike. Read the specs.

JDO usability

[elindauer]

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. Even if you don't use the code here, there is a page explaining how Stomp works 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:Java Data Objects are nice but Hibernate is Bet

[teneighty]

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 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 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. 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

fud again?

[geoff_hendrey]

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?

[tdrury]

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?

[geoff_hendrey]

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.

Re:fud again?

[plinskey]

> For the record, I have no issues with JDO other than the byte code mangler.

For the record, there is nothing about the JDO spec that requires a bytecode [mangler|enhancer]. There is even a free source-code enhancer available, bundled with Sun's reference implementation.

The JDO spec is written such that any compliant implementation can work with any class that implements javax.jdo.spi.PersistenceCapable. One route to making your class implement this interface is to post-process (relative to initial compilation) the bytecodes with a tool. Another is to pre-processthe source code with a tool. A third is to manually implement the PersistenceCapable interface. Further ways to implement this interface are left as an exercise for the reader.

(Most vendors do not ship with a source-code enhancer, as Sun has already written one. However, due to licensing restrictions on the reference implementation, it is not legal for a vendor to ship with Sun's RI. This does not prevent you from using it, etc. etc. etc.)

-Patrick

Re:fud again?

[geoff_hendrey]

I would listen to Patrick ... I think he might have some experience with JDO ;)

this is just an advertisement

[Anonymous Coward]

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.

Re:Still in love with Java?

[FortKnox]

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.

Hibernate is a lighter, nicer implementation

[puppetman]

Hibernate

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...

Re:Still in love with Java?

[ProfKyne]

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.

Why buy it?

[oniony]

When you can wait 14 years and get it for free?

Re:Java Data Objects are nice but Hibernate is Bet

[Julian Morrison]

The real solution is to use (1) ant (2) jboss. Ant can run thru all the steps from rebuild to deploy automagically, and jboss will sense the changed file and expand it into place. Tada! Your EJBs and servlets are ready to test. Try it.

Project Colle

[Myshkin5]

Take a look at Project Colle.

I don't have any direct experience with JDO but it sounds similar. Project Colle (Colle-SQL) focuses on building, loading, indexing and accessing databases from an XML scheme.

Re:Project Colle

[CowboyBob500]

Looks like there is particular dissatisfaction with this area of Java development. I'm also so frustrated with current tools that I'm writing my own thing as well - http://sourceforge.net/projects/jwebtoolkit

Good luck with your project.

Bob

Online JDO Overview

[awhite]

If you want to get a technical feel for JDO, Solarmetric has an online document that covers all the spec basics here. It's not as in-depth as a full JDO book, but it covers JDO concepts pretty nicely in about 40 pages (if it were printed).

Re:Still in love with Java?

[giantsquidmarks]

I was not trolling... why is java enormous in the enterprise and middleware setting..? Problems in this space can be solved in C++. Good C++ compilers are free. And the resultant product is invariably faster.

Why use another language if one already exists which can solve the problem..?

If C++ can get you in srinkwrap, on the shelf AND solve your problems in the middleware space AND in firmware AND... AND..., why turn to Java...?

In my opinion, there is no reason to turn to Java... I can solve any problem I am presented with in C++... or PERL (JCL in VM)... or the shell. These three tools work everywhere and can do anything. One of these three tools, or a combination of these three tools is the answer to any problem.

My time is valuable, I don't need another language...

What's after relational?

[Trinition]

In my databases 102 class in college (yeah, I passed databases 101), we covered heirarchial, network, and relational databases. More recently, I've learned of object oriented databases (for a free, 100% Java poor-man's OODB, see XL2). From everything I've read about OODBs, they would be better solution than RDBMSs for 90% of the stuff I've seen as a Java programmer.

The negatives I've heard from people in coversation are "they're not as fast", "there ae no tools", etc. BUt each of these are either false, not entirely true, or jyst due to immaturity:

Too slow Actually, because there is no impedance mismatch (converting from related rows into an Object, and converting the data types between disparate systems), they can be faster than an RDBMS. Where you might have to pull up a person record, and then their home address record, convert their homepage into a URL object, etc... in an OODBMS, your data is (can be) already in the proper Object format. You wouldn't needs things like JDO.

Tools no available Well, the haven't been around for as many decades as RDBMSs either. And, one of the other things that makes RDBMS tools so numerous is that they have a standard language, SQL. However, you must still rebuild what the data means in your reporting system separately from your online system. In an OODBMS, you would theoretically only build the Classes for the Objects once, and they would have with them the business rules.

Any thoughts? I'm not an OODBMS bigot, but I'm trying to be an advocate in the hopes that it will have some truly educational dialogue.

Re:What's after relational?

[John Bayko]

I've never understood what's special about OO databases - as far as I can tell, they're just either making the rows into objects, or allowing objects to be stored as column data. It may make interfacing with the database easier from an external language like Java, but doesn't actually enhance the database itself - the expressiveness is the same. It may even be worse, if you can't access the data within object columns for selects.

Something that is a genuine enhancement to databases is deductive databases, which attempt to simplify query writing by using defined relations to write the query for you.

Note: in set theory that relational database theory is based on, sets are equivalent to database tables, tuples are records, and attributes are columns.

Many of the concepts come from Prolog, which essentially defines the relationship between sets of tuples (with unnamed attributes), in such a way (using logical implications) that you can write a question, and the interpreter will figure out how the sets are joined based on the defined relationships (if they are), and return the first matching answer (or nothing, if no relationship can be found, or nothing matches the query conditions).

Many people have tried to make Prolog more database-like, with persistant data. However, relational databases can be made more Prolog-like. It wouldn't be hard - foreign key constraints provide much the same information as Prolog implication statements. It would not be that hard to generate a query based on known foreign key relationships - e.g. for "SELECT PERSON.NAME, COMPANY.ADDRESS", the interpreter could figure out as well as a human that what the relationship between PERSON and COMPANY is without an explicit WHERE clause.

I also don't think this would take much more time to execute, since generating the query only uses the table definitions, and it only has to be done once per query. A small number of entities to search and some caching should make it unnoticable in practice.

I suppose the question is whether it's worth the effort, when SQL is so simple. I think so, mainly because I think SQL is an abomination, but that's just me - I don't work with databases at the moment.

Re:What's after relational?

[Trinition]

OODBMS are not supposed to objectivy rows, and tables. In fact, XL2 (whcih is the only OODBMS I've worked with) does nothing of the sort. It's more like serializing the graph of objects and references you have in memory to disk.

Now, perhaps some OODBMSs are really object-relational mapping solutions behind the scenes, but I know for a fact that XL2 is not. I've been through the source code and was awed at the simplicity. It is very much like a snapshot of memory on disk.

Now XL2 is primitive in that it doesn't have an Objective query language. You must query it yourself. In pseudo-code, you would work with it like this:

XL2Database db = new XL2Database(...);
AddressBook addresses = (AddressBook)db.getRoot();
Person trinition = addresses.findByUsername("Trinition");
db2.startT ransaction();
trinition.setKarma(50);
db2.endTra nsaction();

Note that the AddressBook class defines "findByUsername". Internally, it could just be a HashMap. Or, if you wanted to be slick, it would be an XL2Map (which can lazy-load individual members). But the point is, I didn't write a query like "SELECT * FROM USERS WHERE USERNAME='Trinition'", convert the result into an object, change an attribute, and then take each attribute of the User object and stick it into a Prepared statement and update the record.

It is much simpler. Now, if you have 50 million users in your AddressBook, and XL2Map might not be the most efficient mechanism for performing lookups. Relational databases rock at that sort of thing.

But then again, as I said before. OODBMSs are still young, and XL2 especially is poor-man's OODBMS.

Re:What's after relational?

[John Bayko]

That sounds roughly like what I though, though maybe the terms differ. The object "type" or class corresponds to a set (or table, in RDBMS), and each object of that class is a tuple (or record or row). The object references are basically dataless foreign keys (constraints are implicit - the reference is added when the tuple/object is created, and garbage collection ensures that the object is never destroyed as long as the reference is still there, where in a RDBMS you explicitly delete tuples, and it raises an exception when the reference is still there - messy, but conceptually the same thing).

The nice thing about what you describe looks like you can follow the relations explicitly in program code. You can do that in RDBMSes, but there is no direct mechanism to support it (specifically syntax) - they're directed to automated query resolution to such an extent that trying to bypass it is actually harder (in other words, there's no way to avoid SQL comlexity when you don't want it). But that's a problem with SQL and RDBMS implementations, there's no reason you couldn't get your mind out of the SQL/Tables gutter and make a nice RDBMS.

In essense, the OODBMS you described is basically an RDBMS, but without automated queries. Actually, pre-SQL RDBMSes used to be like that. A lot more work to program (think COBOL) - the difference seems to be the text/table-oriented focus compared to using structs/classes for the same thing.

Re:What's after relational?

[Trinition]

Well, we might or might not be saying the same thing. The important thing in OODBMS is that there is no "impeadance mismatch". That is, you store the data as objects, not homogenous rows of primitive data types. I think the ODBMSFacts.com site's FAQ may explain it better than I do. But then again, maybe we are on the same length -- I can't tell.

Re:Still in love with Java?

[buckinm]

Because C++ doesn't solve the problem of writing your application on one platform, and running it on several others. I have an app that I write & maintain on w2k. It deploys on windows 95, 98, NT, etc, and Solaris, Linux, and AS/400. Is it possible to do that with C++? Not in the same way. I'm tried of coding a bunch of #ifdef WINDOWS in order to have portable code. Oh, and the COBOL jockeys never believed they would ever need another language either.

Re:Still in love with Java?

[Anonymous Coward]

Because C++ doesn't solve the problem of writing your application on one platform

That, again, is a matter of *SKILLS*
(see parent)

Drop them both

[matteo_v]

But, why not do without both EJB and JDO? I find JDBC is a fine interface. You don't really need an object-relational mapping. And for real applications you need to design the database by hand, and design the SQL transactions by hand. You can't get enough speed otherwise.

Re:Still in love with Java?

[buckinm]

Right...

Doing things in a harder way than necessary shows how skillful you are.

Re:Still in love with Java?

[giantsquidmarks]

I guess we have different experiences... I, kind of, see the value in "compile once, run anywhere". If java can live up to this, perhaps it does have a place. I shall ponder this more.

But I still dread mastering another language. I'd like to have a personal life at some point.

Re:Still in love with Java?

[bluFox]

*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).*

Yes I believe you, because i have the misfortune of coding in Jbuilder - Yes in java - and i hunger for an ide that is a little more responsible to my commands
These days i make do with textpad when i can help it.

Before talking about jbuilder's speed, run the visual c++ 6 ide, or the visual java ide (now defunct but still gives you a feel of how responsive an ide can be), and see the difference (I dont know what happened for the VS.net because it is again painfully slow.)

another point, i am not sure how many people actualy use JBuilder for coding in c++ There are so many better IDE's available for c++? And who does not understand that it is not native :P i mean the difference is there for all to see - at least in windows platforms, the absence of native widgets is a dead give away,

I do my coding in a p3 in office and the p2 i have at home, recently i had the chance to try out one of the p4s. Even in these the response of this IDE is nothing to romp home about , It has become bareable that is all.

Perhaps you are fortunate to code in the latest p4's but not every one does it that way.

Re:Still in love with Java?

[buckinm]

I Don't blame you there... I've always considered java to be a subset of C++ anyway...

Re:Still in love with Java?

[Anonymous Coward]

Keep that than necessary out of it. It applies only to people who dare to invent the wheel again and again while writing C code. then necessary is "covered by" *SKILLS* either.

Re:Still in love with Java?

[FortKnox]

Are you confusing JBuilder with Eclipse? Eclipse can run slow as balls, no question, but JBuilder 8 (I started with 6 and worked my way up) is a dream to code in. With integration with everything from CVS to Sourcesafe (and you can code your own plugins, easily), it is the only way I like to code java.

Re:Still in love with Java?

[bluFox]

I am not , ..

Eclipse was one of the IDE's i tried and i liked its ability to manage the ant files. It is slower than JBuilder , but as i said I was not comparing JBuilder with other Java IDE's but with the IDEs that are implemented natively.

I had to start with JBuilder 5 and now on 8 but i prefer the faster native text editors to do the coding any time.

Object Oriented Programming Languages

[Teknon]

More and more often these days, desktop and web applications need to display and interact with rich graphics. The Scalable Vector Graphics (SVG) format published as a World Wide Web Consortium (W3C) Recommendation in September 2001 is part of the response to that need. SVG allows you to describe two-dimensional graphics -- such as generic shapes, images, and text -- with an eXtensible Markup Language (XML) grammar. These graphics can be styled through Cascading Style Sheets (CSS) or XML, using advanced styling functionalities such as color gradients and filter effects. SVG is the W3C-recommended, XML-based, standards-based alternative to similar proprietary formats.

Re:suggestion - also add a link to addall

[draziw]

Link it to addall.
They even show how to link right to a book price search with ISBN, etc.. how to link.

Ryan