Tim van der Lippe

> will allow for more strict tests We shipped strict mocks to support this feature (https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/Mockito.html#40). Would that work for you?

> Caused by: java.lang.InternalError: class redefinition failed: invalid class Indicates that your class is corrupt. You should cleanup the class output and recompile with the JDK to fix the inconsistency.

I think the correct usage should be `Mockito.withSettings().useConstructor("hi", 1, c)`, would that work? In case you want to specify multiple, it would become `Mockito.withSettings().useConstructor("hi", 1, c1, c2)`.

Yes I think that makes sense. All packages except anything in `org.mockito.internal` are implicitly exported. Do you mind sending us a PR adding the necessary files? Thanks!

Hm, I am not sure, as we are using typical stock Gradle. Would it maybe be better if we have hand-written `module-info.java` files that we then check during build to...

I am not 100% sure what the impact of the `module-info` files are. I know JUnit5 ships them and I think for those users that want to consume Mockito with...

For JDK 17+, we are planning to switch to `mockito-inline` as the default mockmaker (#2589) as the subclass mockmaker indeed is not sufficient for these versions. Therefore, I think we...

https://github.com/mockito/mockito/blob/95b43e50101af2e598d247c618e334d0a6d8093e/src/main/java/org/mockito/internal/exceptions/stacktrace/StackTraceFilter.java#L75 is supposed to make this fast if the JVM supports it, but I am not sure if that still works. #2225 was supposed to fix it, but I had...

This is an interesting edge case and I fear that Mockito has little opportunity to do something here, given that we explicitly subclass the original class. In other words: we...

Good question! The intention was to switch the default in Mockito 4, but after user feedback, we decided to postpone that decision. That said, I do think we should have...