openjdk/jdk · error

no '/' found in the full path of the executable

Error message

no '/' found in the full path of the executable

What it means

From the Unix java launcher relauncher (the small program that execs the real 'java' binary living next to it, used for the JDK 8->9+ launcher compatibility shim). After realpath(argv[0]) succeeded, strrchr(path, '/') found no slash, so it cannot derive the directory that should contain the real java executable; it prints the message and returns exit code 1.

Source

Thrown at src/java.base/unix/native/launcher/relauncher.c:53

#error LAUNCHER_ARGS must be defined
#endif

static char *launcher_args[] = LAUNCHER_ARGS;

int main(int argc, char *argv[]) {
    ////////////////////////////////////////////////////////////////////////////
    // Create a fully qualified path to the java executable in the same
    // directory as this file resides in.

    char *our_full_path = realpath(argv[0], NULL);
    if (our_full_path == NULL) {
        perror("failed to get the full path of the executable");
        return 1;
    }

    char *last_slash_pos = strrchr(our_full_path, '/');
    if (last_slash_pos == NULL) {
        fprintf(stderr, "no '/' found in the full path of the executable\n");
        return 1;
    }

    size_t base_length = last_slash_pos - our_full_path + 1;
    size_t java_path_length = base_length + strlen(JAVA_EXECUTABLE_NAME) + 1;

    char *java_path = malloc(java_path_length);
    if (java_path == NULL) {
        perror("malloc failed");
        return 1;
    }

    memcpy(java_path, our_full_path, base_length);
    strcpy(java_path + base_length, JAVA_EXECUTABLE_NAME);

    ////////////////////////////////////////////////////////////////////////////
    // Build the argument list: our executable name + launcher args + users args

View on GitHub (pinned to 88dfb74bbe)

Solutions

1. Verify the JDK installation layout: the relauncher and the 'java' executable must sit in the same bin/ directory
2. Invoke java via its real path (absolute or a proper PATH entry) rather than exotic argv[0] tricks; avoid replacing/deleting the binary while it runs
3. Reinstall or re-extract the JDK image if the bin directory is inconsistent (missing java executable next to the relauncher)
4. If this reproduces in a container, check that the binary is mounted from a normal filesystem and not modified between exec and realpath

Example fix

# before
./some-weird-link-to-jdk/bin/java -version   # broken link target

# after
/path/to/jdk/bin/java -version                 # intact bin directory

# Verify the launcher directory is intact before invoking:
JH=/path/to/jdk
[ -x "$JH/bin/java" ] && [ -x "$JH/bin/jexec" ] 2>/dev/null || echo "check $JH/bin layout"

When it happens

Trigger: argv[0] resolves (via realpath) to a path with no '/' component — in practice only possible when the resolved absolute path degenerates (e.g. the program is invoked such that realpath returns a relative name because the executable was deleted/replaced while running, or a container/ptrace environment gives a bogus argv[0]). On POSIX, realpath normally yields an absolute path starting with '/', so this is a defensive almost-unreachable branch.

Common situations: Corrupted JDK installation where the relauncher's own binary has been unlinked while executing; unusual exec environments (chroot, containers, LD_PRELOAD path games) producing non-absolute realpath results; a broken symlink chain ending in a bare filename.

Related errors

• failed to get the full path of the executable: %lu
• no '\' found in the full path of the executable
• CreateProcess failed: %lu
• VM warning: the use of signal() and sigset() for signal cha
• WaitForSingleObject failed: %lu

AI-assisted analysis of openjdk/jdk@88dfb74bbe (2026-08-14). Data as JSON: /api/errors/453fe01c76997a02. Report an issue: GitHub.