With VDM++ and VDM-RT, background threads (such as those created by buses, CPUs and periodics) have started to report Java stack traces on stderr when these threads terminate. This is due to a change in Java 20, as part of the deprecation of the ThreadDeath mechanism for thread termination. Eventually, the java.lang.ThreadDeath exception will be removed completely.
This mechanism is used by VDMJ currently to handle thread termination, so that needs to be updated.
In VDM-VSCode, the problem seems to prevent execution via a "launch" codelens from displaying anything in the Debug Console. Instead, stack trace output appears in the Output window. A workaround is to open a Console session (a launch without a "command" entry), and execute the launch manually - the stderr output will appear when the session is closed.
The behavioiur appears to be harmless - that is, execution is not affected, but there is spurious stderr output and the console does not display for codelens launches.
With VDM++ and VDM-RT, background threads (such as those created by buses, CPUs and periodics) have started to report Java stack traces on stderr when these threads terminate. This is due to a change in Java 20, as part of the deprecation of the ThreadDeath mechanism for thread termination. Eventually, the java.lang.ThreadDeath exception will be removed completely.
This mechanism is used by VDMJ currently to handle thread termination, so that needs to be updated.
In VDM-VSCode, the problem seems to prevent execution via a "launch" codelens from displaying anything in the Debug Console. Instead, stack trace output appears in the Output window. A workaround is to open a Console session (a launch without a "command" entry), and execute the launch manually - the stderr output will appear when the session is closed.
The behavioiur appears to be harmless - that is, execution is not affected, but there is spurious stderr output and the console does not display for codelens launches.