chore(Core): Avoid injection errors for Java 26

[l-1squared]

No description provided.

[Copilot]

Pull request overview

This PR aims to prevent ByteBuddy class injection failures on newer JVMs (Java 26) by conditionally falling back to a wrapper class loading strategy when reflective injection is not available, and it extends ScenarioExecutorTest to validate lifecycle behavior under different class loading strategies.

Changes:

• Update ByteBuddyStageClassCreator to select INJECTION only when ClassInjector.UsingReflection is available; otherwise use WRAPPER.
• Add/extend tests in ScenarioExecutorTest to validate wrapper/injection behavior for lifecycle methods, visibility edge-cases (package-private/protected), and class identity differences across class loaders.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
jgiven-core/src/main/java/com/tngtech/jgiven/impl/ByteBuddyStageClassCreator.java	Adjusts ByteBuddy class loading strategy selection to avoid injection-related failures.
jgiven-core/src/test/java/com/tngtech/jgiven/impl/ScenarioExecutorTest.java	Adds tests covering wrapper vs injection lifecycle execution and classloader identity edge-cases.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

[hvennekate]

General comment on this class: it would probably be better to repeat the test cases for the different strategies in more general terms: First, I noticed that the tests are essentially the same -- as are the stage classes (it does not seem to me that this is really necessary given that the executor retrieves the actual instances from the creator anyway). At that point, I would have suggested using nested test classes to group the test cases. But then realizing that they are essentially (did not compare each, tbh.) the same, it seems to me like it should be possible to have one generalized test base and just inherit that in each of those nested classes with some specialized setup for each strategy, no?