I think we should just do the translation in the JNI code.
In general, people expect the jar files to be portable, meaning you can copy them from one PC to another without suffering disaster. This will not be true if we start injecting native constants into the Java code. In contrast, libhadoop.so is designed to contain the operating-system and architecture-specific parts of the code.
Also, do we really want to depend on Perl for our build process? I realize there's already a changes2html.pl script, but in general Perl seems like another build dependency we'd be better off without. Installing Perl on some platforms will definitely be a hassle-- like Windows. We also don't document our Perl dependency anywhere right now.
I suspect that [translating the constants] is going to be a lot slower.
I seriously doubt that the performance difference between translating the constants and passing them straight through will even be measurable. If you like, I can do some before and after benchmarks with constant translation and without. Keep in mind, this is a couple of if statements every time we open a file. Considering the other performance issues we have to tackle, this is less than noise-- on par with changing constants because you believe comparisons with 0 are faster, etc.