RFR: JDK-8200178 Remove mapfiles for JDK native libraries

[Alan Bateman]

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.

-Alan