Improve support for "standalone file" use cases

[anthonyvdotbe]

When working with standalone files, the "Classpath is incomplete" warning shows up and only syntax errors are reported.

There are several use cases for standalone files, such as:

• working with a Java file to be run in the terminal directly, without any project involved (and without even needing to compile, simply doing java Test.java). This is useful for quickly trying things out, but is also a use case for people who just get started learning Java and don't use projects (and may not even have learned about the classpath/modulepath yet).
• using VS Code as the default JShell editor
• opening a file in a project to browse the source code

In all these use cases, I'd like VS Code to compile the file as usual with an empty class- and modulepath. I believe the first 2 use cases don't need further motivation, since it's the natural thing to do.

For the 3rd use case, I disagree with the wiki when it says:

It makes it useless to report compilation errors, as the UI would be filled with distracting red errors all over the file

I don't perceive the errors as distracting: in a typical case, most of them are in the imports. The wiki page uses test classes with lots of static imports, which results in a lot more errors, but this is not a typical case. (Ideally, the extension would ask if it should look for a Maven/Gradle/Eclipse file in any of the file's parent folders, such that there wouldn't be any errors at all. In that case, the "Classpath is incomplete" warning would only be given if no such file could be found, which would be very rare, imho.)

Environment

• Operating System: Windows 10
• JDK version: 13
• Visual Studio Code version: 1.42.0
• Java extension version: 0.55.1

[testforstephen]

@anthonyvdotbe thanks for sharing your thoughts on the "standalone file" support. We're revisiting the UX for this part, too.

At first, let me clarify the current support on the "standalone file". The extension provides two kinds of support for the "standalone file".

• Syntax mode - only report syntax error, but still support auto complete and run/debug features

When you open an arbitrary Java file in VS Code, for example, invoke "Open File..." menu or drag a file to VS Code. The extension will support your file with syntax mode. When opening a single file in VS Code, we infer there are two intentions: read-only and edit/run. For read-only users, show lots of red errors will affect the reading experience. But for the editing users like your 1st use case, providing semantic errors are also necessary and helpful. So we're thinking to provide a switch in the editor to allow the user to enable semantic errors for the current file, so that the user can determine to show the semantic errors on demand.

• Project mode - full feature support
  When you open a folder with standalone java files in VS Code, the extension will create an invisible project to manage your folder. It provides full feature support. You even are able to create a lib folder in the root folder, and the extension will take the jars under the lib as the libraries for the standalone files. This approach is recommended for standalone java files.

Then go back to the use cases you mentioned.

• for 1st use case, if we provide some way to allow you to enable semantic errors, do you think it mitigates your requirement?
• for 2st use case, this is definitely the direction we want to explore. But considering jshell is a new feature brought by Java 9, and many users are still using Java 8. This is not in our first priority yet.
• for 3st use case about opening a file in a project to browse the source code. We're trying to make the detect mechanism more smart. For example, if you're opening src or a sub package folder from a maven or gradle project, we will support it with syntax mode. because maven and gradle project has the fixed file structure, the detection is doable. If you're opening a usual folder with java files, serve it with project mode.

[anthonyvdotbe]

@testforstephen thanks for pointing out the existence of Project mode, that's really useful

for 1st use case, if we provide some way to allow you to enable semantic errors, do you think it mitigates your requirement?

Yes, a switch for enabling semantic errors would be great.

[fbricon]

Thanks to @testforstephen , we now have an improved syntax mode for non-project Java files:

• Deleted the notification message box about "classpath is incomplete. Only syntax errors will be reported".

• Added a general non-project warning diagnostic, see screenshot below.

• Provided a quickfix to enable/disable semantic errors. (More quick fixes could be enabled in the future, such as Add to source path for those not on classpath.)

  Enable semantic errors:
  
  Disable semantic errors:
  

[elliotaplant]

Thank you for adding the option to "Only report syntax errors for any non-project file in current session"

Is there a way to completely hide the warning that says "xxx.java is a non-project file, only syntax errors are reported"? Now that I am aware that only syntax errors will be reported, the error is no longer actionable.