five hours of real coding in Visual Studio Code

I tried to code for real in Visual Studio Code for the first time. This means not just dealing with my first impressions, but actually trying to get something done. I spent five hours coding today. The project I was working on uses Maven, Selenium and JUnit 5.

I tried to *only* use VS Code for the five hours of coding I did today. Learning any new tool is frustrating. I didn’t complete the development task I wanted to. But I made a decent amount of progress. And more importantly, I have a better understanding of the VS Code environment.

What I re-learned

I learned these when I was playing last time. But this time, I used them a bunch.

  • Shift Command/Windows P – Lets you type in the name of what you want to do. Useful when you don’t know the keyboard shortcuts or location of anything! I used it a lot for organize imports!
  • F12 – drill down into a class

What I learned for the first time

  • F2 – renames a method
  • The left explorer view has a “Maven Projects” section. This provides a visual way to run Maven clean/install/etc. it also provides a visual way to run effective pom. Or at least it did until I disabled the Maven integration. See the “challenges” section for why.

What I liked

  • Running a junit test is easy. Click “run test” over the class name or method name. This causes the test to run and a green (or red) status to appear in the bottom left line with how it went.
  • A green check or red x also appears next to each test method which you can click to see the test result details.
  • Extract to method is easy. Just highlight the code and click the lightbulb.
  • The git integration is good. It is clear on how to pull/push/commit/stash
  • Typing code was relatively easy.


  • F2 does not rename a class completely. It does rename the “public class” line. But it doesn’t rename the file. There was a github issue logged about this in August. It was closed because it was going to be resolved “soon”, but still seems to be a problem.
  • JUnit 5 tests in classes that end with * run normally but report as if they were skipped. This means integration is partial. If you open the test class, the green check or red x are correct. And the test explorer recognizes integration tests as tests. But the bottom bar status and test report show as skipped. I had to temporarily rename my test to * and name it back before committing for this to be usable. I reported this as an issue in the vscode-java-test project
  • There doesn’t appear to be an easy way to make the editor (the part where you type code) full screen. You can choose the command “Maximize editor group and hide sidebar”, but the problems/terminal/etc group is still at the bottom along with some visual clutter on the right. This means you actually have to drag stuff around. In Eclipse, you just double click the “title” and get full screen. More importantly, in Eclipse you double click again to get your original view back. This was requested back in 2016 so I doubt it will be added.
  • Printing something in JUnit doesn’t play well with the Maven integration. Seriously, even if you remember to switch the output tab to “test output”, nothing gets output. I quickly learned that I wasn’t the only one with this problem. It was also logged as a defect this month and sounds like it is being worked on. In the meantime, I disabled the Maven plugin. This isn’t terribly inconvenient because of the Terminal tab. I can still run a Maven build right from my editor.
  • You have to create packages and classes “manually.” This is annoying from deeply nested packages. It is also annoying to have to type the package declaration when creating a new class. This is because VS Code has the concept of folders/files vs packages/classes

What I had to fall back to Eclipse for

There were two tasks where I decided to use Eclipse rather than VS Code:

  1. I needed to paste a very long string. Eclipse adds the line breaks and string concatenation to make this elegant. VS Code does not. I could have spent 15 minutes doing it by hand, but I let Eclipse do it for me.
  2. Eclipse is really good at showing all the differences visually between two Strings in an assertion. (See #1 for my long string.) I could have read the text assertion to see the differences. But again, Eclipse is just so good at this.

converting word to markdown

Scott and I used Microsoft Word for our Hands On Lab at Oracle Code One. This worked “mostly” fine. The quotes are because we had a one merge conflict when writing the instructions.

At the conference, an attendee (Barry Evans) said he had some improvements to the docs and he’d submit a pull request. Less than useful in Word so I asked him to email me with change tracking. i thought better of that and decided to convert to Markdown.

It wasn’t as bad as I thought:

  1. First, I used the Word to Markdown converter to do a first level pass
  2. Then I manually split it into a page per step (cut/paste) and changed the table of contents to links.
  3. Next, I converted the images to local ones in the repo.
  4. Finally, I did cleanup on code that didn’t format right, lists that were broken and using better code tags.

I used Visual Studio Code as the markdown editor. (I’ve been trying to get more comfortable with VS Code). I learned:

  • Having the markdown file in the left pane and a split view with the preview is nice. They even stay in sync with content/paging.
  • Command up/down goes to the top/bottom of the doc.
  • Home/End goes to the beginning/end of a line.
  • You can test markdown links directly in the preview editor.
  • The preview editor shows images so I could easily spot typos.

I tagged the repo version with the Word doc in case I ever want to go back to what it looked like.


[2018 oracle code one] developing java applications with microsoft visual studio code

Developing Java Applications with Visual Studio Code
Speaker: Fred Bricon

For more blog posts, see The Oracle Code One table of contents

VS Code

  • Lightweight extensible “source code editor”
  • Open source
  • Developed by Microsoft, but vibrant community
  • Led by Erich Gamma (Gang of Four and one of the original authors of Eclipse)

Language Server Protocol

  • language specific smarts
  • standard protocol to minimize effort to support multiple development tools/languages
  • open source protocol
  • development led by microsoft
  • JSON RPC 2.0 messages
  • tool opens/edits docs/displays errors. language server initializes languages tools/identify compilation error/etc.

Eclipse JDT.LS

  • Implemented language server for Java in Java.
  • Running language server launches headless Eclipse behinds scenes
  • Adds custom commands
  • Extensible through OSGi bundles

Vs Code – Java

  • RedHat developed thin wrapper.
  • Launched late 2016
  • Updates about twice a month
  • Half a million extensions
  • Other Java tools
    • debugger (from MS)
    • test runner (from MS)
    • Fabric8 analytics
    • java decompiler
    • lombok support
    • checkstyle
    • maven
    • dependency analytics – new plugin to flag components with CVEs. Plugin not completely ready. Not all CVEs loaded yet. Just something to play with at this point.
  • VS Code LiveShare – plugin where can share content of workspace with up to 50 people. They can even set breakpoints in your workspace.

Next steps

  • Better refactoring support
  • Quick fixes from problems view
  • Huge backlog; more improvements soon


Note: I have a bunch of notes to myself of things I want to try. I also want to ask Thomas for a copy of his workspace preferences file. It seems more reasonable than the defaults.

  • Autocompletion
  • Lightbulb with option to run/debug – have to turn on code lens in workspace settings
  • Click triangle in bottom left corner to see problems/output/debug console view at bottom
  • F2 = rename variable [command F2 on Mac]
  • Debugger on left view on screen
  • Showed hiding . files . Preference > settings. Edit workspace settings to control Ant style patterns on what see. (Edit settings as json)
  • New Java Dependencies plugin. Came out recently. Can see Maven dependencies
  • Command shift o – see outline in file [want to try; didn’t work on first shot]
  • command p – list all files in project
  • Command click – navigate into class [want to try; didn’t work on first shot]
  • Organize imports – alt shift o
  • Saving gives instant feedback – need to turn on
  • Run test runner. Code lens shows red/green test status in class itself.
  • Can type “get” and getters are suggested (vs typing them in)
  • Showed changing code while app is running
  • Using a bad dependency gives CVE error in problems view

My take: FRC (FIRST Robotics Competition) teams are using VS Code this year. I’ve learned a little but am nowhere near fluent. So was really looking forward to the demo. Plus hearing the story of how the plugins came to be is interesting. But seeing someone use it who is comfortable with the tool is even more valuable.