On 05/10/2015 15:14, Steve Loughran wrote:
I don't think anyone would object for the changes, except for one big caveat: a lot of us would like that binary file to be backwards compatible; a Hadoop 2.6 JAR should be able to link to the 2.8+ libhadoop. So whatever gets changed, the old methods are still going to hang around
That's not achievable as the method signatures need to change. Even though they are private they need to change from static to normal methods and the signatures need to change as well, as I said.
JNI code is intimately intertwined with the Java code it runs with. Running mismatching Java & JNI versions is going to be a recipe for eventual disaster as the JVM explicitly does *not* do any error checking between Java and JNI. At some point some innocuous change will be made that will just cause undefined behaviour.
I don't actually know how you'd get a JAR/JNI mismatch as they are built and packaged together, so I'm struggling to understand what the potential issue is here.
In any case the constraint you are requesting would flat-out preclude this change, and would also mean that most of the other JNI changes that have been committed recently would have to be ripped out as well . In summary, the bridge is already burned.
-- Alan Burlison --
