RFR: 8239563 - Reduce public exports in dynamic libraries built from static JDK libraries
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Wed Feb 26 14:09:52 UTC 2020
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.
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.
>> 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?
>> Andrew Dinn
More information about the core-libs-dev