id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
23729	Investigate moving from jmockit to something actively maintained	taylor.smock	team	"jmockit is no longer maintained. While I don't think it is going to break anytime soon, I ''do'' think it is highly likely to break in the next few years. Specifically, it (apparently) uses a customized fork of ASM, and that is highly likely to break at some point.

I'd rather start working to replace it now (when it isn't broken) than have to replace it suddenly when ''something'' breaks it.

There was some discussion in #16010 about whether or not we should try using mockito instead of jmockit. Of note:
* jmockit only had one developer who appears to have abandoned the project
 * There is a fork at https://github.com/hazendaz/jmockit1 (do we want to use that instead? they've integrated some of our PRs against jmockit and seem to be active)
* jmockit supports ""global"" mocks
 * We'd apparently have to do a lot of work to get mockito working properly (specifically, we'd have to fiddle with dependency injection)
 * mockito does support thread-local mocks now (apparently), so this ''might'' be ""good enough"" since we really only have three threads we care about most of the time (MainApplication.worker, EDT, and the JUnit thread). See [https://github.com/mockito/mockito/blob/main/src/main/java/org/mockito/MockedStatic.java MockedStatic].
* jmockit supports ""private"" method mocks (but so does mockito + powermock; powermock isn't supported anymore though)
 * We mostly need private method mocking due to some of our tests hitting UI codepaths. Maybe we should fix those? Maybe with something like `BooleanSupplier`/`IntSupplier` for answers to UI questions?

Potential plans of action:
* Add dependency on `mockito` and start moving tests to it
* Switch jmockit from original author to hazendaz
* Remove need for (most) mocks by adding parameters that will call the UI codepaths in the UI, but otherwise return a specified value

Example of the last point:
{{{
#!java
public static void combineWays(Collection<Way> ways) {
    // Do stuff
    // Then ask question
    if (ConditionalOptionPaneUtil.showConfirmationDialog(...)) {
        // Finish doing stuff
    }
}
// Versus
public static void combineWays(Collection<Way> ways) {
    combineWays(ways, () -> ConditionalOptionPaneUtil.showConfirmationDialog(...));
}
public static void combineWays(Collection<Way> ways, BooleanSupplier checkConfirmation) {
    // Do stuff
    // Then ask question
    if (checkConfirmation.getAsBoolean()) {
        // Finish doing stuff
    }
}
}}}

An important note is that none of the potential plans of action are ''exclusionary''."	task	new	normal	Longterm	Core