2 posts tagged with "vscode"

I'm definitely not the first developer to say that quick fix suggestions make my life ten times easier. With dynamic proposals for code actions, my life gets even easier.

Many quick fixes have multiple suggestions for text replacement. In the Eclipse IDE, these are displayed in a dropdown selection menu. Take a look at the type mismatch quick fix below, for example:

Very helpful, right? Now let's take a look at how VS Code handles the same quick fix:

No dropdown, no options, just the first item from Eclipse's list inserted statically. Definitely less helpful.

Why is this? Well, code actions in Eclipse support dropdown choices, as well as placeholders, which enable dynamic text insertion/replacement. Code actions in VS Code, on the other hand, do not. The closest we can get to simulating this behaviour in VS Code is by using snippets, which similarly have choices/placeholders. Unfortunately, we couldn't support snippet strings in code actions without violating the Language Server Protocol specification... until now!

With the introduction and support of SnippetTextEdit in LSP and VS Code, dynamic code actions will now be supported in the upcoming release of vscode-java 1.35.0! If you can't wait, they're also available now in pre-release.

Check out the relevant PR in vscode-java and its supporting PR in JDT-LS.

The Point​

Code actions, which were once completely static, now prompt you to alter relevant sections of text and give you multiple suggestions for insertion and replacement.

Pretty cool.

Limitations​

This improvement doesn't come without a few minor setbacks.

For code actions that propose new types, the import for the selected type cannot be automatically resolved. Instead, after applying the code action and selecting the new type from the dropdown, the user has to either manually import the type, apply the subsequent quick fix suggestion to import the type, or issue the 'Organize Imports' command (Shift + Alt + O).

Additionally, any code action that involves multi-line text insertion will see additional indentation on all lines excluding the first one. You can see this happen in the above example. This is due to a bug in VS Code that automatically adds indentation to snippet strings.

A percentage (~4%) of users trying out our latest release of vscode-java 1.33.0 were probably disappointed to note that we dropped support for Java versions prior to 1.8. This wasn't something we did intentionally but it happened in the JDT Core library that we rely on for much of our Java functionality. While losing existing functionality is frustrating, I'll go over why this change was necessary and how it will set up the JDT Core project, the Java language server (JDT-LS), and vscode-java for success in the longer term.

There's a JEP for that​

JEP-182 already defines a process for this exact thing. Although the policy would have to change to take into account the 6-month release cadence, it's clear that a move towards supporting fewer older releases is desired.

As of now, javac from the OpenJDK 22 developments tools no longer support a pre-1.8 source/target/release flag :

$ javac --help
  ...
  ...
  --release <release>
        Compile for the specified Java SE release.
        Supported releases:
            8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22
  ...
  ...

Maintenance burden​

Going through the discussion ( https://github.com/eclipse-jdt/eclipse.jdt.core/discussions/820 ) in JDT Core to drop the support, it's clear there's a cost to supporting the older versions. It also affects the time it takes to implement new features that must deal with the added complexity from those older versions. Simplifying the codebase will translate into more features, implemented more quickly and an easier maintenance.

Perspective​

So where does that leave affected users ? They could continue to stay on vscode-java 1.32.0, until they update their project to Java 1.8 or above. It's definitely not ideal for those depending on older Java versions but the newer features, and improvements should certainly make up for it.