[code-reflection] RFR: Test java version check we do in op building methods [v3]

[Mourad Abbay]

On Wed, 17 Dec 2025 22:50:32 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Mourad Abbay has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Test reflectable lambda
>>  - Apply suggestion
>
> test/jdk/java/lang/reflect/code/writer/TestJavaVersionChecker.java line 48:
> 
>> 46:             ie = e;
>> 47:         }
>> 48:         Assertions.assertNotNull(ie, "Reflectable lambda creation didn't fail as expected");
> 
> Recommend you separate out the tests for methods and lambdas.
> 
> The behavior for lambdas is an unfortunate deviation from that of methods, and it's hard to diagnose and occurs at a distance from where the quoted code model is requested. We need to be consistent, which indicates we have to revisit how we load the code model and extract the quoted code model. At the moment the code model is loaded (built) when the LMF inner class is initialized, and the quoted code model extracted when the inner class is instantiated. We should really be lazy. We might have discussed that but avoided it due to the additional complexity in an already complex area. Now we have a better understanding we can revisit. Let's do so in another PR.

I Will do it in a subsequent PR.

> test/jdk/java/lang/reflect/code/writer/TestJavaVersionCheckerForMethods.java line 35:
> 
>> (failed to retrieve contents of file, check the PR for context)
> What happens if you call `Op.ofMethod` again after the first failure?

It will throw the `UnsupportedOperationException`. Did you expect a different behaviour ?

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

PR Review Comment: https://git.openjdk.org/babylon/pull/748#discussion_r2632485718
PR Review Comment: https://git.openjdk.org/babylon/pull/748#discussion_r2632492701