[Java] Separate JNI build with ONNXRuntime source

[lanking520]

Currently the JNI build jobs are bundled in the ONNXRuntime itself. It is very inefficient to rebuild if you only change some part of the code in Java. Separate JNI build also provide an ease to leverage any released binaries of ONNXRuntime to have the best performance. If anytime we plan to add backwards compatible JNI for all previous ONNXRuntime releases, make then build separate will be much easier. @Craigacp

Proposed change:

# build any cmake to have the ONNXRuntime C/C++ API

Use the gradle project (assume the output shared libraries is in the root folder)

./gradlew compileJNI

to just build JNI

[Craigacp]

The JNI code depends on the exact build flags supplied to the ORT C API as it controls which execution providers are compiled in. Additionally separating it out so that the JNI binding can work with different versions of ORT's C API seems tricky, as it could only be upwards compatible (as in the JNI binding could work with newer builds of ORT which didn't have breaking API changes, but not older as they'd be missing functions at link time). I'd rather not risk having separate compilation of the JNI binding and the ORT native library, as it can cause mysterious errors which are unexpected by Java developers.

If you want to recompile the Java side bits without changing the native bits, you can run the gradle build with the path to the CMake build dir as an argument and it will just rebuild the Java code & rerun the Java tests. For example after running ./build.sh --update --build --build_java --config Release you can then run cd java; ./gradlew -DcmakeBuildDir=../build/MacOS/Debug/ clean spotlessApply build test to rebuild the Java bits and rerun the tests.