Change to QueryExecutor and RequestResultProcessor interface is not backwards compatible
Answered
Hi,
I'm trying to make my plugin compatible with the 2018.2 EAP version and I'm stuck with a problem. In the QueryExecutor and RequestResultProcessor interfaces, the first generics parameter changed in a way that is not backwards compatible and the compiler throws the following error:
error: name clash: processQuery(SearchParameters,Processor<? super PsiElement>) and processQuery(SearchParameters,Processor<PsiElement>) have the same erasure
I'd like to keep my plugin compatible with at least the most recent two major versions. Since 2018.2 has not been released yet, would it be possible to implement this change in a different way?
Hopefully someone from the Jetbrains team can give some feedback on this issue.
Ciao, Victor.
Please sign in to leave a comment.
Hi Victor,
introduced *IndexId* should not break any compatibility. Could you elaborate please?
AFAICS, the easiest way to make it backwards compatible would be to rename the affected methods. That way consumers of the API could simply implement the new method and leave the old one as is.
Hi Victor-
Unfortunately, adding new method was not an option.
This change is binary compatible, so if you update your sources accordingly, you will still be able to run the plugin with older version of IntelliJ.
Hi Daniil,
yes, you're right. I already figured that myself in the meantime. I was building and running tests for my plugin on a CI server, which was compiling the source for each supported version of IntelliJ. This was obviously failing due to compile-time incompatibility of the change.
I changed my project setup now to build for the latest version and only run tests for each supported version, which works flawlessly. It's a superior setup anyway, because now I'm really checking compatibility on a binary level.
On another note, I think I discovered a binary incompatible change between 2017.1 and 2017.2 that is not listed in the documentation: http://www.jetbrains.org/intellij/sdk/docs/reference_guide/api_changes/api_changes_list_2017.html
The `IndexId` class was added as a base class for index IDs and my tests now fail with a `NoClassDefFoundError`, because the base class cannot be loaded by the class loader.
Ciao, Victor.
Hi Dmitry,
the introduction of IndexId itself was not a breaking change, but the fact that com.intellij.util.indexing.ID extends it. At runtime, the class loader is not able to load the base class of ID, because it simply doesn't exist.
Ciao, Victor.