This RFE is expected to improve the dynamic (and static) linking story for Java SE by providing a linkage target that hides Hotspot implementation details, specifically to do with the current situation with per-compiler libjvm.so files but covering more issues than that. See 4777947 for history and additional details. Here is the specific proposal from Fred Oliver in the notes of that CR:
"There is quite a long email trail associated with this bug, and since I
am passing it on, I document some of the goals and constraints, and a
(1) Native applications embedding Java using the invocation API should
not be required to set the LD_LIBRARY_PATH in advance (for dynamicly
loading the JVM). Applications which staticly link to the JVM should
require LD_LIBRARY_PATH set only to select the JVM to use.
(2) The same solution should work on both Solaris and Linux.
(3) The solution should allow the linker argument "-z defs" so that no
symbols are left undefined, only to be detected later on.
Create a new libjvmsyms.so which
(a) Lives in jre/lib/<processor> with the other native libraries.
(b) Defines every private JVM entry point required by our native
+ All of our native libraries requiring these entry points will be
linked against this new library (instead of libjvm.so), and bound
to it by including $ORIGIN in the runpath.
+ None of these entry points will ever actually be called, because
the JVM will be loaded first, and its symbols will override those
in the new library.
(c) Implements the entry points as fatal errors (to guarantee that they