search

UnitTestBot / UTBotJava

Automated unit test generation and precise code analysis for Java
Apache License 2.0
132 stars 40 forks source link

Custom open modules windows #1139

Open Domonion opened 1 year ago

Domonion commented 1 year ago

Description Starting from JDK17 there are no special cli switch illegal-access which opens for reflection all jdk internal modules such as java.base - ref.

UtBot requires some internal jdk modules to be open for reflection. Current set of modules are available here. This set is used every time EngineProcess is started.

However, there can be many other modules which are used via reflection either directly or indirectly. Accessing them would break UTBot. Although we have OpenModulesContainer, it cannot suffice because:

  1. User code might have it's own modules
  2. User code might access internal modules in unpredictable way
  3. There are additional JDK providers which differs by JDK vendors - see #1138.

All 3 options implicate that whatever set of open modules we use - it is still possible for UTBot to access modules closed for reflection. This will break UTBot execution.

To mitigate that problem I propose to provide user a tool to customly set required modules open. The motivation is that user have much better understanding of the project UTBot is used on. In case if our module list is incomplete - he will manully provide additonal modules.

This feature involves:

denis-fokin commented 1 year ago

If we are discussing the generated tests, we have information about incorrect modules set-up even on concrete execution's phase. We can use this information to specify open modules automatically (on the fly).

Maybe we can employ module-info.test or module-info.java (probably this article can help https://sormuras.github.io/blog/2018-09-11-testing-in-the-modular-world#white-box-modular-testing-with-extra-java-command-line-options)

tyuldashev commented 1 year ago

@denis-fokin module-info.test seems not the best option, because that's unofficial suggestion and is not supported by tools out of the box (see for example discussion, especially last comment, for IDEA ). Also one maybe don't want to modularize his own project, so adding module-info.java/test would make more harm than good. For now I would suggest to disable such problematic cases and add some type of the comment, what's needed to be 'fixe' in project configuration.

UPD: actually for generated tests there is dedicated case #2026