RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2]

[Jorn Vernee]

On Mon, 10 Jul 2023 16:40:06 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Move StringTable to JavaClassFile namespace.
>
> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8311661
>  - Move  '} // namespace JavaClassFile' to after '#endif //INCLUDE_CDS_JAVA_HEAP'.
>  - 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking

The JBS issue says: "That avoids having to fix the application or libraries code, which may not be practical." but I'm not sure how changing hotspot every time an application defines a conflicting symbol is more practical? This seems like a band-aid to make one particular application work. I think a more principled solution is needed that avoids symbol conflicts going forward, if we are serious about supporting static linking of hotspot.

For instance, the symbols that _should_ be exported from hotspot are found in several files in make/data/hotspot-symbols. Is it possible to limit the symbols exported/visible in the static library to those symbols instead?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1629746328