Gorkem Ercan

Recent Posts

demo of features

YAML Language Server and the Extension for VS Code

Over at the Openshift and Che land, we deal with YAML files for deploying our applications regularly. Unfortunately, the tooling to support editing of these files was not up to our expectations. As we are also tooling developers, we have decided to take matters at hand and implement a language server for kubernetes syntax. An effort which mostly Josh Pinkney and I have worked on for the last few months. As we have progressed with our implementation, we have realized that limiting the extension to kubernetes was wasted opportunity and we have reorganized the language server for general YAML support but kept the kubernetes syntax support built-in.

Continue reading “YAML Language Server and the Extension for VS Code”

Share

Java Language Support for Visual Studio Code enters the Million Downloads Club

It has been a year since I posted the announcement about the availability of the Java Language Support for Visual Studio Code. During this past year, we made 10 releases, added various features, fixed many bugs but more importantly, we have constantly grown our user base and finally reached and passed a million downloads on the Visual Studio Marketplace.

Continue reading “Java Language Support for Visual Studio Code enters the Million Downloads Club”

Share

Java Language Support for Visual Studio Code has landed

Java language server is an implementation of the language server protocol for Java. If you recall, language server protocol provides a common way for editors and IDEs to integrate with language smartness providers. By design, all of the language tooling magic happens on the Java language server, and can provide same level of smartness to tools that support the protocol. In fact, we are working with communities such as Eclipse Che to make this server available for their tools.

Continue reading Java Language Support for Visual Studio Code has landed

Share

A common interface for building developer tools

“There is already a command line for it, why can’t my favorite editor support this language?” As a developer, you’re probably familiar with this sentiment, and in reality there has never been a better time to be a software developer.

Developers have access to a growing list of languages, frameworks, libraries, and technologies that can help them solve the problems they are tasked to tackle. However, the abundance of choices often hinders the ability of Integrated Development Environments (IDEs) and code editors to support such an abundance of choice. As a result,  developers often choose to use multiple IDEs and editors for building their solutions, in order to get access to best IDE support.

IDEs are frequently architected to have direct access to the tools related to the technology for which they were designed — for programming languages this often means that IDE has access to parsers, compilers and an in memory presentation of the developed code usually in the form of an Abstract Syntax Tree (AST). This approach also means that IDE developers need to create and maintain these tools.

As an example, Eclipse Java Development Tools (JDT) project provides a compiler for Java and a Java editor which in turn uses the AST generated to implement features like code assist, outlines, refactoring, etc.

Another approach is to define an API that the IDE will invoke to provide language features. In this architecture, the IDE has no real knowledge of the programming language and instead relies on the implementations of the interface.

We think this approach has a couple of advantages: first, it allows the interfaces to be implemented by the communities that create the technology, and so know it best; second, it frees up IDE developers for what they know best — we think this results in better IDEs and editors.

Unfortunately, we do not get the full benefits of the approach because there are as many of such interfaces defined as there are editors and IDEs.

Continue reading “A common interface for building developer tools”

Share