On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou <jian...@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. Hi Jaikiran, Thanks for looking into this. > is there some way these issues can be caught when code changes are being > reviewed in future? Or would this require explicit run of some tool to > identify these issues? The symbol issues are reported as linker errors when statically linking the executable with JDK native libraries and libjvm. I just created a branch with the preliminary makefile changes for optionally statically linking JDK, which can be used to demonstrate/identify the issues: https://github.com/jianglizhou/jdk/pull/new/JDK-8303796 The branch is based on our prototype on JDK 11, but mostly reworked. It re-uses the existing JDK make infrastructure based on the feedback from Severin Gehwolf in https://bugs.openjdk.org/browse/JDK-8303796. Still need to clean up the makefile changes before making it ready for review. Early feedback/input is also welcomed. > 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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1513574228
