As @Module is absent from the Kotlin flavor of jMolecules, code that refers to that is now guarded with a more specific check for that type in particular.
Both ModuleContextCustomizer and ModuleTypeExcludeFilter contribute to the calculation of the context configuration which the Spring Test Context Framework uses to decide whether it's necessary to create new ApplicationContext instances.
Both of them previously used a Supplier<ModuleTestExecution> to calculate equals(…) and hashCode() which -- by definition -- does not result in the same result even when created with identical input. We now rather use the source class instance eventually backing the ModuleTestExecution, as that is the internal cache key in turn.
We now additionally guard the completion query by event and target identifier to also only apply to publications that have not been completed yet. This will allow databases to optimize the query plan to apply simple comparisons (the date being null) over complex comparisons (the event payload) to reduce the intermediate results to process further and thus improve performance.
If named interfaces are declared in nested packages, the name detection might accidentally pick up the names declared in child packages. We now deliberately only inspect the base package.
As we process a type's entire type hierarchy for dependencies we might discover a foreign module's internal dependencies for modules that declare allowed dependencies explicitly. Explicitly declared dependencies so far solely verified the target being explicitly listed, which, for internal dependencies does not make sense. We now immediately start checking the source and target modules to be equivalent, in which case we can skip any further processing.
We're now registering a customizers for both the SimpleAsyncTaskExecutor (used for virtual threads) and the ThreadPoolTaskExecutor to register a ContextPropagatingTaskDecorator.
