I came across jPersist very recently. From their example everything look nice and easy. But I when I tried to map tables with name different from the classes (using the interfaces TableMapping and ColumnMapping) I could’nt figure out a way to make it run properly.
I was wondering if you were still playing with it or not?

By the way, carry on with the scala series…very interesting.

Olivier

This is along the lines of the two dzone readers who down voted my article because they we friends of yours. Of course everyone shot me down for complaining, but the reality is that it’s not cool (along the same line as sportsmanship and being polite), and I would not do the same to you.

I have a few corrections for you:

o The passing items via a constructor or calling several setters is a matter of preference (I prefer constructors and less lines of code), but this is an example not real world.
o You missed the part about extending PersistentObject, which allows jPersist to track an object to a row in the database, as well as, tracking the state of persistence.
o With jPersist loading and inserting makes an object persistent (providing it extends PersistentObject), and this ties an object to a row in the database.
o I chose this implementation because I wanted to be able to work with POJOS, as well as, persistent objects.
o It’s also possible to extend jpersist.Database, in which case you are highly coupled to the database (I don’t document that).
o The internal iterator is simply a wrapper around a JDBC ResultSet that allows you to traverse the database (if you consider ResultSet an internal iterator).
o jpersist.Database wraps Connection, Statement and ResultSet functionality. The jpersist.Database also has a clone() method which keeps the connection but uses new Statement and ResultSet objects. This allows you to perform multiple queries with the same connection, so you’re not just limited to one query.
o I did not implement an SQL derivative. It is not a framework-specific query language. The only thing going on there is with “:attribute” which is replaced with the column name; the where clause is then added to the SQL statement being built and passed to a prepared statement.
o Yes I did want to support Java 1.4, because I believe there are still a lot of Java 4 users, and I am working on a Java 5+ version.
o If I am avoiding XML and annotations, does it not make sense that I would have a different scheme for handling associations?