Rating: 

well you are, and it happened rather a while ago. the book goes about, oh, 2/3 of the way toward showing a fix for the problem. but msrs. Tate & Gehtland are not true database wonks (you can see it in how they talk about databases), and that remains the problem with java; especially the Enterprise variety. enterprise development without a deep understanding of data modeling is a travesty. java started as a client (applet) approach to language; we're still paying dearly for this 'small' view. as the authors point out, EJB isn't the answer. some of the answer is in the text; much of it lies in the world of relational database modeling.

put simply, java folk view data the way COBOL did before Dr. Codd and his 12 kids showed them the way to Application Independent Data Storage (tm). java folk think that their application is the only way into the data. the relational database is designed to support arbitrary access; treating it like a bunch of VSAM files (which is what 99.44% of java developers do; 'we don't need no stinkin foreign keys') is tres retrograde. this is why java will lose. it's data model is 35 years old.

even, perish the thought, should the java twinks get their way, users lose; their data is no longer open, but tied up in 0 NF databases and (God punish them severely) XML. tagged text files aren't 35 years old; their 40 years old.

the relational database is really what OO claims: data and its control in one place. java folk go around writing pages of stuff, when the proper solution is a 3 NF database with check constraints (and possibly other stuff, but still in the database WITH THE DATA).

remember the mantra: the DATA is the application, not the code. the best we can hope is that the coders don't screw up the data beyond repair.