* Bob Vandette:
> CSR:
>
> https://bugs.openjdk.java.net/browse/JDK-8239791
For ELF (at least in the GNU incarnation), a change to the installed
jni.h is not required to make the symbols hidden; a hidden definition
would be sufficient for that. The declaration may however allow the
compiler to generate better code because it can assume a local
definition.
> All JNI entrypoints that exist in JDK static libraries are declared as
> exported or visible. If a dynamic library is built from these static
> libraries, we end up with many exported functions that we don't want
> to provide access to,
Do you expect any impact on processes which have loaded multiple copies
of the same static libraries (same library and version) linked into
different shared objects? Non-hidden symbols tend to make this work
transparently, even for code that does something like
static const char *const label = ...;
if (ptr != label)
free (ptr);
With hidden symbols, this tends to break if ptr is passed from one
shared object to the next because all code copies are active, and their
label variables have distinct addresses.
> This is a security issue and a potential problem if this library is
> mixed with other libraries containing these symbols.
This problem still persists within shared objects themselves, of course.
Thanks,
Florian
