Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] IntelliJ's OpenAPI / PSI platform.

From my experience, in language communities the people working on a language server (or on a similar tool but more restricted in scope, like a code completion tool), they prefer to work on the same language as they are targeting. As such, using OpenAPI and Java would not appeal to most of them.

Rather, in my view the big gain of abstracting OpenAPI from IntelliJ would be enabling ports of already-existing OpenAPI-based engines like the Go or Rust ones that I mentioned before. But there are also other ones for other languages: Scala, Groovy, etc., that are all licensed in some Eclipse-friendly license - and developed by Jetbrains.
So all those engines would be readily available for other IDEs if exposed under a LSP interface. One does wonder if such task would indeed be that easy/feasible technically: this would give away a lot of IntelliJ's value, since one of it's core strengths (the OpenAPI enabled engines), would not longer be tied to IntelliJ IDE itself. I'm not sure they would be that happy to keep paying developers to work on language engines that other IDEs would end up using for free.

Such experiment is not for me though (not on my volunteer time at least), I already have my hands tied to a lot of IDE related projects and tasks. Also, my main language of interest is Rust - for which I don't think the OpenAPI-based engine approach will be better than a native language server, given Rust's complexity (and given that the Rust team themselves have expressed interest in developing a language server).

But maybe it could be an idea for the Eclipse Ché guys. :) After all, the Go language is popular enough that one could consider it mainstream already, and it's also very focused on cloud and server-based apps, just like Ché infrastructure, so it seems it might be a good fit.

In any case, I guess we need to wait and have LSP mature and gain more popularity/support first of all.

On 16 August 2016 at 12:49, Mickael Istria <mistria@xxxxxxxxxx> wrote:
Hi Bruno,

So far I've never heard of any integration between Eclipse and some IntelliJ APIs. Since the community parts of IJ are in an Eclipse-friendly license, there is no reason to avoid that, so if anyone thinks it's valuable for Eclipse to use JetBrains OSS APIs, I guess it would be totally fine (and better than re-implementing the same thing).

As part of the topics of Platform UI for Oxygen, there's a part about making it easier to integrate new languages in the IDE. The idea is to work on a generic code editor which can understand extensions for the main code editor operations (highlighting, completion...) and enable the right ones according to the file's content-type (see ). This would allow to make the language engine (responsible of parsing, inference, building, whatever) a blackbox for the editor, and to allow a single editor to pick its features from different engines.
A Go engine based on OpenAPI would be a good candidate to provide such features for Go files as extensions for the generic editor.

About making an implementation of the language server based on OpenAPI, that would be a good idea I guess. However, I have no idea of how difficult that would be. However, the progress on the topic of language servers seem to make it worthy to introduce this indirection.

Note that if you compare to how other tools (Sublime, VSCode...) are doing, consuming some external applications such as gocode, guru... to provide IDE features seems to be a more sustainable idea. Indeed, those CLI applications are often more sustainable that an IDE-specific parser. However, that's specific to the community which is around the target language.

If you get deeper into experiments, please keep us in touch.

Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets

ide-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit


Back to the top