can you refresh my memory as to what the "generic jet4" type is?

It was implemented re:

https://sourceforge.net/p/jackcess/bugs/129/

DAO and ADOX can create an .mdb file that is a Jet4 database, but does not contain system objects that make it a V2000 or V2003 file.

A right. is there a benefit to being able to re-create this specific format, as opposed to just create a 2000 format db (which presumably just has some extra properties but is otherwise identical)?

The tests are designed to cover each file type, so if we want to test an operation against a GENERIC_JET4 file we need to be able to create one. (As mentioned, these changes were prompted by failing tests in AutoNumberTest.java)

what about just "faking" a create for unit tests?

If we fake creating the database file then wouldn't we have to fake the test results, too? In other words, wouldn't that be essentially the same as simply bypassing all of the tests for GENERIC_JET4 files?

As it stands now, under the [master] branch, many of the tests error out as soon as they hit the GENERIC_JET4 FileFormat (which comes first in the list of SUPPORTED_FILEFORMATS), e.g., ...

... so in this case we really don't know if the user will be able to add a column to an existing table in a GENERIC_JET4 file using the new ColumnBuilder#addToTable method because it never gets tested.

so, i absolutely agree about testing the format. however, i really don't see any value in having "generic jet4" as a format which jackcess supports creating new instances of as part of the public api.

since db creation is really just copying the relevant empty version into the given file name, and most of the unit tests use a common util method to create new instances, i was thinking we could just modify the test util method to do the "generic jet4" create using the empty db you provided. so the unit tests would all run against a real generic jet4 db, but the public api would still not support creating a new generic jet4 instance.

So you're proposing that

1. TestUtil.create should handle GENERIC_JET4 as a special case, copying the emptyJet4.mdb file to create the test file, and

2. DatabaseBuilder#create() should unconditionally throw an UnsupportedOperationException if it is asked to create a GENERIC_JET4 file?

FileFormat.GENERIC_JET4 is already visible to anybody who looks at the Enum. By "Public API" do you mean "'blessed' in the documentation"? (It does appear in the Javadoc, but I suppose we could add "for internal use only".)

Edit:

... or, for item 2 above, revert

addFileFormatDetails(FileFormat.GENERIC_JET4, "emptyJet4", JetFormat.VERSION_4);

back to

addFileFormatDetails(FileFormat.GENERIC_JET4, null, JetFormat.VERSION_4);

so they'd get

java.io.IOException: File format GENERIC_JET4 [VERSION_4] does not support file creation

just like the tests do now.

Yes, that is basically what i am proposing.

Having the FileFormat makes sense because we still want to reflect that to a user if they open a file of that type. I just see no reason for a user to be able to create a new database of that type.

I added another commit as suggested. (Does GitHub notify you when I do that?)

All the tests pass, both on Windows and Linux. The only change that gave me pause was changing DatabaseImpl#transferFrom from private to public so I could call it from TestUtil, but we could refactor that method into a more general-purpose utility class if necessary.

heh, yeah, that change caught my eye as well. i only glanced through, though, haven't had time to digest deeply. (and yes, i get notified on your commits)

Incorporated these changes into the main project.