You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
--strict-image-heap requires all classes to be marked for build-time init that become part of the image heap. However, JUnit provides various mechanisms that allow users to pull in their own classes. One such mechanism is @ParameterizedTest with its @ValueSource and @EnumSource. The moment an object becomes part of the heap of a user-defined type, native testing fails because those types also need to be explicitly marked for build-time init.
Generally, we are aiming at keeping the use of build-time init at a minimum (e.g., oracle/graal#7488), so it makes sense to revisit our JUnit support and reduce or even avoid the use of build-time initialization.
This probably means that test discovery also needs to run at run time, unless it can somehow be pre-computed at build-time and stored in such a way that user-defined types cannot end up in the heap. However, it also probably means that we need to register all methods for reflection that JUnit can potentially access reflectively (e.g., to instantiate and run a test case).
The text was updated successfully, but these errors were encountered:
We currently build-time initialize
NativeImageJUnitLauncher
, which referencesTestPlan
and transitively many other JUnit classes. As a result, we also have to mark lots of other classes for build-time initialization (here's an example).--strict-image-heap
requires all classes to be marked for build-time init that become part of the image heap. However, JUnit provides various mechanisms that allow users to pull in their own classes. One such mechanism is@ParameterizedTest
with its@ValueSource
and@EnumSource
. The moment an object becomes part of the heap of a user-defined type, native testing fails because those types also need to be explicitly marked for build-time init.Generally, we are aiming at keeping the use of build-time init at a minimum (e.g., oracle/graal#7488), so it makes sense to revisit our JUnit support and reduce or even avoid the use of build-time initialization.
This probably means that test discovery also needs to run at run time, unless it can somehow be pre-computed at build-time and stored in such a way that user-defined types cannot end up in the heap. However, it also probably means that we need to register all methods for reflection that JUnit can potentially access reflectively (e.g., to instantiate and run a test case).
The text was updated successfully, but these errors were encountered: