On Fri, 27 Feb 2026 18:31:11 GMT, Frederic Parain <[email protected]> wrote:
> JNI GetObjectField and SetObjectField don't enforce strict fields semantic,
> but they could optionally log messages when strict fields accessed in order
> to help debugging.
Hi Fred,
I'm not sure if we are quite ready for these checks - mainly because of testing
them (and there are no test cases in the PR so that needs to be addressed).
But IIUC nothing currently uses strict static fields, so we cannot test these
by any means. Also I think the primary rule requires us to be in the context of
a `<clinit>` which we can't readily test in any case (not even for final field
setting).
For the strict instance fields my understanding is that it is impossible to
have bytecode that would invoke the JNI methods from within `<init>` before
strict fields have been set (due to `uninitializedThis`) so we cannot test for
a read-before-set in that context. The only time this could occur is if we use
`AllocNew` in native code and then read/write the strict field whilst still in
native.
And I don't agree with issuing a warning just because we are reading a strict
field - we have to tie the warning back to the initialization state somehow.
src/hotspot/share/prims/jni.cpp line 1818:
> 1816: if (fd.is_strict()) {
> 1817: ResourceMark rm(current);
> 1818: log_debug(jni)("%s read strict instance field %s.%s
> (initialization not guaranteed)", func_name, ik->external_name(),
> fd.name()->as_C_string());
I think the preferred terminology is "strictly-initialized instance field".
-------------
PR Review:
https://git.openjdk.org/valhalla/pull/2182#pullrequestreview-3886117554
PR Review Comment:
https://git.openjdk.org/valhalla/pull/2182#discussion_r2881232704
