Ted Neward has a post on O/R up. I raised this post on the Smalltalk IRC channel to general snickers - I'll probably have a more detailed critique from an O/R expert later. In any case, I'm reading along and come across this:

If none of these approaches seems particularly what you're looking for, particularly because they still seem like too much work and too awkward to work with from within Java, another approach is to make use of the recently-standardized SQLJ, or "embedded SQL for Java", specification recently approved as part of the SQL-99 specification. As with other embedded SQL technologies, SQLJ allows a programmer to write SQL statements directly within the Java code, which is then preprocessed by a SQLJ preprocessor, turned into regular Java code and fed to javac as a normal compilation step. The SQLJ preprocessor takes care of any of the call-level interface logic in your Java code--you just focus on writing the SQL when you want to talk to the database, and on Java when you want to do anything else.

The easiest way to use SQLJ is to use static SQL statements embedded in the code directly, what's known as SQLJ clauses:

Ummm.... you build a data access layer with embedded SQL all through it? One of the first Smalltalk applications I built (way back in the early 90's) did that, because at the time "it seemed simple". Then the schema changed, because the dba's decided it needed changing. Boom crash, broken app, with changes required all over the place. IMHO, embedding the SQL this way is as silly as scattering hardcoded constants all over the place - it doesn't scale.

Then there's this:

One major drawback to SQLJ, however, is its relative lack of support within the J2EE community. Although the J2EE and EJB specifications do mention it by name as a possible data-access technology layer, it receives almost no attention beyond that. Oracle is the only major database vendor to have a SQLJ implementation available as of this writing, and there seems to be little support from the community as a whole, which is a shame, because in many respects this is the epitome of a relational-first persistence approach.

So not only is it a terribly bad idea, it's unsupported for the most part. "Here use this approach that cripples your application maintenance, and obtw, better stick to one DB". Bah. It looks more and more to me like Gemstone is like Da Vinci - brilliantly ahead of it's time, simply outside the grasp of the current crop of developers....