RFR: 8239563 - Reduce public exports in dynamic libraries built from static JDK libraries

[Bob Vandette]

Thanks but I don’t like that idea for several reasons.

1. It’s too dramatic of a change for the immediate problem I’m trying to solve.

2. It creates a support issue.  Every time a new native function is added or removed, we’d have several files
that would need to be updated (1 per OS type).

3. How do we know which functions to export.  The VM sometimes needs to get access to internal native
functions that are not accessible via java native methods.

I prefer the option where we can override the definition of JNIEXPORT.

Bob.


> On Feb 26, 2020, at 7:36 AM, Andrew Dinn <adinn at redhat.com> wrote:
> 
> Hi Bob,
> 
> On 25/02/2020 20:37, Bob Vandette wrote:
>> 
>> Please review this RFE that alters the visibility of JNI entrypoints to hidden when a shared library
>> is created using static JDK libraries.
> As David Holmes mentions in his ocmment on the JIRA it is possible to
> control re-export of the JNI entrypoints in the shared library using a
> linker map. Indeed, OpenJDK does this to limit visibility of entrypoints
> to libjvm.
> 
> Is there a reason why this is not a viable alternative to changing the
> definition of the JNIEXPORT macros?
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
>