RFR: 8291917: Windows - Dump error diagnostics when runtime libraries fail to load [v3]

[Julian Waters]

On Sat, 6 Aug 2022 10:36:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing spacing between errors
>
> src/java.base/share/native/libjli/emessages.h line 111:
> 
>> 109: #define DLL_ERROR2      "Error: failed %s, because %s"
>> 110: #define DLL_ERROR3      "Error: could not find executable %s"
>> 111: #define DLL_ERROR4      "Error: Failed to load %s"
> 
> Have you looked into all usages of this macro, also non-windows/shared code? Please make sure the replacement text makes sense in all those cases.

The only non Windows code that uses the `DLL_ERROR4` macro is Unix's java_md_common.c, where it reports the same `JVM_FindClassFromBootLoader` issue that Windows also does, and the shared args.c when a file cannot be found by path:

static JLI_List expandArgFile(const char *arg) {
    JLI_List rv;
    struct stat st;
    FILE *fptr = fopen(arg, "r");

    /* arg file cannot be opened */
    if (fptr == NULL || fstat(fileno(fptr), &st) != 0) {
        JLI_ReportMessage(CFG_ERROR6, arg);
        exit(1);
    } else {
        if (st.st_size > MAX_ARGF_SIZE) {
            JLI_ReportMessage(CFG_ERROR10, MAX_ARGF_SIZE);
            exit(1);
        }
    }

    rv = readArgFile(fptr);

    /* error occurred reading the file */
    if (rv == NULL) {
        JLI_ReportMessage(DLL_ERROR4, arg);
        exit(1);
    }
    fclose(fptr);

    return rv;
}


In any case, the only thing that would change would be "Error: loading:" to "Error: Failed to load" as the prefix of the message, which semantically is the same whatever the context may be, just a small change I thought that would look better whenever the macro is used

-------------

PR: https://git.openjdk.org/jdk/pull/9749