RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries

[Jaikiran Pai]

On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> - Make functions 'static' when feasible:
>   - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
>   - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
>   - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c.
>   - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c.
>   - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static.
>   - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static.
> 
> - Rename functions by following the existing naming usages in different libraries code:
>   - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss.
>   - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11.
>   - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11.
>   - Rename throwIOException() to p11ThrowIOException() in libj2pks11.
>   - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw<exception> functions.
> 
> - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used.
> - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c.

Thank you for those details, Jiangli.

> 
> 
> > Once that work is done and integrated in the JDK build, would that catch issues like these across different components of the JDK, before such changes get merged in?
> 
> Yes, one option would be to include the JDK static build in pre-submit testing, which can catch any changes breaking the build. That would need to be discussed broadly with other members in OpenJDK.

Even if it doesn't get enrolled in the pre-submit testing, I think the fact that there will be a build within the JDK which can catch these issues is a good thing. It might catch the issue(s) after the integration, but I think it's still a good improvement to have these issues identified by running a specific variant of the JDK build process.

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

PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1514538152