Nick Mancuso

This seems like an improvement to me, as long as coverage is properly reported by Jacoco. Do we currently have suppressions in pitest.sh like this?

@Vyom-Yadav let's do this: since we have separated execution of pitest and generation of pitest report out of your groovy script, let's also remove pitest execution and report generation from...

We will allow #11972 to close this issue, and open more granular issues as we need to.

I am on it, updating for AllSinglelineCommentsTest

> Why does execute use the traditional way of building configurations and not the … The “check” that I created it for was not a real check, we just needed...

@arinmodi See comment at https://github.com/checkstyle/checkstyle/issues/11446#issuecomment-1272458268 as example, just say you are on a test and send PR, no need to ask.

> I think it is up to user to decide what java version they are using and do they need it or not. So I suggest to do not try...

> Execution of this Check on code base before jdk17 will create a lot of confusions. Implementation at https://github.com/checkstyle/checkstyle/pull/10804 requires that user add `STRICTFP` token to their config manually, it...

> It is more logical to make "jdkVersion" field, it has a lot of potential As TreeWalker property, as @pbludov mentioned [above](https://github.com/checkstyle/checkstyle/issues/10798#issuecomment-922429238) ? Or just to this check?

> TreeWalker is not responsible for printing violations of JDK version. I think the idea was to have TreeWalker property like: ```xml ``` so that during check module initialization, TreeWalker...