[JDK18] InternalError: Caller is not annotated as @CallerSensitive

[babsingh]

OpenJDK Tests

TEST: jdk/internal/reflect/Reflection/GetCallerClassTest.java#id0
TEST: jdk/internal/reflect/Reflection/GetCallerClassTest.java#id2
TEST: jdk/internal/reflect/Reflection/GetCallerClassTest.java#id1
TEST: jdk/internal/reflect/Reflection/GetCallerClassTest.java#id3

Error

[2021-11-17T18:35:06.056Z] testMissingCallerSensitiveAnnotation...
[2021-11-17T18:35:06.056Z] STDERR:
[2021-11-17T18:35:06.056Z] java.lang.InternalError: Caller is not annotated as @sun.reflect.CallerSensitive.
[2021-11-17T18:35:06.056Z]      at java.base/jdk.internal.reflect.Reflection.getCallerClass(Native Method)
[2021-11-17T18:35:06.056Z]      at boot.GetCallerClass.missingCallerSensitiveAnnotation(GetCallerClass.java:35)
[2021-11-17T18:35:06.056Z]      at GetCallerClassTest.testMissingCallerSensitiveAnnotation(GetCallerClassTest.java:118)
[2021-11-17T18:35:06.056Z]      at GetCallerClassTest.main(GetCallerClassTest.java:89)
[2021-11-17T18:35:06.056Z]      at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[2021-11-17T18:35:06.056Z]      at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
[2021-11-17T18:35:06.056Z]      at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:52)
[2021-11-17T18:35:06.056Z]      at java.base/java.lang.reflect.Method.invoke(Method.java:577)
[2021-11-17T18:35:06.056Z]      at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
[2021-11-17T18:35:06.056Z]      at java.base/java.lang.Thread.run(Thread.java:884)

Related: #13946

[babsingh]

Test code: openjdk-next...GetCallerClassTest.java#L121

Test code expects the InternalError message to be CallerSensitive annotation expected.

OpenJ9's InternalError has the following message: Caller is not annotated as @sun.reflect.CallerSensitive.

openj9/runtime/nls/j9vm/j9vm.nls

Line 1322 in 4d741e5

J9NLS_VM_CALLER_NOT_ANNOTATED_AS_CALLERSENSITIVE=Caller is not annotated as @sun.reflect.CallerSensitive.

This failure can be resolved if the InternalError message mismatch between OpenJ9 and test code is fixed.

Three potential solutions:

1. Update OpenJDK test code
2. Update OpenJ9 trace point message
3. Similar testing exists in OpenJ9: openj9...GetCallerClassTests.java. So, we keep the failing OpenJDK tests excluded, and rely upon similar OpenJ9 testing.

@pshipton We have chosen Solution 3 for similar cases in the past. Do we want to take the same path for this issue?

[pshipton]

Although we don't want the patches, the safest approach is to update the OpenJDK test code. I'm concerned we might miss something otherwise with all the changes that are occurring. Although it would be a better solution, I'm concerned copying the OpenJDK message is a license violation.

[gacholio]

All of the tests which check for an exact exception message match are invalid. We long ago decided against blindly copying OpenJDK messages. Patching 100s of tests seems unreasonable.

[babsingh]

I agree that we should not update OpenJ9 code. I don't think the test in question is invalid.

I also agree that we may miss something critical if we exclude the OpenJDK test.

In this case, we can update the OpenJDK test with a regex so that it accepts both OpenJ9 and OJDK messages. We will need to only update two locations:

1. openjdk-next...GetCallerClassTest.java#L121
2. openjdk-next...GetCallerClassTest.java#L136

@pshipton @gacholio For resolving this issue, shall we proceed with updating the OpenJDK test?

[gacholio]

If you mean updating it in the OpenJDK repo, yes. If you mean a local patch, then no I would not approve that.

[pshipton]

This is updating in the OpenJDK repo, which I agree with.

[gacholio]

It looks like an IBM repo, which is not the OpenJDK repo, so we'll be maintaining patches. This is foolish, but not my problem, I suppose.

[babsingh]

In the future, we can encounter conflicts in the extensions repo for our patches. The chances of the test code to be updated are pretty low. So, these patches should have a low risk for a potential conflict.

[pshipton]

It seems more foolish to allow a bug to occur because we didn't run the tests and something was missed. While it would be nice to contribute the test fix upstream, it seems unlikely to be accepted. Although we could try.