Hi, I’m wondering why PluginManagerCore.getPlugin(id: PluginId?) is Internal in IJ 2026.2 EAP. I’m using it since a long time to read the version of my plugin, which is very useful when generating an error report. The commit that added @Internal: [plugins] IJPL-244315 Do not allow plugins to enable or disable plugins via PluginManagerCore GitOrigin-RevId: 7b3bbd9dc2769784e0bee284b8eb86faeb77d447 I understand that we should not be able to enable or disable a plugin (and the corresponding methods are now deprecated), but removing access to getPlugin may be too much. I can’t find a replacement method to read the version of an installed plugin. Some help would be appreciated. Thx

PluginManger still allows accessing the descriptors, as it delegates to PluginManagerCore. Accessing other plugins‘ descriptors would still be useful, even if read-only. Wouldn‘t there always be ways to abuse reflection? To read the own plugin‘s descriptor, there‘s PluginAwareClassLoader, but I‘m not sure if that‘s the best, recommended way…

[image] Joachim Ansorg: Accessing other plugins‘ descriptors would still be useful, even if read-only It is usually OK to know everything about plugins, what is not good is access to their Plugin classloader

[image] Joachim Ansorg: Wouldn‘t there always be ways to abuse reflection? We take this seriously, such usage (reflective access to other plugins) is a road to ban in the Marketplace

Thx. For now, I think I will read the plugin version from my plugin.xml (the good old getClass().getResourceAsStream("/META-INF/plugin.xml"))). I’m not sure if it works in all cases, but it will allow me to support both older versions (2025-2026.1) and newer versions of the IDEs.

We will follow up with proper APIs in master to read all information on plugins, versions, descriptions, etc, as those are no secret

Good idea! Just tried and it seems to work well.

Disabling plugins I think a valid use case to turn off or disable other plugins is, when several provide the same functionality and thus should not be installed at the same time, like file types for the same extensions, run configuration overlap, and more. For example, BashSupport Pro and the Shell plugin provide a similar set of features. If possible, both should not be used and installed at the same time. For better UX BashSupport Pro has a wizard to let the user decide if Shell should be disabled or not. With the changes of 2026.2, this won‘t be possible anymore. Is a clear, user-initiated action a valid use case to disable another plugin? If not, what do you recommend? Asking the user „please close this dialog, go to settings, locate the plugin X, click disable, then restart“ seems not like good UX or a good alternative to me. I can‘t use „incompatible with“, because some IDE’s features (iirc, e.g. CLion + Makefile support, others) depend on Shell. Accessing classloader There‘s another case not possible anymore with 2026.2 for me: Because BashSupport Pro is providing Shell run configuration compatibility, it unregisters Shell‘s runConfigurationProducer via „ExtensionPoint.unregisterExtension(Class)“ when both are enabled. The method variant with „class“ is used to prevent instantiating the extension unnecessarily. To locate the class without instantiating the extension, I access the classloader of the other plugin (but not using reflection). Not doing this would make two providers for the same run configurations available at the same time, which ends up with unpredictable results, bad UX, exceptions and more. I‘m not sure which usages made JetBrains restrict the API this much, I just hope there‘s a way to allow the valid use cases while still preventing abuse… Thanks! Joachim

We know that, but it ultimately requires user attention and approval and may not be allowed to plugins to do silently

[image] Joachim Ansorg: Not doing this would make two providers for the same run configurations available at the same time, which ends up with unpredictable results, bad UX, exceptions and more. I hope we can just introduce a switch-off toggle extension on our side in the Shell Script plugin so you can signal the built-in extension to unregister

PluginManagerCore.getPlugin is now Internal

IntelliJ Platform

jansorg (Joachim Ansorg) May 16, 2026, 2:09pm 9

Why not just cast the classloader of one of your own classes to PluginAwareClassloader and get the version from there? That should work for old and new…

PluginManager now has all methods as internals

Topic		Replies	Views
2026.2 and now internal PluginManager API IntelliJ Platform api , eap	18	468	July 14, 2026
PluginManager now has all methods as internals IntelliJ Platform	9	254	June 19, 2026
47 internal API usages - how enforced is this requirement? Plugin Verifier	24	372	August 22, 2026
Stricter plugin verification in IntelliJ Platform Gradle Plugin 2.15.0 Announcements plugin-development , intellij-platform-gr	15	444	May 25, 2026
Keeping plugins compatible IntelliJ Platform	0	1240	February 10, 2025

PluginManagerCore.getPlugin is now Internal

Related topics