Simplify generated launch.json

[isidorn]

Hey,

VSCode dev here. This milestone I am looking into simplifing generated launch.json for various extensions microsoft/vscode#62851

The launch.json that Java generates is attached at the end. This is not too complex for the avarage user, however we can still improve. I suggest to simplify it the following way:

• DebugConfigurationProvider should use the quickPick to ask the user if he would like to launch or to attach. After that it should ask what is the mainClass or what is the port. Optimally it should be able to detect those things on its own, but if not possible use quickPick to ask the user.
• Remove default fields which are not necessery like console, args, stopOnEntry, hostName and cwd
• You are already contributing configuraitonSnippets which is great. However these snippets also need to be simplified. I suggest to remove all attributes that have the default value. Example: stopAtEntry, cwd, args

If you agree with the suggestions I am making here I am also here to help with any potential questions you might have. The changes should not require a lot of work but will simplify the flow a lot imho. It should be much less complex and not too much like a wizard experience

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "java",
            "name": "Debug (Launch)",
            "request": "launch",
            "cwd": "${workspaceFolder}",
            "console": "internalConsole",
            "stopOnEntry": false,
            "mainClass": "",
            "args": ""
        },
        {
            "type": "java",
            "name": "Debug (Attach)",
            "request": "attach",
            "hostName": "localhost",
            "port": "<debug port of remote debuggee>"
        }
    ]
}

[isidorn]

@testforstephen Are there any plans to address this?
Do you agree with my suggesstions here?
If you do not have cycles to address this but would like to see it done, I can try to get some users to provide a PR which tackles this.

Thanks a lot

[testforstephen]

@isidorn Is there any strong reason to shorten the launch.json? Because we found the user will be pretty hard to discover the hiding launch options.

Here is my thoughts about the removable options:
Ok to remove stopOnEntry from the default options, Neutral on cwd, hostName. But i'd like to keep console, args. VS Code default CONSOLE doesn't support program input, so that the user frequently reports not knowing how to specify program input. And args is helpful for the console program.

[isidorn]

@testforstephen thanks for the reply. Well it is a delicate belance of showing just enough such that it does not look too complex and is discoverable enough. Shorting the configuration makes it look and feel simpler for the user.
With regards to that it is perfectly fine to keep some fields for discoverability, however I would only keep those which the users depend on a lot.
So I agree with you, keeping console and args makes perfect sense. stopOnEntry should be removed and cwd and hostName should be removed as well if the users do not change it often.

As for the mainClass is it possible that your extension somehow auto detects this and fills it in properly for the user when the launch configuration is generated?
For example node is currently looking into the users package.json to properly fill in the program attribute. If not, does it make sense to aks the user to input this at the moment of launch.json generation?

[testforstephen]

yes, mainClass option will be automatically filled when java debugger generates launch.json.

[isidorn]

@testforstephen aha ok. I only got the "" because i had no main in my workspace.
Maybe default to "${file}" if you can not detect the main, could be better than the empty string

What do you think about the suggestion that DebugConfigurationProvider could use the quickPick to ask the user if he would like to launch or to attach?

[testforstephen]

Maybe default to "${file}" if you can not detect the main, could be better than the empty string.

@isidorn I like this suggestion. We can check whether the active file is a main class (having main method) or not. If so, then launching it directly, otherwise, searching all possible main classes in the workspace and use quickPick to prompt user to choose one.

What do you think about the suggestion that DebugConfigurationProvider could use the quickPick to ask the user if he would like to launch or to attach?

What scenario is this for? No launch.json case?
For no launch.json case, F5 and the debugger will resolve all possible main class list and generate their corresponding launch configurations.

[isidorn]

@testforstephen great, I like your suggestion for mainClass.

Oh so the no launch.json case seems to be covered quite well if you generate all corresponding launch configuraitons.

I am just trying to give some suggestions on how to simplify this, in the end you know much better what would lead to a better Java debugging experience. So let me know if there is something on the vscode side which we could do to improve this

[chadirino]

I am just a beginner here but the auto-detection of the fully qualified class name (for the mainClass option) would be a great update -- it would definitely shorten and simplify the launch.json file (removing the need to list each class). I also find relying on the quickPick option to choose the class name to be frustrating (I have chosen the wrong one many times and it would obviously save a few seconds each launch).

I agree that the stopOnEntry option isn't important and that the console option should be there (for user input). I am neutral on the rest.

[testforstephen]

@chadirino Glad to hear your feedback. The real user's feedback is definitely helpful for us to improve the product. Thanks.

To improve the auto-detection, we plan to generate a configuration at the beginning of launch.json.

{
     "type": "java",
     "name": "Debug (Launch) - Current File",
     "request": "launch",
     "console": "internalConsole",
     "mainClass": "${file}",
     "args": ""
}

But the auto-detection will be only based on your current focus editor. If your current opening editor file is not a Java file with main method, then prompt you to choose the main entry with quickPick option.

I also find relying on the quickPick option to choose the class name to be frustrating (I have chosen the wrong one many times and it would obviously save a few seconds each launch).

Is it because the option format is not friendly or other reasons to cause the wrong pick?

[chadirino]

Thanks for the response, @testforstephen. I am glad that I can be of some help to you -- your work is great and really appreciated! That goes to you too, @isidorn.

To improve the auto-detection, we plan to generate a configuration at the beginning of launch.json.

I see -- you are using ${file} to check if the current focus editor is for a Java file with a main method. I have always run my code from within the file so I think that works just great! And I do think it is good to keep the quickPick option for when it is not a Java file.

Is it because the option format is not friendly or other reasons to cause the wrong pick?

I just analyzed it real quick -- It's definitely intuitive so it must come down to the choice in the defaulted class name (and that I probably don't pay enough attention). It looks like the recently used quickPick default overrules the active editor one. Given that the class name is currently not auto-detected, and that I always run the file from within the code, the active editor default, however, would have been my preferred one (so I can mindlessly choose the option). I also sometimes run classes with the same name but in different packages -- so that might have triggered a wrong pick or two.

I said "many times" (which might have been an exaggeration) but I suppose it couldn't have been more than 10 times that I chose the wrong class name. Nevertheless, assuming the auto-detection will be added, the active editor default will no longer be needed (right? idk) and my issue will no longer exist.

[testforstephen]

@chadirino Nice to know your scenario, thanks.
yes, the current file support should fix the active editor default issue, too.

[testforstephen]

@patelkunal Hope this solution will fix the issue Introduce shortcut to launch program from active editor too.

[testforstephen]

0.16.0 release contains the change. close this task.

[isidorn]

@testforstephen great, thanks a lot!