Great. That means as long as using the same classloader (as Hadoop seems to do so), reusing libsnappy.so between hadoop-snappy and snappy-java is no problem. Now, it looks like whether to use libsnappy.so or not is a problem of snappy-java, and I prefer to use libsnappyjava.so (statically linked snappy + JNI code with -fvisibility=hiden option), which can avoid potential API conflict and missing library problems (for some OSes).
In my experience of developing sqlite-jdbc (http://sqlite-jdbc.googlecode.com/), which uses the same technique to extract .so file at runtime, many people seems to be satisfied with this approach. The problem that can be solved by the runtime library extraction is failures due to misconfiguration (e.g., LD_LIBRARY_PATH, etc.) and library build process (gcc, linker options, etc.) for each OS. For example, I frequently use Windows to develop the code, but run the production code under Linux; no need to switch the library files really helps me a lot. But, looking at
HADOOP-7405, current Hadoop's native libraries are not so portable across various OSes. In such a state, motivation for using portable library something like snappy-java might be low.
I don't care which one is used in Hadoop, but the discussion in this thread has been useful for me to improve snappy-java. Thanks!
a) OS X (32-bit/64-bit) are already supported.
b) I need to know os.name and os.arch name system properties that IBM JVM provides.
Building and embedding non-bundled so file into snappy-java is simple; just do "make".
As a matter of fact, I do it for 6 types of OS and CPU combinations. And also, by using VMWare FUSION in Mac, all of native libraries currently supported can be compiled in a single machine. Some 64-bit OS can be used to build 32-bit native libraries (e.g., Windows, Linux, etc.)