This article is more than 1 year old
Improved Java support poured into Microsoft's Visual Studio Code – will it be enough to tempt developers?
Redmond's open-source code editor is not the equal of heavyweight Java IDEs but still has attractions
Microsoft has announced several improvements to Java support in Visual Studio Code, its popular open source editor.
Visual Studio Code is a general-purpose editor but benefits from thousands of extensions (there are currently thousands listed in the extension marketplace. Language Support for Java (an extension created by Red Hat though still marked Preview) is the 7th most popular, with 4.6 million installs, below Python, C/C++. ESLint, C#, Debugger for Chrome, and the Prettier code formatter.
A better choice for most Java developers is Microsoft’s Java Extension Pack, which installs the Red Hat Language Support as well as a debugger, test runner, Maven, dependency viewer, and Visual Studio IntelliCode. There is also a Spring Boot extension pack for those working with the Spring framework.
So what’s new for Java in Visual Studio Code? Senior program manager Xiaokai Hi describes a number of updates, headed by a new Call Hierarchy view. Right-click a function, choose Peek – Peek Call Hierarchy, and you get a list of outgoing or incoming calls - with a toggle button to switch between them – and the ability to drill down into the tree.
Another new feature is Data Breakpoints, which let you set a breakpoint when the value of a variable changes. In addition, code actions (lightbulb suggestions in the editor) are now sorted by “relevance” – presumably determined by AI of some sort – and there is a new quick fix to correct access modifiers for static elements. Users of the Java Test Runner extension can see test results directly in the Test Explorer.
While these are not huge improvements, VS Code has gradually evolved into an effective lightweight Java development tool. While is it not a full-featured as dedicated IDEs like JetBrains IntelliJ IDEA (or Android Studio which is based on IntelliJ), or Apache NetBeans, its speed and relative simplicity is n attraction.
VS Code is attractive for developers working in multiple programming languages, since you can use the same editor and rely on there being adequate extensions for whatever you need to work on. It is also cross-platform and free to use.
How much headway has VS Code made among Java developers? It is always hard to find reliable statistics. JetBrain’s own survey put it at just 3 per cent, behind not only IntelliJ IDEA (no surprise) but also Eclipse, Android Studio and NetBeans. In the StackOverflow 2019 survey though, VS Code is used by 53.8 per cent of mobile developers - many of whom use Java to target Android – just behind Android Studio but ahead of IntelliJ at 31.1 per cent.
Traditionally the Eclipse IDE has been a favourite among Java developers, perhaps particularly for enterprise Java as opposed to Android development. The original Eclipse IDE is still very capable and in the latest version, 2019-12, has tooling for Java 13 as well as claimed performance improvements.
Theia is not the only connection between Eclipse and VS Code. Red Hat’s Java language extension for VS Code uses the Eclipse JDT Language Server. It is also notable that Erich Gamma, one of the “gang of four” who wrote an influential book on design patterns back in 1994, was one of the original designers of Eclipse before joining Microsoft in 2011 to work on Visual Studio Code.
Theia seems unlikely to catch up with VS Code at this point though, despite Eclipse executive director Mike Milinkovich bemoaning Microsoft’s “monopoly on both development experience and [via GitHub] artefact pipepines”.
VS Code is not the equal of the commercial IntelliJ IDEA for Java development, nor as complete as the other dedicated Java IDEs, but for now it does offer a nice balance of performance and features, as well as the ability to transition seamlessly to being a cloud IDE.
The main risk is that the pressure to add more and more features will, in time, remove its advantage and make way for new and more nimble tools, and that is what Gamma and his colleagues must work hard to avoid. ®