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. 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
