How should I make a plugin for both IDEA 7.x and 8.x ?

Hello,

I wonder what's the best approach to code a plugin that will work with both IDEA 7.x and 8.x (and newer versions later)?

For instance, how to get the ConstantEvaluationHelper differs between the version and there is no common way to get it...

IDEA 8.x: JavaPsiFacade.getInstance(project).getConstantEvaluationHelper()
IDEA 7.x: PsiManager.getInstance(project).getConstantEvaluationHelper()

Will you generally make those kinds of backwards compatibility breaking changes?

Note, there are other examples of broken APIs in 8.x. I just want to know how I should handle this so I don't have to manage several code bases. Reflection?

Cheers,
Mikael Grev

7 comments
Comment actions Permalink

Hello Mikael,

The breaking changes in 8.x were more extensive than what we usually do,
and I hope we won't have to break things at such a scale again soon. Using
reflection can be good if there's a small number of APIs that are different
between versions. A more scalable approach is developing a facade module
around the IDEA APIs, having multiple versions of the facade for different
versions of IDEA, and coding the plugin core against the facade.

I wonder what's the best approach to code a plugin that will work with
both IDEA 7.x and 8.x (and newer versions later)?

For instance, how to get the ConstantEvaluationHelper differs between
the version and there is no common way to get it...

IDEA 8.x:
JavaPsiFacade.getInstance(project).getConstantEvaluationHelper() IDEA
7.x: PsiManager.getInstance(project).getConstantEvaluationHelper()

Will you generally make those kinds of backwards compatibility
breaking changes?

Note, there are other examples of broken APIs in 8.x. I just want to
know how I should handle this so I don't have to manage several code
bases. Reflection?


--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Thank you for your answer Dmitry,

I would expect that anyone that have a public API not break that API between versions, it is generally how things are done.
I find it very strange that Jetbrains do, but I guess you have enough plugins as it is.

Cheers,
Mikael

0
Comment actions Permalink

OTOH, there are MAJOR versions right ?

And as far as I'm concerned (only dealing with VCS integrations as of yet), the migration is quite straightforward, so if this allows for a better IDEA I'm all for it

0
Comment actions Permalink

Still, it means that the API users (plugin creators) have to create those facades that should be made by the API vendor, if they choose to change the API.

Please read "Effective Java" or any other serious book about Java and you'll see that the common consensus is that you never ever change the public API unless it is absolutely necessary to fix bug, and even then you just deprecate the old API.

Anyway, I don't want to quarrel, I know how it is now and will adjust accordingly.

Cheers,
Mikael

0
Comment actions Permalink

Hello Mikael,

Please read "Effective Java" or any other serious book about Java and
you'll see that the common consensus is that you never ever change the
public API unless it is absolutely necessary to fix bug, and even then
you just deprecate the old API.


Please understand that the reason why we're breaking the APIs is not the
fact that we haven't read enough serious books about Java or that we're unaware
how things are done.

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Given the extremely high quality of IDEA, the IDE, I did not think so.

I love IDEA as a developer and I'm just getting to know it through the plugin architecture as well. I was surprised though.

Mikael

0
Comment actions Permalink

Sorry if my remark felt aggressive, it was not meant to be. My point was that considering the general quality of IDEA product, I guess that those changes would not have been done without a good reason :)

0

Please sign in to leave a comment.