Restarting spring-boot workspace, I see the shutdown doesn't complete, and the workspace is still not properly saved:

!ENTRY org.eclipse.jdt.ls.core 1 0 2019-04-12 15:32:09.126
!MESSAGE >> shutdown

!ENTRY org.eclipse.jdt.ls.core 1 0 2019-04-12 15:32:09.127
!MESSAGE Saving workspace
!SESSION 2019-04-12 15:32:14.400 -----------------------------------------------
eclipse.buildId=unknown
java.version=1.8.0_181
java.vendor=Oracle Corporation
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_CA
Command-line arguments:  -data /Users/fbricon/Library/Application Support/Code - Insiders/User/workspaceStorage/4b108579b42a00cd8343838a6a610090/redhat.java/jdt_ws

!ENTRY org.eclipse.core.resources 2 10035 2019-04-12 15:32:15.906
!MESSAGE The workspace exited with unsaved changes in the previous session; refreshing workspace to recover changes.

Restarting spring-boot workspace, I see the shutdown doesn't complete, and the workspace is still not properly saved:

Could you test with https://raw.githubusercontent.com/snjeza/vscode-test/master/java-0.43.1.vsix ?

This is on another workspace, but this looks much better, shutdown takes several seconds to complete, but does complete with your special build:

!ENTRY org.eclipse.jdt.ls.core 1 0 2019-04-12 16:25:34.321
!MESSAGE >> shutdown

!ENTRY org.eclipse.jdt.ls.core 1 0 2019-04-12 16:25:34.321
!MESSAGE Saving workspace

!ENTRY org.eclipse.jdt.ls.core 1 0 2019-04-12 16:25:37.599
!MESSAGE Workspace saved. Took 3277ms

!ENTRY org.eclipse.jdt.ls.core 1 0 2019-04-12 16:25:37.600
!MESSAGE Shutdown received... waking up main thread

!ENTRY org.eclipse.jdt.ls.core 1 0 2019-04-12 16:25:37.605
!MESSAGE class org.eclipse.jdt.ls.core.internal.JavaLanguageServerPlugin is stopping:
!SESSION 2019-04-12 16:25:39.447 -----------------------------------------------
eclipse.buildId=unknown
java.version=1.8.0_181
java.vendor=Oracle Corporation
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_CA
Command-line arguments:  -data /Users/fbricon/Library/Application Support/Code/User/workspaceStorage/4b108579b42a00cd8343838a6a610090/redhat.java/jdt_ws

!ENTRY org.eclipse.jdt.ls.core 1 0 2019-04-12 16:25:45.133
!MESSAGE class org.eclipse.jdt.ls.core.internal.JavaLanguageServerPlugin is started

!ENTRY org.eclipse.jdt.ls.core 1 0 2019-04-12 16:25:45.261
!MESSAGE Main thread is waiting

@fbricon @snjeza Could this change microsoft/vscode-languageserver-node#485 fix the parent watching process issue?

I have updated the PR.

@snjeza I tested this change on Windows and observed that after reloading the window, the message !MESSAGE The workspace exited with unsaved changes in the previous session; refreshing workspace to recover changes. will not be seen anymore.

One question: I think the key point is options.detached = true;, but according to current change, it will only be set when vmargs contains -DwatchParentProcess=, which is not contained in the default value of the vmargs. What's the purpose for that check?

One question: I think the key point is options.detached = true;, but according to current change, it will only be set when vmargs contains -DwatchParentProcess=, which is not contained in the default value of the vmargs. What's the purpose for that check?

We could set it as the default. It will not run tasklist (on Windows) or kill (on Linux/Mac)t after eclipse-jdtls/eclipse.jdt.ls#2115
This way, Java LS will be shut down on Windows properly.
@fbricon @rgrunber @testforstephen @CsCherrYY

@jdneo @snjeza How does this change solve the issue on Windows, with only defaults if -DwatchParentProcess=false is never passed as a JVM argument. It only gets set to false in prepareParams, which happens after the change in this PR. Did you manually set -DwatchParentProcess=false in java.jdt.ls.vmargs ?

@rgrunber you should set -DwatchParentProcess=30, 30 seconds delay

If this helps the situation, then I'm fine with merging. I just don't see how it would benefit the issue without users also overriding the default java.jdt.ls.vmargs in their settings. But if a manual change to a setting is required then most users likely won't benefit.

If this helps the situation, then I'm fine with merging. I just don't see how it would benefit the issue without users also overriding the default java.jdt.ls.vmargs in their settings. But if a manual change to a setting is required then most users likely won't benefit.

See #880 (comment)

When I tested this change, I manually changed the vmargs. options.detached = true; seems to work. I'm also confused the check for the -DwatchParentProcess.

@snjeza Could you help me understand the relationship between -DwatchParentProcess and options.detached = true;?

Could you help me understand the relationship between -DwatchParentProcess and options.detached = true;?

We have disabled watchParentProcess on Windows because Windows kills child processes when the parent process finishes.
This way, Java LS will not save a big workspace properly.
options.detached=true requires that Windows doesn't kill child processes and Java LS saves the workspace properly.
I have updated the PR. Now, it works in the following way:

• VS Code sets options.detached=true, watchParentProcess is not set, Java LS will exit and save the workspace properly when its parent process is dead. We can do it after Use ProcessHandle.of(long) to determine state of the parent process. eclipse-jdtls/eclipse.jdt.ls#2115 because Java LS will not start the tasklist command anymore.
• you can add -DwatchParentProcess=false to vmargs if you want old behaviour

Just found the previous background eclipse-lemminx/lemminx#328 to disable parentProcessWatcher by default. Since we've optimized the server-side parentProcessWatcher via the JDK native API, it is worth to enable it back if the performance gains are high. I suggest we put it in pre-release for a try first.