Adding missing @Override annotations. Some refactoring

[unv-unv]

No description provided.

[unv-unv]

@claude review pr with inline comments

[VISTALL]

@claude review pr with inline comments

[github-actions]

Claude finished @VISTALL's task in 3m 28s —— View job

---

PR Review: Adding missing @Override annotations. Some refactoring

• Gather context (read changed files)
• Review changes for correctness & style
• Report findings

---

Overall this is a clean, low-risk cleanup: added @Override annotations, converted tabs→spaces in the junit-rt runtime classes, and extracted a couple of helper methods. I read the substantively-changed files and found no correctness regressions. A few minor, optional notes below.

⚠️ On inline comments: I was asked to post inline review comments with suggestion blocks, but I can't in this run — the shell environment is misconfigured (HOME resolves to an unwritable /home, so the sandbox wrapper bwrap fails to initialize and every git/gh/gh api command errors out). There's also no MCP tool exposed for creating PR review comments. So the review is anchored by file:line below instead. To enable real inline suggestions next time, the runner's HOME/allowed-tools need fixing so gh api .../pulls/{n}/comments can run.

---

Minor / optional

1. JUnit4Framework.java:105-110 — indirection helper adds no value

The refactor splits out a private overload, but it's only ever called once, with the two arguments hard-wired to constants:

protected PsiMethod findOrCreateSetUpMethod(PsiClass clazz) throws IncorrectOperationException {
    String beforeClassAnnotationName = JUnitUtil.BEFORE_CLASS_ANNOTATION_NAME;
    String beforeAnnotationName = JUnitUtil.BEFORE_ANNOTATION_NAME;
    return findOrCreateSetUpMethod(clazz, beforeClassAnnotationName, beforeAnnotationName);
}

Since beforeClassAnnotationName/beforeAnnotationName are always the same constants, the parameterized overload doesn't buy any reuse — the body could just reference the constants directly and drop the extra method. Not a bug, just dead flexibility. Fix this →

2. JUnit4Framework vs JUnit5Framework — inconsistent modernization

This PR touched both, but JUnit5Framework.java:132 was modernized to Application.get().isUnitTestMode() + CommonLocalize.titleWarning().get() (plus @RequiredUIAccess/@RequiredWriteAction), while JUnit4Framework.java:129 still uses the older ApplicationManager.getApplication().isUnitTestMode() + CommonBundle.getWarningTitle(). Since they were both being cleaned up, aligning JUnit4 to the same APIs would be consistent. Optional.

3. JUnit45ClassesRequestBuilder.java:77-89 — pre-existing shadow + dead null-check (not introduced here)

Method ignored = BlockJUnit4ClassRunner.class.getDeclaredMethod("isIgnored", FrameworkMethod.class);
if (ignored != null) { ... }
...
catch (NoSuchMethodException ignored) { }   // shadows the Method `ignored` above

getDeclaredMethod never returns null (it throws NoSuchMethodException), so if (ignored != null) is always true, and the catch parameter reuses the name ignored. This predates the PR, so it's out of scope — just flagging while it's in view in case you want a follow-up.

---

Verified as correct

• IdeaSuite, JUnit3IdeaTestRunner, JUnit4IdeaTestRunner, JUnitForkedSplitter, RunOnce, JUnit4TestRunnerUtil, TestClassFilter — the @Override additions all correspond to genuine supertype/interface methods, and the whitespace/formatting changes preserve behavior.
• TestClassFilter.getCompilePattern(...) extraction is behavior-preserving.

Nice cleanup overall — the notes above are all optional polish, nothing blocking. ✅
· branch overrides