As raised by the IntelliJ verifier ran on the Marketplace, we use some APIs that we should not use. They are either marked as scheduled for removal, internal or deprecated.

The biggest risk is if some API is removed in a future version, our plugin could crash badly. Generally there is a replacement API that is mentioned in the doc of the offending API.

The full list is the following:

13 internal API usages
Internal methods usages (8)
PlatformUtils.isRider() (4)
PlatformUtils.isCLion() (2)
Module.getModuleFilePath() (1)
PlatformUtils.isAppCode() (1)
Internal classes usages (5)
PlatformUtils (5)

17 usages of scheduled for removal API
Scheduled for removal methods usages (16)
NotificationGroup.createNotification(...) (11) (scheduled for removal in a future release)
NotificationGroup.balloonGroup(String) (5) (scheduled for removal in a future release)
Scheduled for removal constructor usage (1)
NotificationGroup.<init>(...) (1) (scheduled for removal in a future release)

37 deprecated API usages
Deprecated methods usages (20)
GuiUtils.invokeLaterIfNeeded(...) (3)
PopupHandler.installPopupHandler(...) (2)
PluginManager.getPlugin(PluginId) (1)
RecentProjectsManager.getRecentProjectsActions(...) (1)
ActionUtil.performActionDumbAwareWithCallbacks(...) (1)
ServiceManager.getService(Project, Class) (1)
ServiceManager.getService(Class) (1)
PluginDescriptor.getPath() (1)
EffectiveLanguageLevelUtil.getEffectiveLanguageLevel(...) (1)
Project.getBaseDir() (1)
Messages.showYesNoDialog(...) (1)
Comparing.equal(String, String) (1)
IconLoader.getIcon(String) (1)
Refreshable.refresh() (1)
LinkLabel.create(String, Runnable) (1)
GuiUtils.invokeLaterIfNeeded(...) (1)
HyperlinkLabel.setHyperlinkText(...) (1)
Deprecated classes usages (16)
ActionLink (6)
PasswordUtil (4)
Queue (3)
ProjectFileIndex.SERVICE (2)
ModuleServiceManager (1)
Deprecated interface usage (1)
DialogWrapper.DoNotAskOption (1)