Export rocksdb fuctions in rocksdbjni.dll

[rhubner]

This PR modifies the CMake build process on Windows to export all RocksDB functions in rocksdbjni.dll.

This allows us to reuse Java builds artifacts in other programming languages without need to manually recompile the .dll for each language.

Closes https://github.com/facebook/rocksdb/issues/12226

[ajkr]

I see the appeal of exporting all the functions as librocksdbjni is almost usable as a general-purpose (non-Java) RocksDB library. But I am not sure we want to encourage or guarantee that usage as the 'j' in librocksdbjni was supposed to stand for Java. Is there precedent for using it for non-Java?

[adamretter]

@ajkr expanding on my comment here - https://github.com/facebook/rocksdb/issues/12226#issuecomment-2162683927

If you extract the .dll or .so files from the Jar file, then you really just have a binary build of RocksDB as a library. It does also include the JNI C++ API, but that is fairly light-weight, and you can use it if you wish, or just ignore it.

The Linux and macOS libraries for RocksJava have always already included the C++ and C API. This change just makes the Windows RocksJava library on-par with the Linux and macOs ones.

[adamretter]

@ajkr @pdillinger can we get this one merged please?

[ajkr]

Would providing a Makefile target to build non-Java static lib with statically linked compression libraries solve their problem?

[adamretter]

@ajkr Possibly. However, regardless, I think we would also like the RocksJava binaries to be equivalent on all platforms (including Windows).

[ajkr]

The inconsistency feels like a difference in linker behavior that only affects off-label uses of the JAR. This kind of inconsistency seems expected to me. So, I am trying to suggest alternatives that may serve the user better and leave behind fewer hacks/semi-officially supported usages.