 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 Yancy Braun. I work as a developer advocate for JetBrains and I'm responsible for everything around Tooling helping plug-in 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 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 plug-in developers and I will also demonstrate or show screenshots at least of some of the internal tools We use a JetBrains to make sure that plug-in 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 IDE 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 IDEs based on the IntelliJay platform It's a JVM based IDE just like net beans 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? Open JDK based runtime which we use for our IDE now So that's another thing that is somewhat related to the IntelliJay platform We use our own Java runtime Based on Open JDK, so it's also completely free for everyone and we merge back to Open JDK as well one important distinction to make between IntelliJay and net beans 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 linked 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 helped you learn it understand all the different parts of it and it also has some tutorials or Self-loan trades basically if for example if you want to write a custom language per plug-in. There's a nice detailed introduction in 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 chat We're actually quite a lot of very active plugin developers are hanging around as well So if you need a quick answer you might get lucky there as well. Sometimes I've I look there as well if you want to keep up to date we run a block and Twitter account of course, so you get all like the high-level news about the IntelliJay platform So plug-ins 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 so one very popular category is of course like custom languages any kind of framework support so any kind of web application support for example There's a lot of little tools help us kind of stuff of plugins being published there as well and Yeah, 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 Jet Brands, which will help plug-in developers to actually monetize the plugins if they want to We are also considering using this platform for donation based plugins So maybe that's also something interesting for purely open-source plugins as well in the future Of course, you can build IDEs on the IntelliJay platform So there's a couple of them by Jet Brands. 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 combine 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 Jet Brands 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 IntelliJay Which allows you or helps you writing plugins in IntelliJay The Gradle IntelliJay plugin is actually a plugin for the Gradle build system which helps you write Plugins for IntelliJay, so you can use Gradle and actually we highly recommend doing so now I will show a bit more details later The third one grammar kit is specifically targeted at custom language development. So anyone wanting to support a new custom language should really try building it on the grammar kit and The last thing is a maintenance tool plugin verifier Which helps you to ensure that the Compatibility with newer or older versions of IntelliJay 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 plug-in File which is basically The XML file we are seeing here It has all sorts of metadata and 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 IntelliJay 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 go target here I can do a find usages 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 on which Actually cost quite a lot of trouble in the 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 to 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 compiler 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 makes some L for example we require Useful descriptions or if you just write one word it will highlight this in 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 jet brains, so you shouldn't specify jet brains as plug-in vendor Stuff like that. So we try to make all the Appearance of plugins a bit more uniform and more useful for end users There is a couple of Other features we have so writing plugins 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 some file and some Java file and you want to test completion you write You've 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 that Decompletion 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 And that's another feature that plug-in development kit offers. For example, I 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 seeming 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 preview for all the colors in your theme, but you also get completion for all the customization keys for example So the that's about some just some of the features we have in the plug-in development kit Now I want to show a bit of the grammar plug-in grammar kit plug-in, sorry So how do you write custom language support in IntelliJ? Basically, you need a lexer which Lexus the file into tokens and Then you need the parser which builds on top of that And 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 Parse here and as soon as I've write something illegal We I can see that my parser actually does what it should do only are now numbers and stuff like that The lexing is done by J flex 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 J flex file So custom highlighting here and completion as well The technology before the parser is actually It's homegrown. So the parsing is incremental. We only pass changed parts of the file So all the parsing is done in real time more or less while you type The parser generator is Completely homegrown. So the code generated is really built by the plug-in itself. Yeah There's no antler or something behind that. No, you can use antler, but Yeah, we prefer our own homegrown stuff for various reasons. Yes, the grammar kit is also free It's a separate plug-in because not many people use it obviously, but it's free to use of course so that's the grammar kit plug-in and The last thing I have on my list here is the plug-in vary fire and we are going to take a Look at this So the plug-in verifier runs on the plug-in 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 plugins 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 expectably And these are all the kinds of problems we catch low like the method. It's not found the class is not existing anymore And there's 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 plug-in compatible with newer releases and fix all these issues one by one and upload a new Better or more compatible version for the latest releases You can also see all the dependencies that your plug-in really has at runtime for example 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 that's all the tooling which is available For any plug-in 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 and chat brains 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 plug-in 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 methods 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 analyzes 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 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 plug-in Developers as well on the plug-in repository So this is something that might come in the future There are of course a lot more tools in the plug-in developer toolkit Then 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 elements to inspect it for example 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 So 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. Yes So any more questions? Yes My question is Here Yeah, so the question is basically how do I know which extensions to use and what they do actually and how to find out more about them Yeah, so that is actually one of the hardest parts for plug-in writer 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 So you can see some In the XML file when you have to your completion open You can invoke Java doc there as well if you are unsure navigate to the extension point Decoration itself to look for more documentation or information. So but yeah 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 Okay