Tooling for IntelliJ Platform Plugins
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Cébron, Yann
Open sourced under Apache 2 license, IntelliJ Platform is the base for a number of well-known IDEs. It supports a large variety of languages and technologies via bundled plugins as well as thousands of third-party plugins. This talk will showcase the tooling and ecosystem for plugin developers, covering the whole lifecycle of creation and maintenance. We'll start by taking a look at the IDE features for development and testing: smart code insight, highlighting, and refactorings. How to keep up with the latest platform releases? Plugin Verifier allows you to check for any incompatibilities locally as well as get reports for already published versions. The built-in exception reporter provides the data for the Exception Analyzer, which helps collect and (auto-)triage all user-submitted runtime problems.
 Good morning. Nice to have so many people here on Sunday morning. I didn't expect it actually. So my talk is about the IntelliJay platform. My name is Jancy Prandt. I work as a developer advocate for J-Brainz. And I'm responsible for everything around tooling, helping, plugin developers extending our IDEs and stuff like that. Please excuse my voice. I have a pretty bad cold since yesterday, of course. So maybe I need a few breaks in between. So what does this talk about? First, I want to introduce the IntelliJay platform on a very high level, basically. Who's using IntelliJay or any of the related... Oh, okay. So that's quite a lot of people who doesn't know anything about the IntelliJay IDEs. Okay, everyone has heard of them, at least. That's good. So that's the first part of this talk. A couple of slides. And after that, I want to show the actual tooling that we provide to plugin developers. And I will also demonstrate or show screenshots, at least, of some of the internal tools we use at JetBrains to make sure that plugin developers enjoy our platform. So we try to help them as well by using some internal tools and making sure that things work smoothly for everyone. So the IntelliJay platform came out of IntelliJay IDEA, the IDE, which used to be commercial IDEA only. We split that into community edition, which is completely open-sourced under Apache 2 license since 2009. And there's, of course, still the commercial IDE or other IDEA based on the IntelliJay platform. It's a JVM-based IDE, just like NetBeans and Eclipse. So we use mostly Kotlin, sorry, we use mostly Java, some Kotlin, or increasing amount of Kotlin, and a few bits here and there of Groovy Code as well. The user interface is actually built completely on swing, and most people are like, what, you can actually build like complex swing applications, yes you can. It is quite painful sometimes, especially when you want to support the same level across Mac, Linux, and Windows. But we are lucky enough that we have actually a couple of very talented people from the former swing team who now work for JetBrains and who built their own OpenJDK-based runtime, which we use for our IDEAs now. So that's another thing that is somewhat related to the IntelliJay platform. We use our own Java runtime based on OpenJDK, so it's also completely free for everyone, and we merge back to OpenJDK as well. One important distinction to make between IntelliJay and NetBeans and Eclipse is that the IntelliJay platform is not a generic framework, or not a framework for generic applications, so it is not intended to be used for like customer applications or anything that is not an IDE or something that is somewhat an IDE. And this is a very important point to make, so please don't try to do it. It is just too specialized, and it is pretty much impossible to rip out the parts which would just give you the basic layer for running an application and having some kind of UI. The last line on the slide is a link to a presentation which a colleague of mine made a couple of years ago, so it's a bit outdated, but it still shows like the whole evolution of the IntelliJay platform and how things work together or developed if you're interested in a bit more history. So how can you approach writing plugins for the IntelliJay platform? So the community repository is basically the IntelliJay platform. We have no distinction between the community edition of IntelliJay and the platform as such. It is one repository and one name. It's published on GipTap as well. We accept pull requests, any kind of feedback on that as well, of course. The second link is the SDK documentation. So that's some high-level docs around the IntelliJay platform which helps you learn it, understand all the different parts of it, and it also has some tutorials or self-lawn trails. Basically, for example, if you want to write a custom language plugin, there's a nice detailed introduction on how to approach this. JetBrains runs a couple of forums. One of them is specialized to help plugin developers or anyone building stuff on the IntelliJay platform. We do monitor this. It's actually one of my tasks to do this and try to help answer all the questions in a timely manner. There's also a Gitter community run. Jet were actually quite a lot of very active plugin developers hanging around as well. So if you need a quick answer, you might get lucky there as well. Sometimes I look there as well. If you want to keep up to date, we run a blog and Twitter account, of course, so you get all the high-level news about the IntelliJay platform. So, plugins. There's actually a quite huge number. Anytime I talk about IntelliJay platform, I have to go on our website, which lists all the plugins and look up the new number and it increases more and more. What kind of plugins can you build for IntelliJay? Well, basically anything that you can think of. One very popular category is, of course, like custom languages, any kind of framework support, any kind of web application support, for example. There's a lot of little tools, helpers, kind of stuff of plugins being published there as well. So it's a very broad offering that you have. And actually, most of them are open source or at least free for use. The plugins' website lists all of them, so that's one way to search for them. You can see all the different versions and stuff of them. We are going to take a look a bit later. Marketplace is a thing we are currently developing in JetBrains, which will help plugin developers to actually monetize the plugins if they want to. We are also considering using this platform for donation-based plugins. Maybe that's also something interesting for purely open source plugins as well in the future. Of course, you can build IDEs on IntelliJay platform. So there's a couple of them by JetBrains. We try to cover all the most popular programming languages, obviously. One of them is very interesting from the technical point of view, which is Ryder. It's a C-sharp.net IDE, which runs as well on Mac as on Linux. So that's something quite unusual in the.NET world. And it uses the IntelliJay platform just for the frontend. So only the user interface is run by the IntelliJay platform. It feels and looks like one of the IDEs, but all the code intelligence and all the real functionality is actually run by a second process, which runs resharper. And resharper is also a product which we have developed for a couple of years, which is originally a plugin for Visual Studio. So we kind of combined the two worlds into one product, which allows us now to run a Visual Studio extension cross-platform on all machines. Probably the most known IDE, which is not built by JetBrains, is Android Studio, which is like the official IDE for anything Android-based. It was built by Google based on the Android plugin we did before. There's also a couple of others. One of them is Cuba Studio, that's the web framework. And they basically provide a plugin, but as well a full standalone IDE for their specific framework. Building IDEs is, of course, much more complicated than building a plugin. So we usually recommend to build a plugin, and if the plugin involves into something bigger, then think about distributing it as a standalone IDE later. So now we come to the interesting developing parts. These are the points I want to show to them today. So the plugin development kit is, of course, a plugin in IntelliJ, which allows you or helps you write in plugins in IntelliJ. The Gradle IntelliJ plugin is actually a plugin for the Gradle build system, which helps you write plugins for IntelliJ. So you can use Gradle and actually highly recommend doing so now. I will show a bit more details later. The third one, GrammarKit, is specifically targeted at custom language development. So anyone wanting to support a new custom language should really try building it on GrammarKit. And the last thing is a maintenance tool, PluginVerifier, which helps you to ensure that the compatibility with newer or older versions of IntelliJ is actually guaranteed. So now let's switch to the IDE. And I want to show some basic features of the plugin development plugin itself in the IDE. So there's a couple of things. Basically, a plugin is built by the code, obviously, and all the components are registered in a pluginless drifter file, which is basically the XML file we are seeing here. It has all sorts of metadata, registration information, about the actual functionality that the plugin exposes. And we have built a quite sophisticated support for editing all this XML. So we can see all the components here, for example. We have some metadata about the plugin itself, like name, ID, compatibility information here, and stuff like that. And you have quite nice tooling support in the XML file itself. So we don't like wizards in the IntelliJ world at all. We try to avoid them. We try to build all the tooling based on textual editors, because we think it's usually faster to type stuff or use tooling that helps you type faster than using UI-driven wizards. So for example, I have two extensions here, which use the same extension point, so they provide a similar kind of functionality. And I have given them some kind of IDs. And this is interesting because then you can actually provide some kind of ordering for extensions. So for example, one extension can have priority over other extensions, your own ones or maybe even the built-in ones. So that's one way of overriding or extending existing functionality even from the platform. And we understand all of this. So we have auto-completion here, I can use GoTarget here, I can do a findUsages and stuff like that. Of course, all the extension points can be auto-completed here as well. We can even go to the declaration here, look at the actual interface, which provides this extension point and stuff like this. We can then go back to the registration of this extension point and stuff like this. So this is all very nicely integrated in the editor. And let's talk about compatibility because that's one very crucial point, which actually caused quite a lot of trouble in recent years, but I think the tooling we have now will help make things better. So we have three major releases a year now. We switched to that model some time ago. And you can actually see the release date from the number. So 18.2 is basically the second release in 2018. And 183, of course, is the third release in 2018. So if you want a very generic compatibility, that's very easy to do like this. But you can also provide the full build number if you really need some changes in some kind of later point release. The thing I did now was to violate the compatibility. So I specified 182 here. And actually, I cannot do this. It's a bit small to read. So basically what the message is saying is I'm trying to use an extension point from a platform release that is newer than the minimum version I specified in my plug-in descriptor. So I'm trying to use something that is not there, basically. And that's quite easy to fix because I can just change now the minimum version, go back and the warning will disappear because now it's okay. It's now compatible, right? And another thing we added in the tooling just recently is that we have now these annotations here, available since, which prints the exact build number when this class or even method was added to the platform so you can see when it will be available. What is the minimum version I need to specify in my plug-in to be able to use this class? So this information and the inspection really helps you to ensure compatibility even before deploying or trying your plug-in you will be warned right in the editor. There's a couple of other highlightings in the plug-in XML. For example, we require useful descriptions. Or if you just write one word, it will highlight this as an error because it's not useful for users to browse the plug-in list and have no decent description, stuff like that. Same if you try to use... Oh, no, it actually doesn't because I'm running in a special mode, but you would get the warning that you are not chat brains or you shouldn't specify chat brains as plug-in vendor, stuff like that. So we try to make all the appearance of plug-ins a bit more uniform and more useful for end users. There is a couple of other features we have. So writing plug-ins, of course, means writing tests. We prefer integration tests, so usually we fire up some kind of headless IDE instance and you test against this headless IDE instance. That's the way we usually write tests. So you need usually some kind of test data and then you perform some actions against this test data. For example, you have some file and some Java file and you want to test completion. You write this minimum Java file, you position the cursor at some specific point in the file and then you invoke completion and then you test the completion variants, which are shown are actually the ones you want to be provided. So you need some kind of navigation between your testing code and the test data. That's another feature that Plug-in Development Kit offers. For example, we have the special annotation here, test data pass. So we can navigate there and see the related test data here as well and navigate to the test data here. Okay, it's broken in this sample of course, but usually it works. There's another new feature which we are going to announce a bit more publicly later this month, which is a thinning in the IDE. So the whole UI can be basically, you can provide a custom theme for the UI, any colors, margins and stuff like this can now be customized. And that's also part of the Plug-in Development Kit to offer tooling support for this customization. As you can see, you get, for example, a preview for all the colors in your theme, but you also get completion for all the customization keys, for example. So that's about just some of the features we have in the Plug-in Development Kit. Now I want to show a bit of the Grammar Kit. So how do you write custom language support in IntelliJ? Basically, you need a lexer which lexes the file into tokens, and then you need the parser which builds on top of that. This is what Grammar Kit offers you for tooling, so it's very easy to write a lexer and as well basically generate a parser based on some BNF notation for the parsing. And I will make this part a bit shorter because time is tight here, but you have all sorts of tooling support here for writing the parser BNF file, generate the parser code. We can even do a live preview of our parser without actually compiling code or doing anything. So now I can test my parser here and as soon as I write something illegal, I can see that my parser actually does what it should do, only allow numbers and stuff like that. The lexing is done by Jflex which is a very popular framework for that kind, and we have all sorts of tooling support with this as well. Sorry, this is the Jflex file, so custom highlighting here and completion as well. Which technology for the parser? The technology for the parser is actually its home drawn, so the parsing is incremental. We pass changed parts of the file, so all the parsing is done in real time more or less while you type. What do you mean by the parser generator? The parser generator is completely home grown, so the code generator is really built by the plugin itself. There's no antler or something behind that. You can use antler, but we prefer our home grown stuff for various reasons. Yes, the grammar kit is also free. It's a separate plugin because not many people use it obviously, but it's free to use of course. So that's the grammar kit plugin, and the last thing I have on my list here is the plugin variable fire. We are going to take a look at this. So the plugin variable fire runs on the plugin repository, which shows all the plugins for downloading and in the IDE directly. But you can also install it locally and run it locally if you really want. But we are going to take a look at the instance on the plugin's repository. And I'm going to open the website because it's a bit nicer. So this is what it looks like. I've run a compatibility test against a specific IDE version and it failed, expectedly. And these are all the kinds of problems we catch now. The method is not found. The class is not existing anymore in this platform version. Incompetible binary changes in the platform. They shouldn't happen, but maybe they happen for some kind of reason. So you must update those references and stuff like this. You are still using deprecated API. So you get all these warnings and they really help you to make your plugin compatible with newer releases and fix all these issues one by one. And you can upload a new, better or more compatible version for the latest releases. You can also see all the dependencies that your plugin really has at runtime, for example. Does it work with the reflection API to internal APIs? Okay, so the question is, does it work with reflection for internal APIs? Yes and no. So it's bytecode-based analysis, obviously. We cannot catch every dirty trick you might or might not do using our platform. So yeah, of course we recommend using the API as is and not try to hack into package private stuff, for example, or even private stuff. If you feel the need to, please talk to us first. Maybe we will agree opening it instead. So that's all the tooling which is available for any plugin developer. All the tools I just showed are completely free and completely open-sourced. So are the SDK docs. We also want and encourage contributions to that as well. And now I'm showing two screenshots of internal tools we use in JetBrains to highlight some of the efforts we do to ensure stability. So the first one is the IntelliJ API Watcher. It is basically a tool we run on all the plugins which are hosted on the plugin repository. So we know what people are using. So before we try and delete, for example, some deprecated method, we can run this usage check and make sure that there are no more plugins using it. Or if we change some method signature, we can ensure that compatibility is not broken, stuff like that. So that really prevents us breaking the platform and all of a sudden a number of plugins just stop working for some binary compatibility issues. The second tool we use currently only internal is exception analyzer. So if there's some kind of exception in the IDE, you have the ability to report it to us. And it includes the exception stack trace, some message. You can also provide some additional details if you want. In some cases, the current file is attached to it if you allow it. So we can use this for diagnosis. And this exception analyzer helps us to classify and assign and group all the exception reports and assign them to the responsible developer. This is currently internal only, but we are really thinking about opening up a similar tool for plugin developers as well on the plugin repository. So this is something that might come in the future. There are, of course, a lot more tools in the plugin developer toolkit than I could show in a couple of minutes today. We try to increase the documentation for all this as well. One thing that is really important is the so-called internal mode in the IDE. So that's the last thing I want to show today. And what it gives you is this internal menu here, which has all sorts of debugging and inspection tools for you to use. And one of them is the UI inspector, for example, which allows you to all control click into any UI element and navigate the whole swing hierarchy of that element to inspect it, for example. And you can understand what components are we using to build this UI, so you can use the same ones for your UI or debug your UI, for example. There's really a huge number of stuff here. You can test various components. You can see so-called disposer trees. You can see the biggest components, the biggest chain of UI components and stuff like this. It really helps you to debug all sorts of problems which you might encounter while writing plugins. Okay, with that, I guess I'm done using my time to showcase some stuff. So I'm happy to take a couple of questions if time permits. Any more questions? Yes, please. I'm going to begin what you showed us, XML effect, which I can feel. My question is, you showed us a huge list of amounts of work here. If my developer doesn't know this, how can I update which is the correct one for me? What about the validation in this part? The question is basically, how do I know which extensions to use and what they do and how to find out more about them. That is actually one of the hardest parts for PluginBrighter because the platform just offers so many extension points and possibilities. Usually it's better to ask, I want to build this and that or look in the documentation and then we will also guide you to the correct extension points you want to use for this. For example, if you want to build a custom language, there's a set of specific extension points you probably want to use and they are listed in the documentation. A number of them have Java doc. You can invoke Java doc even in the editor there. In the XML file, when you have the completion open, you can invoke Java doc there as well. If you are unsure, navigate to the extension point, declaration itself to look for more documentation or information. We usually prefer if people ask what they want to build or look up what they want to build and then we guide them to the correct ones.
 Good morning.  Nice to have so many people here on Sunday morning.  I didn't expect it actually.  So my talk is about the IntelliJay platform.  My name is Jancy Prandt.  I work as a developer advocate for J-Brainz.  And I'm responsible for everything around tooling,  helping, plugin developers extending our IDEs and stuff like that.  Please excuse my voice.  I have a pretty bad cold since yesterday, of course.  So maybe I need a few breaks in between.  So what does this talk about?  First, I want to introduce the IntelliJay platform on a very high level, basically.  Who's using IntelliJay or any of the related...  Oh, okay.  So that's quite a lot of people who doesn't know anything about the IntelliJay IDEs.  Okay, everyone has heard of them, at least.  That's good.  So that's the first part of this talk.  A couple of slides.  And after that, I want to show the actual tooling that we provide to plugin developers.  And I will also demonstrate or show screenshots, at least, of some of the internal tools we use at JetBrains  to make sure that plugin developers enjoy our platform.  So we try to help them as well by using some internal tools and making sure that things work smoothly for everyone.  So the IntelliJay platform came out of IntelliJay IDEA, the IDE, which used to be commercial IDEA only.  We split that into community edition, which is completely open-sourced under Apache 2 license since 2009.  And there's, of course, still the commercial IDE or other IDEA based on the IntelliJay platform.  It's a JVM-based IDE, just like NetBeans and Eclipse.  So we use mostly Kotlin, sorry, we use mostly Java, some Kotlin, or increasing amount of Kotlin,  and a few bits here and there of Groovy Code as well.  The user interface is actually built completely on swing, and most people are like,  what, you can actually build like complex swing applications, yes you can.  It is quite painful sometimes, especially when you want to support the same level across Mac, Linux, and Windows.  But we are lucky enough that we have actually a couple of very talented people from the former swing team  who now work for JetBrains and who built their own OpenJDK-based runtime, which we use for our IDEAs now.  So that's another thing that is somewhat related to the IntelliJay platform.  We use our own Java runtime based on OpenJDK, so it's also completely free for everyone,  and we merge back to OpenJDK as well.  One important distinction to make between IntelliJay and NetBeans and Eclipse is that the IntelliJay platform is not a generic framework,  or not a framework for generic applications, so it is not intended to be used for like customer applications  or anything that is not an IDE or something that is somewhat an IDE.  And this is a very important point to make, so please don't try to do it.  It is just too specialized, and it is pretty much impossible to rip out the parts  which would just give you the basic layer for running an application and having some kind of UI.  The last line on the slide is a link to a presentation which a colleague of mine made a couple of years ago,  so it's a bit outdated, but it still shows like the whole evolution of the IntelliJay platform  and how things work together or developed if you're interested in a bit more history.  So how can you approach writing plugins for the IntelliJay platform?  So the community repository is basically the IntelliJay platform.  We have no distinction between the community edition of IntelliJay and the platform as such.  It is one repository and one name.  It's published on GipTap as well.  We accept pull requests, any kind of feedback on that as well, of course.  The second link is the SDK documentation.  So that's some high-level docs around the IntelliJay platform which helps you learn it,  understand all the different parts of it, and it also has some tutorials or self-lawn trails.  Basically, for example, if you want to write a custom language plugin,  there's a nice detailed introduction on how to approach this.  JetBrains runs a couple of forums.  One of them is specialized to help plugin developers or anyone building stuff on the IntelliJay platform.  We do monitor this.  It's actually one of my tasks to do this and try to help answer all the questions in a timely manner.  There's also a Gitter community run.  Jet were actually quite a lot of very active plugin developers hanging around as well.  So if you need a quick answer, you might get lucky there as well.  Sometimes I look there as well.  If you want to keep up to date, we run a blog and Twitter account, of course,  so you get all the high-level news about the IntelliJay platform.  So, plugins. There's actually a quite huge number.  Anytime I talk about IntelliJay platform, I have to go on our website,  which lists all the plugins and look up the new number and it increases more and more.  What kind of plugins can you build for IntelliJay?  Well, basically anything that you can think of.  One very popular category is, of course, like custom languages,  any kind of framework support, any kind of web application support, for example.  There's a lot of little tools, helpers, kind of stuff of plugins being published there as well.  So it's a very broad offering that you have.  And actually, most of them are open source or at least free for use.  The plugins' website lists all of them, so that's one way to search for them.  You can see all the different versions and stuff of them.  We are going to take a look a bit later.  Marketplace is a thing we are currently developing in JetBrains,  which will help plugin developers to actually monetize the plugins if they want to.  We are also considering using this platform for donation-based plugins.  Maybe that's also something interesting for purely open source plugins as well in the future.  Of course, you can build IDEs on IntelliJay platform.  So there's a couple of them by JetBrains.  We try to cover all the most popular programming languages, obviously.  One of them is very interesting from the technical point of view, which is Ryder.  It's a C-sharp.net IDE, which runs as well on Mac as on Linux.  So that's something quite unusual in the.NET world.  And it uses the IntelliJay platform just for the frontend.  So only the user interface is run by the IntelliJay platform.  It feels and looks like one of the IDEs, but all the code intelligence and all the real functionality  is actually run by a second process, which runs resharper.  And resharper is also a product which we have developed for a couple of years,  which is originally a plugin for Visual Studio.  So we kind of combined the two worlds into one product,  which allows us now to run a Visual Studio extension cross-platform on all machines.  Probably the most known IDE, which is not built by JetBrains, is Android Studio,  which is like the official IDE for anything Android-based.  It was built by Google based on the Android plugin we did before.  There's also a couple of others. One of them is Cuba Studio, that's the web framework.  And they basically provide a plugin, but as well a full standalone IDE for their specific framework.  Building IDEs is, of course, much more complicated than building a plugin.  So we usually recommend to build a plugin, and if the plugin involves into something bigger,  then think about distributing it as a standalone IDE later.  So now we come to the interesting developing parts.  These are the points I want to show to them today.  So the plugin development kit is, of course, a plugin in IntelliJ,  which allows you or helps you write in plugins in IntelliJ.  The Gradle IntelliJ plugin is actually a plugin for the Gradle build system,  which helps you write plugins for IntelliJ.  So you can use Gradle and actually highly recommend doing so now.  I will show a bit more details later.  The third one, GrammarKit, is specifically targeted at custom language development.  So anyone wanting to support a new custom language should really try building it on GrammarKit.  And the last thing is a maintenance tool, PluginVerifier,  which helps you to ensure that the compatibility with newer or older versions of IntelliJ  is actually guaranteed.  So now let's switch to the IDE.  And I want to show some basic features of the plugin development plugin itself in the IDE.  So there's a couple of things.  Basically, a plugin is built by the code, obviously,  and all the components are registered in a pluginless drifter file,  which is basically the XML file we are seeing here.  It has all sorts of metadata, registration information,  about the actual functionality that the plugin exposes.  And we have built a quite sophisticated support for editing all this XML.  So we can see all the components here, for example.  We have some metadata about the plugin itself, like name, ID, compatibility information here,  and stuff like that.  And you have quite nice tooling support in the XML file itself.  So we don't like wizards in the IntelliJ world at all.  We try to avoid them.  We try to build all the tooling based on textual editors,  because we think it's usually faster to type stuff or use tooling that helps you type faster  than using UI-driven wizards.  So for example, I have two extensions here, which use the same extension point,  so they provide a similar kind of functionality.  And I have given them some kind of IDs.  And this is interesting because then you can actually provide some kind of ordering for extensions.  So for example, one extension can have priority over other extensions,  your own ones or maybe even the built-in ones.  So that's one way of overriding or extending existing functionality even from the platform.  And we understand all of this.  So we have auto-completion here, I can use GoTarget here,  I can do a findUsages and stuff like that.  Of course, all the extension points can be auto-completed here as well.  We can even go to the declaration here, look at the actual interface,  which provides this extension point and stuff like this.  We can then go back to the registration of this extension point and stuff like this.  So this is all very nicely integrated in the editor.  And let's talk about compatibility because that's one very crucial point,  which actually caused quite a lot of trouble in recent years,  but I think the tooling we have now will help make things better.  So we have three major releases a year now.  We switched to that model some time ago.  And you can actually see the release date from the number.  So 18.2 is basically the second release in 2018.  And 183, of course, is the third release in 2018.  So if you want a very generic compatibility, that's very easy to do like this.  But you can also provide the full build number if you really need  some changes in some kind of later point release.  The thing I did now was to violate the compatibility.  So I specified 182 here.  And actually, I cannot do this.  It's a bit small to read.  So basically what the message is saying is I'm trying to use an extension point  from a platform release that is newer than the minimum version I specified  in my plug-in descriptor.  So I'm trying to use something that is not there, basically.  And that's quite easy to fix because I can just change now the minimum version,  go back and the warning will disappear because now it's okay.  It's now compatible, right?  And another thing we added in the tooling just recently is that we have  now these annotations here, available since, which prints the exact build number  when this class or even method was added to the platform so you can see  when it will be available.  What is the minimum version I need to specify in my plug-in to be able to use this class?  So this information and the inspection really helps you to ensure compatibility  even before deploying or trying your plug-in you will be warned right in the editor.  There's a couple of other highlightings in the plug-in XML.  For example, we require useful descriptions.  Or if you just write one word, it will highlight this as an error  because it's not useful for users to browse the plug-in list  and have no decent description, stuff like that.  Same if you try to use...  Oh, no, it actually doesn't because I'm running in a special mode,  but you would get the warning that you are not chat brains  or you shouldn't specify chat brains as plug-in vendor, stuff like that.  So we try to make all the appearance of plug-ins a bit more uniform  and more useful for end users.  There is a couple of other features we have.  So writing plug-ins, of course, means writing tests.  We prefer integration tests, so usually we fire up some kind of headless IDE instance  and you test against this headless IDE instance.  That's the way we usually write tests.  So you need usually some kind of test data  and then you perform some actions against this test data.  For example, you have some file and some Java file  and you want to test completion.  You write this minimum Java file,  you position the cursor at some specific point in the file  and then you invoke completion  and then you test the completion variants,  which are shown are actually the ones you want to be provided.  So you need some kind of navigation between your testing code and the test data.  That's another feature that Plug-in Development Kit offers.  For example, we have the special annotation here, test data pass.  So we can navigate there and see the related test data here as well  and navigate to the test data here.  Okay, it's broken in this sample of course, but usually it works.  There's another new feature which we are going to announce a bit more publicly later this month,  which is a thinning in the IDE.  So the whole UI can be basically, you can provide a custom theme for the UI,  any colors, margins and stuff like this can now be customized.  And that's also part of the Plug-in Development Kit to offer tooling support  for this customization.  As you can see, you get, for example, a preview for all the colors in your theme,  but you also get completion for all the customization keys, for example.  So that's about just some of the features we have in the Plug-in Development Kit.  Now I want to show a bit of the Grammar Kit.  So how do you write custom language support in IntelliJ?  Basically, you need a lexer which lexes the file into tokens,  and then you need the parser which builds on top of that.  This is what Grammar Kit offers you for tooling, so it's very easy to write a lexer  and as well basically generate a parser based on some BNF notation for the parsing.  And I will make this part a bit shorter because time is tight here,  but you have all sorts of tooling support here for writing the parser BNF file,  generate the parser code.  We can even do a live preview of our parser without actually compiling code or doing anything.  So now I can test my parser here and as soon as I write something illegal,  I can see that my parser actually does what it should do, only allow numbers and stuff like that.  The lexing is done by Jflex which is a very popular framework for that kind,  and we have all sorts of tooling support with this as well.  Sorry, this is the Jflex file, so custom highlighting here and completion as well.  Which technology for the parser?  The technology for the parser is actually its home drawn, so the parsing is incremental.  We pass changed parts of the file, so all the parsing is done in real time more or less while you type.  What do you mean by the parser generator?  The parser generator is completely home grown, so the code generator is really built by the plugin itself.  There's no antler or something behind that.  You can use antler, but we prefer our home grown stuff for various reasons.  Yes, the grammar kit is also free.  It's a separate plugin because not many people use it obviously, but it's free to use of course.  So that's the grammar kit plugin, and the last thing I have on my list here is the plugin variable fire.  We are going to take a look at this.  So the plugin variable fire runs on the plugin repository, which shows all the plugins for downloading and in the IDE directly.  But you can also install it locally and run it locally if you really want.  But we are going to take a look at the instance on the plugin's repository.  And I'm going to open the website because it's a bit nicer.  So this is what it looks like.  I've run a compatibility test against a specific IDE version and it failed, expectedly.  And these are all the kinds of problems we catch now.  The method is not found. The class is not existing anymore in this platform version.  Incompetible binary changes in the platform.  They shouldn't happen, but maybe they happen for some kind of reason.  So you must update those references and stuff like this.  You are still using deprecated API.  So you get all these warnings and they really help you to make your plugin compatible with newer releases and fix all these issues one by one.  And you can upload a new, better or more compatible version for the latest releases.  You can also see all the dependencies that your plugin really has at runtime, for example.  Does it work with the reflection API to internal APIs?  Okay, so the question is, does it work with reflection for internal APIs?  Yes and no.  So it's bytecode-based analysis, obviously.  We cannot catch every dirty trick you might or might not do using our platform.  So yeah, of course we recommend using the API as is and not try to hack into package private stuff, for example, or even private stuff.  If you feel the need to, please talk to us first.  Maybe we will agree opening it instead.  So that's all the tooling which is available for any plugin developer.  All the tools I just showed are completely free and completely open-sourced.  So are the SDK docs.  We also want and encourage contributions to that as well.  And now I'm showing two screenshots of internal tools we use in JetBrains to highlight some of the efforts we do to ensure stability.  So the first one is the IntelliJ API Watcher.  It is basically a tool we run on all the plugins which are hosted on the plugin repository.  So we know what people are using.  So before we try and delete, for example, some deprecated method, we can run this usage check and make sure that there are no more plugins using it.  Or if we change some method signature, we can ensure that compatibility is not broken, stuff like that.  So that really prevents us breaking the platform and all of a sudden a number of plugins just stop working for some binary compatibility issues.  The second tool we use currently only internal is exception analyzer.  So if there's some kind of exception in the IDE, you have the ability to report it to us.  And it includes the exception stack trace, some message.  You can also provide some additional details if you want.  In some cases, the current file is attached to it if you allow it.  So we can use this for diagnosis.  And this exception analyzer helps us to classify and assign and group all the exception reports and assign them to the responsible developer.  This is currently internal only, but we are really thinking about opening up a similar tool for plugin developers as well on the plugin repository.  So this is something that might come in the future.  There are, of course, a lot more tools in the plugin developer toolkit than I could show in a couple of minutes today.  We try to increase the documentation for all this as well.  One thing that is really important is the so-called internal mode in the IDE.  So that's the last thing I want to show today.  And what it gives you is this internal menu here, which has all sorts of debugging and inspection tools for you to use.  And one of them is the UI inspector, for example, which allows you to all control click into any UI element and navigate the whole swing hierarchy of that element to inspect it, for example.  And you can understand what components are we using to build this UI, so you can use the same ones for your UI or debug your UI, for example.  There's really a huge number of stuff here.  You can test various components.  You can see so-called disposer trees.  You can see the biggest components, the biggest chain of UI components and stuff like this.  It really helps you to debug all sorts of problems which you might encounter while writing plugins.  Okay, with that, I guess I'm done using my time to showcase some stuff.  So I'm happy to take a couple of questions if time permits.  Any more questions?  Yes, please.  I'm going to begin what you showed us, XML effect, which I can feel.  My question is, you showed us a huge list of amounts of work here.  If my developer doesn't know this, how can I update which is the correct one for me?  What about the validation in this part?  The question is basically, how do I know which extensions to use and what they do and how to find out more about them.  That is actually one of the hardest parts for PluginBrighter because the platform just offers so many extension points and possibilities.  Usually it's better to ask, I want to build this and that or look in the documentation and then we will also guide you to the correct extension points you want to use for this.  For example, if you want to build a custom language, there's a set of specific extension points you probably want to use and they are listed in the documentation.  A number of them have Java doc. You can invoke Java doc even in the editor there.  In the XML file, when you have the completion open, you can invoke Java doc there as well.  If you are unsure, navigate to the extension point, declaration itself to look for more documentation or information.  We usually prefer if people ask what they want to build or look up what they want to build and then we guide them to the correct ones.
Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_0_47.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_48_107.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_108_155.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_156_16535.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_16536_18011.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_18012_19835.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_19836_21971.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_21972_25187.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_25188_25283.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_25284_27299.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_27300_27419.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_27420_28283.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_28284_28355.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_28356_28427.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_28428_28571.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_28572_30395.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_30396_30575.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_30576_30707.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_30708_32051.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_32052_32171.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_32172_32219.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_32220_32891.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_32892_32939.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_32940_32987.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_32988_35435.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_35436_35495.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_35496_35579.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_35580_39119.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_39120_39179.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_39180_39227.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_39228_39431.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_39432_39539.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_39540_39707.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_39708_40043.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_40044_40091.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_40092_40175.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_40176_40679.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_40680_40739.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_40740_40787.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_40788_40847.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_40848_43655.png Tooling_for_IntelliJ_Platform_Plugins_KrAfPAWlAAs_43656_43776.png