 Hello, sorry about that. I'm just trying to get my screen oriented. So my name is Gorka Marjan. I work for RETAT in the developer tools group. Yay. And before that, I used to work for mobile. I still maintain some of the mobile tools that we have. Today I'm going to talk about Visual Studio Code of all the things. How many of you used Visual Studio Code before? How many of you used Eclipse before? OK. So what is Visual Studio Code? So in the development tooling space, you have the IDEs, which is Eclipse. Which everything is integrated. And then you have your tools nicely built into your IDE. And you can reach to them. And then you have the text editors, like VI, Sublime. Any VI users? Sublime? Yep. So Visual Studio Code actually falls into this category. So it's a text editor. But it does have some IDE features built into it. What kind of features we're talking about? We're talking about integration with Git, debuggers, language tools. Yeah. Yep. Analysis of your code. Yeah. It's more of a, OK. So that is basically a topic that I'm going to cover. So the question is, we usually distinguish the editors as code editors and text editors. And his classification way of using abstract trees. If an editor is using abstract language trees, then it's a code editor. And if it's just doing text, then it's the text editor. Well, I think in some cases it is a code editor. But I'm going to tell you more about it. So yeah. So let me just do a quick demo of VS Code now so that those who hasn't used it can get a bit more familiar. OK, what I'm going to do is I'm going to first find my. So I have prepared a few files to show. So the best feature of Visual Studio Code is it, you can just start it from command line. You can just say code and a dot. And it will start with that directory. So that's the best thing. But while it's not limited to that, so there is more to it. So if you look at the code help, you can see that there are some properties, some options that you can use. For example, you can use it as a diff tool. So it will just open the diff view for that file, for those two files. So you can just directly do a diff. And I'm not doing that myself, but some people actually use it for the get diff tool. There is their default get diff tool as well. So that's one thing. And if you're wondering, how many of you are using developing a Java? So if you're wondering if it can be used for Java, it can. So you will notice that there is a starting Java language server thing. And then when it starts, it says class path is incomplete. And the reason for that is it's a single file that we opened. It's not even in the correct directory structure and so on and so forth. So what we do is we go with the spread of the Visual Studio Code or any other text editor or code editor and say that, OK, yeah, you have a single file. We know that this doesn't work with Java. So your class path is incomplete. But if you want to continue, you can still continue. But you will not be getting all the errors. For instance, if I add an import here that says my unknown import, it's happy with it. It doesn't say that my unknown import doesn't exist. Because we don't really know if the class path has it or not. We just say, OK, it's not a syntax error. So let's go with it. But if you go here and say, remove this, all of a sudden, this is a problem. It says you're missing a semicolon. And then if we know something about your class, let's say version, which is a string, then we give you the code access for string. Because we know string, it's in the JVM. So we can kind of understand that. But we cannot understand, for instance, something that is not part of the JVM. Because we don't know the class path. So you will get some code assist. You will get code templates. But you will not be getting the full compilation of everything. And this is pretty much a similar case for other languages as well. So if you start using code and we just do the code for Python or TypeScript, if you cannot find out the information about the project, it will try to do best with the single file that it has. And that's what we do with Java here. And you will notice that everything actually works. For some reason, the get ID is referenced seven times here. And if you look at it, it's all the references to the get ID in the same file. And you can also take a look at the outline. So everything will work on a single file other than the information in the project. So that's basically a quick introduction to Visual Studio code. I will have more on that. But one thing that you may have noticed is that I had the starting Java language server prompt when I opened up the Java file. And what that is is a language server is how you introduce language properties to Visual Studio code. What it does is it is a server that the tool communicates with. So it doesn't know anything about AST. It doesn't know that the Visual Studio code actually doesn't know anything about Java. What it does is it knows is there is a language server that I can ask certain questions to. For instance, when the user opens the document, it goes and says to the language server, hey, there's a text document opened. But it doesn't know what the server will do with it. And the language server receives it and initializes the tools. For example, on the Java server side, what we do is we create a working copy of that file. If it's a Java file, we look at it and say, OK, someone is going to modify this. Let's get ready. And when the user edits the document, the tool sends us, oh, there's some change. Here's what's changed with this file. And then on the server side, what we do is we modify the working copy that we created, which means we modify the ASD tree, basically. And then if the ASD tree analysis says that, oh, there are some errors in this file, on the other hand, we just go back to the tool and say that, hey, these are the new errors that you should display to the user. So in this interaction, as you can see, the text editor doesn't know anything about the language. It just knows that there are some changes and there are errors. And the tool doesn't know how they are displayed. The language server doesn't know how they are displayed. So this is the thing that we call the language server protocol. It's the protocol that goes behind it in between the tool and the server. And it is portable. Right now, Visure Studio Code, obviously, is the tool that started it and supports it. But we do have support for it on Eclipse Orion. There is coming up support for it on Eclipse Classic ID. There is upcoming support on, I just saw someone trying to use our language server, the Java language server on Emacs. So there is some support for it. So yeah. That way, the language tooling is actually part of the server. And the text editors or the IDs actually don't know anything about it. And there are flurry of advantages to this. For instance, one of the problems that we face on Eclipse World is the language tooling is actually done by IDE developers who are not necessarily familiar with that language. You have Eclipse is written in Java. You have these Java developers who are trying to support TypeScript, which they never use. But this language server protocol kind of replaces that. For example, we have a TypeScript server written in TypeScript. We have a Java server written in Java. And Python server is written in Python. So the very community that creates that language can actually build the language server. And it has a lot of advantages. A bit more about the language server protocol. As I said, it was started by Microsoft as part of their Registry to Code initiative. And last year, we declared our support for it, together with CodeMV on Eclipse.j. It's a Creative Commons Attribution 3 license for the documentation. And the code that exists on that repository is MIT license. It is a JSON RPC protocol. That means that all the messages that goes between server and tool is JSON objects. There is no transport that is defined. So there are some servers that run on sockets. There are some servers that run on namepikes. The Java language server that we have supports both. And we are going to add another transport for Emacs soon, because they don't have sockets for some reason. So the one that we have right now is the Java language server. Basically, we started this last year so that it was a good demo for Summit. Then it got traction, and it became an Eclipse project. So now it is an Eclipse open source. So we moved it. It was always open source. Now we moved it to eclipse.org. And it became JDTLS. The good thing about our language server is it actually uses Eclipse JDT, Java Development Tools, for all the Java stuff. It uses M2E project for Maven integration. It uses BuildShip for Gradle integration. So one of the developers on the team considers it as his secret plot for hipsters to use Eclipse. So we basically ship a 40-meg version of Eclipse with VS Code. Well, the main motivation was we were Eclipse developers. So we were very familiar with JDT. So that was the starting point. But yeah, it could be IntelliJ as well. And if we find that IntelliJ is a better fit, then we can just switch to IntelliJ. And it just wouldn't matter, because the tools I'll only know about the protocol. And one thing that we did is we actually, after implementing this language server, we actually made it into a Visual Studio Code extension. And last year, about eight months ago, I guess, we published it on the Marketplace. And if I can't find it here, no, I can't find it here. Let's try our luck with the link. Yeah, and since we published it, we got over 100,000 downloads, which is pretty good. It makes us one of the top 40 extensions on Visual Studio Code Marketplace. OK, so let's look at some of the Java language features that we haven't looked at. So I'm going to just make it directory here, with a name, of course, and open that on Visual Studio Code. So I have an empty directory. There are no files. So what I want to do is I want to show the creation of a Spring Boot application here. And the way I will do that is I'm going to start the Yeoman, say Spring Boot app, yeah, one for one. That's fine. Let's do 1.8. And I want to JAR and Maven, because we like Maven. Yeah, let's do web. I'll just skip these. We don't need any of that. But you can add them, as you can see. There are a lot of options on Spring Boot. Use Spark, no. Yeah, and then what it does is it will just generate me a Spring Boot application. And you can see it here. And my language server started. And it will start to give me code-assessed and hover support and whatnot in here. So one thing that I want to do is to create a controller for it. Let's go with animals. So as you can see, now I have two options here for code-assessed. One of them is it will just print me class. And the second one is a template. So I'm going to just choose the template, and which gives us a good look at multi-cursor support on VS code. Let's call it, of course, animal. And I don't need parameters. Not doing well right now. I usually use VI key bindings on VS code. So my hand kind of goes to insert command. So one thing that you will notice, there is like a little red squiggly here. And that's because we don't have a package name for it. OK, so we want to make this a controller, right? So let's do rest controller. We don't even need this, but let's remove it completely. I'm going to just have a string, say, and what kind of animal. It's a raccoon. Let's do some more. I'm just going to add a response. Oh, yeah, sure. Yeah, I don't really know that. OK, so once I created this, this actually works, right? It will, well, it's a Spring Boot application. So how do I run this? That's my next question. Of course, we can always go back to the command line and run it. But the code, we just did a code way of doing this is to go here and say task, configure task runner. So what it will do is it will ask you, give you a list of task runners. And if you choose Maven, it will give you a task JSON file. So what the task JSON file does is it actually is a configuration for you to run for that workspace. So you can have any number of tasks, and they will show up on your command window. And if you actually call them to be build commands, then it will be tied to your command B shortcut. Let's call this, of course, not Vi. I'm going to do this. And then, well, I don't have any tests. I don't care about it right now. So I'm just going to say run. And for run, I'll do, is it the test command? No. And one of the options, so if you look at here, you actually are getting content assist for this as well. So you can echo the command, and you can say that it's a watching task, which means that the task is never terminated, and it does something every time a file changes. You can have a problem matcher. So it's actually a way of getting those errors from a build, for instance. We don't do that for Java. But that's a possibility. So you can just say, hey, anything that comes out of this command, just run it through this problem matcher, and it will generate errors on the file or files. But yeah, we don't need any of that right now. So I think we are ready. What I'll do is I will try to run the run task. You can see that it is here on the output, starting the server, started the server. So let's see if it's working. I think it is on 8080, right? Yep. Our URL was animal. We have a raccoon. So this is working. One thing that we are not able to do right now is hot code replace with the regular Spring Boot. You can actually get into a configuration where you can do hot code replace with Spring Boot as well. But if you choose, for instance, Vertex, Vertex actually has a command which you can start the server in, which does the hot code replace. So it's much easier. So with this, the difference between an IDE and the code editor is you are depending on the tools provided by your framework, for instance. And with Spring Boot, you don't have an easy way of configuring hot code replace. Well, you do have an easy way of doing that with Vertex, for instance. So I guess that's kind of the main difference, because with an IDE, that IDE takes the responsibility of doing that hot code replace for you. What else do we have on the? Another thing that I wanted to show is so the animal controller is here. And then you can do, we looked at the outline view. But let's say you're here and you want to open the application. So you start typing it, and then it will do a Java reference search for you. And then you can just go back to it. And you can jump to class files if there is that, if it's downloaded by Maven. But yeah, string is always there, so you can jump to it. And the good thing is the tools are still working. So if on a string, you still get hover information and so on and so forth. So those are all actually coming from the language server. Another advantage that I want to show, how many of you are familiar with Jhipster? Heard of that? No? OK. So Jhipster is this packaging of Spring Boot with Angular and with many other things. But those are the two main things. And it gives you a good package application starter. So you can have a Spring Boot backend and an Angular UI. It is just created for you. And I want to look into that. And let's kill this, kill that one. Go back to command line. So I'm going to, again, start using Yeoman. And actually, this is kind of required when you're working with Jhipster, because they kind of support Yeoman for generation. OK. So it says, I'm going to create these. What sort of application you want? I want a monolithic application. What's the base name of your application? I really don't care. That's fine. No, I don't want any other generators. What's your default Java package name? Somehow it detected that I want to use that. I don't know. I don't want to go into the details of how it did it. What database would you like to use? I'm going to use Sequel and use MariaDB for production. Since I'm not going to the production, it doesn't matter. Let's do in-memory HD, H2 part. And do I want second level cache? No. And here's a different thing. I want to use Gradle this time. I don't want any of this. I don't want SAS. I don't want internalization. Yeah, why not? And yeah. So what it does is it goes and downloads some of the internet and then generates you an application in that folder. But the good thing about this is all your Angular files, which are typically JavaScript. And all your Java files are in the same folder. So and if you're working with Angular 2, you know that they support TypeScript. And they kind of look better with TypeScript. And the best TypeScript tooling you can get right now is on Visual Studio Code. So having your Spring Boot application and your TypeScript-based Angular application on the same workspace with Visual Studio Code provides a lot of advantages. But it's still downloading. I'm going to blame the internet being slow. Sure. OK, the first question is, where is the language server running? Right now, it's running locally. What it does is it starts it as a request comes. So if you open a Java file or if you actually, if your workspace has a Maven file or a Gradle file, it just invokes the Java server. But that's just because it's easier to do for us. So if you have another situation or another tool that needs to talk with a remote language server, for example, that's something that we are planning to do with Che. Che supports language servers. The Java support on Che, we haven't replaced that with our JDTLS server. But at some point, what we want to do is to run our language server on a container, which the Che IDE would be talking with. So it will be running on a container so that the communication will be socket-based or removed as well. The second question was, what was the second question? OK, can we run Visual Studio Code on a browser? So that's the question. Yes, Visual Studio Code is built with TypeScript. So it's actually JavaScript that is running. And it's running on Electron. So the answer is no, because the Visual Studio Code actually uses a lot of the system APIs, like access to desk and so on and so forth. It actually assumes that you actually have a file system. On a browser IDE, you really don't have a file system. But what you can use instead is the editor on Visual Studio Code, the actual editor, is called Monaco. It's an open source editor. You can take that and embed that into a web page. And then you have a chance of hooking that up with a language server. It already supports coloring, the syntax highlighting, Monaco already supports that. The only thing that it doesn't support right now is the language server part. And my guess is it's not a big chunk of work to get that running. So it is possible to have the same editing experience on a web IDE. But one thing that we did with Che is Che already supports that. And it uses an Orion editor. And funnily, Orion also supports Java language server as well. It's eclipse.org slash che. How do you spell it, Che? C-H-E. It supports language servers, although we haven't replaced the Java support with the language server yet. But for instance, things like PHP support, I think we have, what else we have, Maria on Che? Yeah. I know we have PHP and JSON. TypeScript and C-sharp, actually. Yeah. Those are also coming from a language server. All right. Now the internet is downloaded. We can start our Registry code. And as you can see, I have all kinds of files here. Let me just start by looking at a Java file. And as you can see, my language server started and so on and so forth, and I'm getting Java help. But that's not the interesting part. The interesting part is I'm just getting like trying to move it along a bit. Go a bit faster. So as you can see, now I have JavaScript. JavaScript support in the same file. So I can get all kinds of TypeScript, JavaScript, code assist through Visual Studio Code. At the same time, I have the Spring Boot application, which gives me the Java as well. And then if I go here, you can see that I have, for instance, inline color support on CSS. That sort of stuff is already there. What else I can show? Editor config is supported on Visual Studio Code for those who are missing it on Eclipse. JSON support is there. You actually get code assist for JSON. YAML is sort of supported. So that's coloring, basically. But the good thing is, if you ever need to deal with PacketJSON, there is good code assist support on PacketJSON. So I can see the different versions of Power here. And if the network handles it, let's do that. It gives me a list of all the packages on NPM so that I can just randomly select those and add that just for fun. It actually does have full support for PacketJSON. Gradle, well, it's basically the same story. Exactly. But J-Hipster is this little, it's a very smart idea of putting everything together. So you have seen all the choices during the generation. So then. Yeah, I'm not complaining. It just looks. Yeah, there is. Yep. The client. Yeah. All right, so that's the advantage that you're getting with Visual Studio Code because you have the option to use Python and Java or PHP and TypeScript in the same editor, in the same workspace, and it just works. If you're familiar with Eclipse, it is very hard to do that on Eclipse because a project on Eclipse is a Java project. So when you add TypeScript to it, if you don't create or Python to it, let's go crazy. You don't really have a situation where you have Java project and the Python project at the same time. There isn't any project type that handles Python and Java at the same time. But with VS Code, you really don't care about the project type. It's just an area in the workspace in your file system. So it doesn't care about it. And it just provides support for it. So let me just show, oh, did I just close it? I was trying to do something else. So let me just show you, did I again? No, it's me. Bug is me. I'm using the wrong combination. So I'm going to just show you the extensions. As I said, these are the extensions that I already have on my VS Code installation. But if you go and search for anything, basically you will find an extension for it. Let me just do this. So as you can see, there is a Python debugger linter. And then there are a flurry of things that I don't really understand. Because I know nothing about Python. But so there is a few hundred CSS-related extensions. And if you go for search for Java, you will see that the language support for Java by Red Hat is the first choice. And the leading choice, I'm pretty much the only choice nowadays. There are a couple of other extensions, actually, on Java. And yes, someone that has a Java properties syntax highlighter, if you're into that. And some of my favorites here, oh, we do have Docker, actually. Some of my favorites here is, for instance, this little one, this Git link. So this is one of my favorite extensions. Because every time that you need to share some code with a colleague, what you need to do is go to the GitHub, find that same line, and then copy that link. With this one, you can just right-click to it, and then it will just put that in your clipboard. You don't need to go online and just send it. So it's a pretty strong ecosystem on Visual Studio Code. All right. So I'm told that we have a few minutes. So as you have seen, that we have a very strong Visual Studio Code ecosystem, and our Java tools are part of it. But Visual Studio Code is only our one way of supporting Java developers with the JDTLS. We are supporting, for instance, Eclipse Orion with Java Server as well, which IBM is planning to put on Bluemix. And we are supporting Eclipse Che with it. We plan to support Eclipse Che with it. And we do want to support more and more editors. So if you are familiar with Adam or Emacs or Vim on how to extend that with a language server, I would like to help. But I'm not really familiar with most of it. So you can contribute to the project. The GitHub address is on the Red Hat developer, VS Code Java. And then if you're using code, Visual Studio Code, you can just say x to install Java and it will be there. So I guess I have time for questions. With dependencies. OK. We use Gradle and Maven for the dependencies. So the question is, how does Java, language server, deal with the dependencies? So we use Gradle and Maven build artifacts. And then from those artifacts, we discover the dependencies and download them. For instance, for Maven, we also download the source code or for Gradle as well. We also download the source code so that we can provide better content assist and hover support. So strictly on Gradle and Maven, we do support Eclipse.classpad files as well. But we are not very competitive about that one. OK. So the question is, can language servers support multiple clients? It can. The JDDLS, the current implementation, doesn't do that. But it is possible to do that. The Microsoft's original definition of the language server protocol kind of assumes that you always start your own instance that is tied to a workspace. But it's not really restricted to that. You can actually have multiple servers, multiple clients using a single server. It's possible. We haven't implemented that so far, but I don't think we are far away from it. Any other questions? I'll give you 10 minutes of your life back. Thank you very much. Thank you.