RFR: JDK-8200178 Remove mapfiles for JDK native libraries
Alan.Bateman at oracle.com
Fri Mar 23 14:45:09 UTC 2018
On 23/03/2018 13:56, Magnus Ihse Bursie wrote:
> With modern compilers, we can use compiler directives (such as
> _attribute__((visibility("default"))), or __declspec(dllexport)) to
> control symbol visibility, directly in the source code. This has
> historically not been present on all compilers, so we had to resort to
> using mapfiles (also known as linker scripts).
> This is no longer the case. Now all compilers we use support symbol
> visibility directives, in one form or another. We should start using
> this. Since this has been the only way to control symbol visibility on
> Windows, for most of the shared code, we already have proper JNIEXPORT
> decorations in place.
> If we fix the remaining platform-specific files to have proper
> JNIEXPORT tagging, then we can finally get rid of mapfiles.
This seems like a great cleanup as the mapfile have always been a pain
to maintain. Also shines a light on some technical debt too.
handleSocketError in libnio is a surprise, this should not be exported
and should not have been in the map file. I suspect the issue is that
jdk.sctp is missing a function prototype from its header file (it has
its own handleSocketError in SctpNet.c).
NET_Wait in libnet is another one, I can't tell why this was listed in
the map file.
I'm also surprised with java.dll exporting handleRead, winHandleRead,
and handleLSeek. I didn't see them mentioned in your mail so I'm curious
what might be using those.
More information about the security-dev