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

[Magnus Ihse Bursie]

Also, we've worked hard to get rid of the map files in the build system. 
I'd be hesitant to say the least to re-introduce them.

/Magnus

On 2020-02-26 14:29, Bob Vandette wrote:
> 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
>> -----------
>>