General
Yep, Jackcess is pure Java. It will work on any Java Virtual Machine (1.8+).
Jackcess supports Access database versions 2000-2019 read/write and Access 97 read-only.
Basic password protection (Access 2003 or earlier) is merely software enforced, and Jackcess does not do any password checking at this point. So, a password protected database can be used the same as any other.
If a database is actually encrypted, then you will need need an encoder.
Data validation in Access is controlled via a variety of mechanisms, not all of which are supported by Jackces. See the table below for details:
| Data Validation Type | Support |
|---|---|
| Data types (Text, Number, etc.) | Yes |
| Field sizes (min/max length, precision, etc.) | Yes |
| Unique constraints (indexes) | Yes |
| "Enforce Referential Integrity" (aka foreign key constraints) | On by default, can be selectively disabled. |
| Field/Table Properties (Validation rules, Input masks, etc) | On by default, can be selectively disabled. Input masks are not handled. |
We want to give a lot of credit to mdbtools. They have been around much longer than Jackcess, and, along with POI, inspired us that a project like this could be done. mdbtools is written in C. There is a Java port of it, but if you've ever read or used a Java port of a C library, you can appreciate the difference between such a library and one written from scratch in Java.
At the time of this writing, mdbtools could only read Access databases. Jackcess can also write to them. According to their web site, "Write support is currently being worked on and the first cut is expected to be included in the 0.6 release." This status hasn't changed since we first started work on Jackcess.
The Java port of mdbtools includes an implementation of a small subset of the JDBC APIs. Jackcess does not currently, but a pure Java JDBC driver for Access could certainly be written on top of Jackcess.
Version 3.0+ requires JDK 1.8 or higher. 2.x versions require JDK 1.5 or higher.
Probably because you're missing a jar that Jackcess depends on from your classpath. Take a look at the dependencies list. The "compile" and "runtime" dependencies (which are not marked as "optional") are necessary for using Jackcess in your application. One great place to track down these dependencies is in the Ibiblio Maven Repository.
In general, the focus of Jackcess is functionality, not speed. However, one major speed factor is whether or not all writes are automatically forced to disk. By default, "autoSync" is enabled, which keeps the database file in a more consistent state, but can be very slow for large updates. Disabling "autoSync" can dramatically increase update speed, but exceptions during update can leave the file in an unusable state (when disabled, you can call Database.flush() manually to force updates to disk). Modifying this option essentially trades off speed for recoverability.
Additionally, adding rows in batches instead of one at a time can increase insert speed.
Finally, always make sure you are using the latest release, as speed improvements are happening periodically.
Update: As of the 1.1.21 release, the text index handling supports the entire Basic Multilingual Plane 0 (i.e. any unicode character 0x0000-0xFFFF). Consequently table names can (as of this release) contain any character in this character set.
There are 2 issues which need to be dealt with when using Jackcess on the Android platform. The first is that non-class resources need to be in a special location. The second is that the nio implementation has some "weaknesses".
The following steps will make Jackcess compatible with the Android platform.
Using Jackcess read-only on the db would not corrupt the db file itself. That said, you risk that jackcess will throw spurious exceptions or find invalid or "corrupt" data while attempting to read the database because the database file may not be internally consistent at all times. So, at the very least, you will need to expect reads to occasionally fail. Depending on what "reliability" you require of the data, you might also need to handle reading data which is not 100% correct.
Ok, that wasn't a question, but we'll try to respond anyway. :) As you might imagine, it's kind of hard to test, simply by its nature. There are bugs that we are aware of, and certainly many more that we are not. If you find what looks like a bug, please report it. Even better, fix it, and submit a patch.