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
possible solution.

Requirement

(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.

Goals

(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.

Proposal

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
    libraries. 
    + 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
    aren't called)."