intellij-community.master build breaks ActionManagerEx API
Changes in the lastest intellij-community master branch, updated this morning, break ActionManagerEx API by adding an argument to function without default and without java overloads.
Is it the expectation that third party plugin developers build latest intellij-community to make sure no breaking API changes sneak into the code?
From previous experience, these things happen on an almost a regular basis, see latest examples: https://intellij-support.jetbrains.com/hc/en-us/community/posts/11323711731346-ProjectPlainTextFileTypeManager-getFiles-is-deprecated-replacement-PersistentFileSetManager-getFiles-is-package-private, https://intellij-support.jetbrains.com/hc/en-us/community/posts/11324174701970-Deprecated-EditorWindow-INITIAL-INDEX-KEY-with-replacement-marked-as-ApiStatus-Internal. Even building latest intellij-community does not provide assurances but is better than nothing.
This is what I called "chasing the API" that takes 80% of plugin maintenance time. Someone commented to me about being familiar with coding to "Quantum APIs", which I think is an appropriate nickname for these cases.
Keep in mind, that these breaking changes when they make it into a release, even if promptly addressed by the next release, have to be worked around in plugins, otherwise the plugin is broken for that release. This "hunt for a workaround" takes hours if one can be found, and creates brittle, unnecessary code in the plugin that remains there as noise until the errant IDE release is no longer supported by the plugin.
The solution to create a plugin per build is only viable for JetBrains bundled plugins. Third party plugins cannot be released until after the official release, meaning that the plugin will not be available for the release and users complain.
Please sign in to leave a comment.
We verify all API-changes on all release branches and master against all plugins published on JetBrains Marketplace on our side, so usually we do catch such (accidental) breakages. What plugin/version is affected by above change?
Hi Yann,
It is the version I am working on right now. So it is not published.
The same issue would apply to in-house third party plugins, of which there are a lot out there.
Correct, these are known problematic areas where we currently have no insights.
Hi Yann,
You have been a third party plugin development champion for a long time. I also suspect that you had the responsibility, but not necessarily the authority nor resources to make the impact you wanted.
I hate sounding like I love to bitch and complain, I don’t. I try to find my own workarounds and solutions as much as I can without bothering JetBrains devs nor support.
I can see how much effort JetBrains has put into supporting third party plugins and can only imagine the added costs in both time and money this adds. At the same time, for years, I was on the other end of this relationship and have my own battle scars, PTSD flashbacks and stories to share around the developers’ campfire.
There are no perfect solutions, only trade-offs based on pros, cons and constraints.
Adding sufficient time for developer feedback in the release cycle is out of the question. The only available choice is to add an option the users can add to their build in plugin verifier task, to register detected API use with JetBrains. This would give you insight into upcoming third party plugins and in-house plugins. Not a perfect solution, but probably better than nothing.
On JetBrains end, the only thing I would like so see is an e-mail informing that API use such and such, in plugin X, file Y will be broken by an upcoming release/build going through the pipeline. There will be a lot of false positives as API changes may be rolled back or corrected in later builds on both ends, but such is life with plugin verifier right now, spewing out a long list of internal, deprecated and experimental API uses, whether there is an alternative or not.
A clear, official policy on API stability, changes and third party plugin development support would go a long way to clear the air. My own experience depended heavily on the developer doing the mods, their experience with JetBrains API use and their attitude towards outside dependencies and feedback. Right now there are no guidelines to go by for everyone involved.
Adding experimental, internal or other such mechanisms is sadistic, because without a clear policy all your APIs might as well be annotated internal and experimental. Why? Because there is no clear picture of what should be exposed or hidden from third party plugin use. Erring on the side of hiding everything, just makes the API useless in many cases, especially when adding functionality not originally envisioned by the API author.
Experimental APIs? Aren’t they all experimental when they come out? Many will likely transition from experimental to deprecated as the API evolves to better, faster, next perfect implementation (a bit of sarcasm to vent the accumulated frustration.)
My use of internal APIs is not on a whim but out of not finding public API options to solve a problem. A problem most of the time arising from another API change, or IDE bug, or user request. I either found no solution, or have asked and was told there is no other solution.
I don’t like brittle code, but having a broken plugin is worse. However bad it is for JetBrains, on my end I wind up having to maintain that “back-alley-abortion” of a solution until the issue is solved and I no longer maintain compatibility with the problem release(s).
On my end, I want to release a version of Markdown Navigator Enhanced with compatibility fixes, where possible, to address IDEs from 2021.3 up to 2023.1.1, which I can verify work. This release will be unlicensed and available to previous licensed users and everyone else.
It will buy me time to figure out whether I want to commit to supporting the plugin in the future as a paid plugin or bite the bullet and give up on the effort as economically unsustainable. In either case, many disgruntled users will have use of the plugin for another year or two.
Hi Vladimir,
Regarding
ActionManagerEx, the old method has been reverted in the master branch.Hello Vladimir Schneider, thanks for your detailed insights and thoughts. We're evaluating various ways on how to improve 3rd party developers experience via Plugin Verifier for plugins not published on JetBrains Marketplace.
Thank you both for your support. It is much appreciated, even through it must feel at times that your job is to stand in front of the proverbial fan.
Hi,
To clarify "reverting" the method, I wasn't precise enough. Binary compatibility was recovered, but the method has slightly different behavior.
Before the change, all the toolbars were *customizable (this behavior was introduced in February 2022 - it was a bug), and now they are not customizable by default. If you need customization, you have to use the new method.
*customizable - right-click showed action to remove some toolbar buttons.
Thank you Karol. I understood it as such.