Fixed various memory leaks and Java 8 JNI Compatibility

[adamretter]

I have manually audited the entire RocksJava code base.

Sorry for the large pull-request, I have broken it down into many small atomic commits though.

My initial intention was to fix the warnings that appear when running RocksJava on Java 8 with -Xcheck:jni, for example when running make jtest you would see many errors similar to:

WARNING in native method: JNI call made without checking exceptions when required to from CallObjectMethod
WARNING in native method: JNI call made without checking exceptions when required to from CallVoidMethod
WARNING in native method: JNI call made without checking exceptions when required to from CallStaticVoidMethod
...

A few of those warnings still remain, however they seem to come directly from the JVM and are not directly related to RocksJava; I am in contact with the OpenJDK hostpot-dev mailing list about these - http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-February/025981.html.

As a result of fixing these, I realised we were not really doing any error checking around our JNI calls, which in an unexpected error case could easily put RocksJava into an unknown state and leak memory. I correct this with extensive error checking through the code base.

Along the way I think I found several (11) memory leaks in RocksJava; I believe I have now fixed all of these, the most serious was in org.rocksdb.WBWIRocksIterator#entry.

[facebook-github-bot]

@siying has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

[siying]

Is the Java test failure in Travis related?

[adamretter]

@siying I do not think so, I have restarted the job to see. The top of the stack looks like:

C  [librocksdbjni-osx.jnilib+0x16cc65]  _ZN7rocksdb18WriteBatchInternal11SetSequenceEPNS_10WriteBatchEy+0x15