SLI-2750 Remove usage of internal or scheduled for removal APIs

[damien-urruty-sonarsource]

Summary

• Replace IntelliJ Platform internal and scheduled-for-removal API usages for 2026.2 compatibility
• Keep the dogfood PluginRepositoryAuthProvider for now and ignore it in the plugin verifier
• Detect optional IDE modules via public APIs (PluginAwareClassLoader, SonarLintUtils, FileTypeRegistry) instead of PluginManager.findEnabledPlugin

[hashicorp-vault-sonar-prod]

SLI-2750

[gitar-bot]

Code Review ✅ Approved 3 resolved / 3 findings

Removes usage of internal and scheduled-for-removal IntelliJ platform APIs to ensure 2026.2 compatibility, addressing findings around hardcoded FileType names and test version fallbacks. No open issues found.

✅ 3 resolved

✅ Edge Case: Language detection relies on fragile hardcoded FileType names

📄 src/main/java/org/sonarlint/intellij/core/EnabledLanguages.kt:192-205
Module detection was switched from PluginManager.findEnabledPlugin to matching hardcoded FileType names ("JAVA", "Go", "SQL") via FileTypeRegistry.findFileTypeByName. If any of these registered FileType names differ from the assumption or are renamed by a future IDE version, the lookup silently returns null and the corresponding language (Java/Go/PLSQL) is quietly disabled with no error or log. Consider verifying each name against the actual FileType registered by the target plugin, and/or logging when an expected module is not detected so silent regressions surface. Note the Jupyter branch uses getFileTypeByExtension("ipynb") while others use findFileTypeByName, an inconsistency worth aligning.

✅ Bug: LanguageSpecificRequirements second arg changed null → false

📄 src/main/java/org/sonarlint/intellij/core/BackendService.kt:382
The second argument to LanguageSpecificRequirements(jsTsRequirements, ...) was changed from null to false. This is a semantic change unrelated to the internal-API removal goal: if the backend treats null as 'unset/use default' and false as 'explicitly disabled', this could alter behavior. Confirm this change is intentional and that false is the desired value for this flag.

✅ Quality: getVersion() silently returns "test" outside unit tests

📄 src/main/java/org/sonarlint/intellij/SonarLintPlugin.java:41-55
When the descriptor cannot be resolved, getPath() explicitly guards on ApplicationManager.getApplication().isUnitTestMode() and otherwise throws IllegalStateException, but getVersion() unconditionally falls back to TEST_VERSION ("test"). In a production state where the classloader is not a PluginAwareClassLoader, the version would silently degrade to "test" (e.g. polluting telemetry) instead of failing loudly. Consider gating the TEST_VERSION fallback on isUnitTestMode() so non-test failures surface consistently with getPath().

Implementation Status ✅ 1 / 1 issues implemented

✅ SLI-2750 — 2 / 2 objectives

The PR removes usages of internal and scheduled-for-removal platform APIs, replacing them with alternative approaches like OptionalPluginMarker extensions, PluginAwareClassLoader, and modern method signatures.

✅ 2 complete

• ✅ Remove usage of internal APIs including PluginManager.findEnabledPlugin and PluginRepositoryAuthProvider
• ✅ Remove usage of APIs scheduled for removal including TextFieldWithBrowseButton, AnActionEvent, ContentManager, SimpleListCellRenderer, LanguageSpecificRequirements, and ActionButton.HIDE_DROPDOWN_ICON

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
3 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
43.4% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube