Jpackage created single executable does not respond CTRL_C_EVENT or CTRL_CLOSE_EVENT

[rifatdover]

Describe the bug
Jpackge packed java application does not respond CTRL_C_EVENT or CTRL_CLOSE_EVENT

Desktop (please complete the following information):

Tested over Windows Server 2019 most probably exist over other

MSFT Build of OpenJDK Version:

openjdk 21.0.6 2025-01-21 LTS
OpenJDK Runtime Environment Microsoft-10800203 (build 21.0.6+7-LTS)
OpenJDK 64-Bit Server VM Microsoft-10800203 (build 21.0.6+7-LTS, mixed mode, sharing)

To Reproduce:
Create this java file under MyApp\src\com\example\Main.java

package com.example;

public class Main {
    public static void main(String[] args) {
        System.out.println("Application started.");

        Runtime.getRuntime().addShutdownHook(new Thread(() -> {
            System.out.println(">>>>> Shutdown hook triggered.");
            try {
                Thread.sleep(3000); // Simulate cleanup
                System.out.println(">>>>> Cleanup complete.");
            } catch (InterruptedException e) {
                System.out.println(">>>>> Interrupted during cleanup.");
            }
        }));

        System.out.println("Press Enter to exit...");
        try {
            System.in.read();
        } catch (Exception e) {
            e.printStackTrace();
        }

        System.out.println("Exiting app...");
        System.exit(0);
    }
}

Use this batch script to build the app under MyApp\build.bat.

@echo off
setlocal

:: ======= CONFIGURATION =======
set MAIN_CLASS=com.example.Main
set APP_NAME=MyApp
set SRC_DIR=src
set OUT_DIR=out
set JPACKED=jpacked
set JAR_NAME=%APP_NAME%.jar
set MANIFEST_FILE=manifest.txt
set PACKAGE_DIR=package
:: =============================

echo [INFO] Cleaning output and package directories...
if exist %OUT_DIR% rmdir /s /q %OUT_DIR%
if exist %PACKAGE_DIR% rmdir /s /q %PACKAGE_DIR%
if exist %JPACKED% rmdir /s /q %JPACKED%
mkdir %OUT_DIR%
mkdir %PACKAGE_DIR%

echo [INFO] Compiling Java sources...
javac -d %OUT_DIR% %SRC_DIR%\com\example\*.java
if %ERRORLEVEL% neq 0 (
    echo [ERROR] Compilation failed.
    exit /b 1
)

echo [INFO] Creating manifest file...
echo Main-Class: %MAIN_CLASS% > %MANIFEST_FILE%

echo [INFO] Creating JAR file...
jar cfm %PACKAGE_DIR%\%JAR_NAME% %MANIFEST_FILE% -C %OUT_DIR% .

if %ERRORLEVEL% neq 0 (
    echo [ERROR] Failed to create JAR.
    exit /b 1
)

echo [INFO] Building native executable using jpackage...
jpackage --input %PACKAGE_DIR% --name %APP_NAME% --main-jar %JAR_NAME% --main-class %MAIN_CLASS% --dest %JPACKED%/dist --win-console --type app-image

if %ERRORLEVEL% neq 0 (
    echo [ERROR] jpackage failed.
    exit /b 1
)

echo [INFO] Build complete. Executable created at:
echo   %JPACKED%\dist\%APP_NAME%-1.0.exe

:: Optional: run the EXE
echo.
set /p RUN_NOW="Run the EXE now? (y/n): "
if /I "%RUN_NOW%"=="y" (
    echo [INFO] Running the EXE...
    "%JPACKED%\dist\%APP_NAME%-1.0.exe"
)

:: Cleanup (optional)
del %MANIFEST_FILE%
echo [INFO] Done.
endlocal

Expected behavior
When application interrupted with Ctrl+C ShutDownHooks should be activated. Which is working with a java command. For example when application started with java -jar package\MyApp.jar and Ctrl+C pressed shutdown hooks are activated. But when you run the app via jpacked\dist\MyApp\MyApp.exe Shutdown Hooks is not activated.

Screenshots, Logs etc
On both runs Ctrl+C used to exit.

Additional context
This problem may also be present on https://github.com/openjdk/jdk

[karianna]

This is a known limitation (but not widely documented) of how native executables created with jpackage interact with console control events like CTRL_C_EVENT or CTRL_CLOSE_EVENT on Windows.

When you use jpackage with --type app-image and --win-console, the generated executable is a native Windows launcher that starts the Java runtime in a subprocess. Because of this:

• The launcher process receives CTRL_C_EVENT, not the JVM subprocess.
• On Windows, CTRL_C_EVENT is sent only to processes attached to the same console, and not necessarily to child processes unless special handling is done.
• Since the JVM subprocess doesn’t receive the signal directly, it doesn’t trigger the shutdown hooks.

As you mentioned, in contrast, when you run the application with:

java -jar MyApp.jar

you’re directly running the JVM in the terminal session, so it does receive the signal, and shutdown hooks work as expected.

---

We're currently not aware of any easy/trivial workarounds. If this is a critical feature then we can suggest some of the more challenging approaches you could take, but most folks we know simply document this exceptional case for their customers.

[rifatdover]

Thanks a lot for your response @karianna.

[KalleOlaviNiemitalo]

I'm curious, why is the child JVM process not attached to the same console?

[karianna]

I'm curious, why is the child JVM process not attached to the same console?

Great question — and the answer lies in how Windows handles process creation and console attachment, particularly when jpackage creates native launchers.

When you run a native executable (like the .exe created by jpackage), the JVM is started as a subprocess from the launcher that jpackage generates.

Here’s what typically happens under the hood:

1.	The jpackage-generated .exe is a native launcher built using C/C++.
2.	This launcher spawns a new JVM process — often via CreateProcess or similar Win32 API.
3.	Unless explicitly told to do so, Windows does not automatically attach the child process to the parent console.
4.	As a result, signals like CTRL_C_EVENT and CTRL_CLOSE_EVENT are only delivered to the launcher process, not its child JVM.

[karianna]

@rifatdover - I'll close this issue as wontfix, hopefully it's not to painful for your users!

[KalleOlaviNiemitalo]

This launcher spawns a new JVM process — often via CreateProcess or similar Win32 API.

Is the executable that is launched via CreateProcess marked as a console application or a GUI application, according to the subsystem field of the header? If it is a console application (like java.exe), it should inherit the console of the parent process, unless specific flags in the CreateProcess call prevent that. If it is a GUI application (like javaw.exe), it shouldn't.

Without checking how jpackage currently works, I can imagine the following fixes or workarounds:

• Change jpackage to mark the executable of the JVM process as a console application.
• After packaging with jpackage, patch the subsystem field of the JVM executable file. If jpackage does any code signing, this could break that.
• Call AttachConsole(ATTACH_PARENT_PROCESS) from within the JVM process. This could be done by the Java application, using a foreign-function interface.
• Specify consoleAllocationPolicy in the Win32 application manifest of the JVM executable. It's still not documented at Application manifests, but see Allow console allocation policies that are finer-grained than the PE image subsystem terminal#7335.

[rifatdover]

Thanks a lot for your response @KalleOlaviNiemitalo

• Call AttachConsole(ATTACH_PARENT_PROCESS) from within the JVM process. This could be done by the Java application, using a foreign-function interface.

I tried this solution but it did not work. Also I tried to attach the JVM pid.

• Specify consoleAllocationPolicy in the Win32 application manifest of the JVM executable. It's still not documented at Application manifests, but see Allow console allocation policies that are finer-grained than the PE image subsystem terminal#7335.

I will try this and inform here thanks.