Java Programming

Hello,

this topic is related to java DB, but is not a JDBC problem, so I deem that {forum:id=1050} was not the best fit; I post it to this more general forum, on the grounds that it's a deployment question regarding a standard JDK component.

We (are only starting to) develop a JavaSE application that will require a local database, using the embedded JavaDB as featured in the JDK 6 installation.
I wonder how we can design the installation of the application's database in the user environment.

Here is my current understanding of JavaDB, along with the installation techniques i imagine. Can you suggest pro/cons of each, or suggest another way?

My understanding:*

- Java DB is an in-memory DB, which persist its data in proprietary files. It can be used embedded (in the application's JVM), or as a DB server (in a dedicated server JVM), in my case there is a single process that needs persistence, and I have no requirement that suggest to have a DB process alive on its own, so the embedded mode makes most sense.

Among the "persistence" proprietary files, there are two types of files, the ones that hold the actual data, and "control files" (checkpoints, transaction logs,...). For a stable base (when all traffic is over, all data is in data files.

My needs*

After being installed on a customer's PC, the system will consist of a Java application featured as a (collection of) jar file(s), and a JavaDB structured with a schema, and (optionally) populated with default data.

Installation Strategies*

I see 4 strategies:
1) Archive the appropriate persistence files tree from the build/test environment, and unzip it on the customer's machine.
2) Implement Java code in the application installer, that creates a DB and creates the schema, issuing the relevant DDL SQL statements for the schema and DML statements for its default population.
3) Implement Java code in the application itself, that at startup, tests whether the DB exists, and if not creates and populates it as in approach 2.
4) Design application code (probably only entity and DAO classes) that leverages whatever "magic" JPA machinery that automatically creates the mapped DB structures when initialization code "persists" default values the first time: a while ago my team used that in a Glassfish+MySQL prototype, but I don't know if it's a JPA or a Glassfish feature, and I don't know how solid this approach is, especially how it deals with upgrades, when the DB may already exist.

Note that the rate of changes in the DB structure when the application is upgraded may be a factor: if it helps I can consider it non-existent (and accept that DB upgrades require offline scripts that migrate the DB first, before installing the software).

Thanks for your help.

J.