JDK 7131356 fix

[timob]

I've split out the JDK 7131356 bug fix from dbarganski:macos-patch branch into this branch.

Updated the loading so it's not an error if libjli cannot be loaded, but logs a warning.

Updated the path to find liblji on my OpenJDK download tar the layout is:

users-MBP:jnigi user$ find ~/java/jdk-14.0.2.jdk/ -name libjvm.dylib
/Users/user/java/jdk-14.0.2.jdk//Contents/Home/lib/server/libjvm.dylib
users-MBP:jnigi user$ find ~/java/jdk-14.0.2.jdk/ -name libjli.dylib
/Users/user/java/jdk-14.0.2.jdk//Contents/Home/lib/libjli.dylib
/Users/user/java/jdk-14.0.2.jdk//Contents/MacOS/libjli.dylib

[dbarganski]

@timob: There may be different logger used by application (like my case). I would rather not deal with logging.

My proposal would be to have a global "platform" flag that either skip loading libjli (default, legacy), enable optionally loading (in such case load error will be ignore) or force loading (load error will be treated as error).

That will keep 100% compatibility with existing code and "optionally" load libji.

JNGIPlatformFlags = ( LIBJLI_LOAD // No op on all platform except mac LIBJLI_FORCE_LOAD // No op on all platform except mac )

Does it make sense ?

[timob]

I like the optionality of your idea. Maybe a user of the package could set a environment variable using os.Setenv("LIBJLI_LOAD", "yes") and os.Setenv("LIBJLI_LOAD", "force"). Using environment variable would allow the developer or the packager of the software to configure this.

[timob]

Last commit does what we discussed, 👀 💯 ?

[timob]

Ok Iets do this.... 😎

[dbarganski]

@timob : Thank you. Currently busy but I will have time next week. Also added some extension of JNI calls for class definition but need to work on test case.