> Second attempt at resolving
> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
> intrusive approach this time
>
> Side note: While it might be preferred to remove this entirely, other areas
> of the JDK also use the same flawed logic, and removing this would simply
> p
> Second attempt at resolving
> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
> intrusive approach this time
>
> Side note: While it might be preferred to remove this entirely, other areas
> of the JDK also use the same flawed logic, and removing this would simply
> p
> Second attempt at resolving
> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
> intrusive approach this time
>
> Side note: While it might be preferred to remove this entirely, other areas
> of the JDK also use the same flawed logic, and removing this would simply
> p
> Second attempt at resolving
> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
> intrusive approach this time
>
> Side note: While it might be preferred to remove this entirely, other areas
> of the JDK also use the same flawed logic, and removing this would simply
> p
> Second attempt at resolving
> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
> intrusive approach this time
>
> Side note: While it might be preferred to remove this entirely, other areas
> of the JDK also use the same flawed logic, and removing this would simply
> p
> Second attempt at resolving
> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
> intrusive approach this time
>
> Side note: While it might be preferred to remove this entirely, other areas
> of the JDK also use the same flawed logic, and removing this would simply
> p
> Second attempt at resolving
> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
> intrusive approach this time
>
> Side note: While it might be preferred to remove this entirely, other areas
> of the JDK also use the same flawed logic, and removing this would simply
> p
On Thu, 18 Aug 2022 15:46:04 GMT, Julian Waters wrote:
> Initially I did intend to do that, but a raw GetLastError wouldn't exactly be
> very helpful when a failure does occur
I disagree. Error codes are well documented, unlike posix errno with defined
numerical values, and often more helpful
On Thu, 18 Aug 2022 11:23:00 GMT, Julian Waters wrote:
> I don't quite get what you mean?
The only thing JLI_ReportErrorMessageSys has above JLI_ReportErrorMessage is
that it prints the error code for you, and that is a very slim win. It turns
into a loss quickly if it does that one thing wron
On Thu, 18 Aug 2022 09:55:59 GMT, Thomas Stuefe wrote:
>> 8291917 was simply about making error messages more informative on Windows
>> when loading the C Runtime or Java Virtual Machine dlls failed (Right now it
>> just prints an unhelpful "Error: loading: ...") - It consequently depended
>>
On Thu, 18 Aug 2022 09:46:56 GMT, Julian Waters wrote:
>> Let's back up a bit.
>>
>> I looked again, and think @dholmes-ora was originally right when he wrote
>> that this coding does not get called on Windows. Not sure why I thought
>> differently, but I cannot find a single callsite on windo
On Thu, 18 Aug 2022 08:52:36 GMT, Thomas Stuefe wrote:
>> I was mainly concerned with Thomas's objection that having both would simply
>> be misleading, though now that you say that, maybe this warning combined
>> with both could be a good compromise.
>>
>> @tstuefe thoughts?
>
> Let's back up
> Second attempt at resolving
> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
> intrusive approach this time
>
> Side note: While it might be preferred to remove this entirely, other areas
> of the JDK also use the same flawed logic, and removing this would simply
> p
On Thu, 18 Aug 2022 08:10:34 GMT, Julian Waters wrote:
>> src/java.base/windows/native/libjli/java_md.c line 621:
>>
>>> 619: char *errtext = NULL;
>>> 620:
>>> 621: char* const conflict = "Java detected conflicting Windows and C
>>> Runtime errors and is unable to provide an accurate
On Thu, 18 Aug 2022 08:23:22 GMT, Julian Waters wrote:
>> Second attempt at resolving
>> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
>> intrusive approach this time
>>
>> Side note: While it might be preferred to remove this entirely, other areas
>> of the JDK also
On Thu, 18 Aug 2022 02:36:37 GMT, David Holmes wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Cleanup
>
> src/java.base/unix/native/libjli/java_md_common.c line 213:
>
>> 211: */
>> 212: char er
> Second attempt at resolving
> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
> intrusive approach this time
>
> Side note: While it might be preferred to remove this entirely, other areas
> of the JDK also use the same flawed logic, and removing this would simply
> p
On Thu, 18 Aug 2022 02:39:55 GMT, David Holmes wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Cleanup
>
> src/java.base/windows/native/libjli/java_md.c line 621:
>
>> 619: char *errtext = NULL;
>> 620:
>>
On Tue, 16 Aug 2022 10:23:31 GMT, Julian Waters wrote:
>> Second attempt at resolving
>> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
>> intrusive approach this time
>>
>> Side note: While it might be preferred to remove this entirely, other areas
>> of the JDK also
> Second attempt at resolving
> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
> intrusive approach this time
>
> Side note: While it might be preferred to remove this entirely, other areas
> of the JDK also use the same flawed logic, and removing this would simply
> p
> Second attempt at resolving
> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
> intrusive approach this time
>
> Side note: While it might be preferred to remove this entirely, other areas
> of the JDK also use the same flawed logic, and removing this would simply
> p
> Second attempt at resolving
> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
> intrusive approach this time
>
> Side note: While it might be preferred to remove this entirely, other areas
> of the JDK also use the same flawed logic, and removing this would simply
> p
> Second attempt at resolving
> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
> intrusive approach this time
>
> Side note: While it might be preferred to remove this entirely, other areas
> of the JDK also use the same flawed logic, and removing this would simply
> p
> Second attempt at resolving
> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
> intrusive approach this time
>
> Side note: While it might be preferred to remove this entirely, other areas
> of the JDK also use the same flawed logic, and removing this would simply
> p
> Second attempt at resolving
> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
> intrusive approach this time
>
> Side note: While it might be preferred to remove this entirely, other areas
> of the JDK also use the same flawed logic, and removing this would simply
> p
> Second attempt at resolving
> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
> intrusive approach this time
>
> Side note: While it might be preferred to remove this entirely, other areas
> of the JDK also use the same flawed logic, and removing this would simply
> p
> Second attempt at resolving
> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
> intrusive approach this time
>
> Side note: While it might be preferred to remove this entirely, other areas
> of the JDK also use the same flawed logic, and removing this would simply
> p
> Second attempt at resolving
> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
> intrusive approach this time
>
> Side note: While it might be preferred to remove this entirely, other areas
> of the JDK also use the same flawed logic, and removing this would simply
> p
Second attempt at resolving
[JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
intrusive approach this time (Clearing the error after the call, which is done
in other areas of the JDK as well)
Side note: While it might be preferred to remove this entirely, other areas of
th
On Mon, 8 Aug 2022 18:02:18 GMT, Julian Waters wrote:
>> JLI_ReportErrorMessageSys has a number of issues, as listed in the linked
>> issue, since it's not widely used, it's easier to remove it and replace the
>> areas it's called in with simpler calls to other error reporting functions:
>
> Ju
> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>
> - The windows variant prints message, then extra-info if available, but the
> Unix variant prints first extra-info, then message on a newline. Standardize
> both to print their system errors on newlines below the message.
>
On Mon, 8 Aug 2022 16:25:41 GMT, Julian Waters wrote:
>> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>>
>> - The windows variant prints message, then extra-info if available, but the
>> Unix variant prints first extra-info, then message on a newline. Standardize
>> both
> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>
> - The windows variant prints message, then extra-info if available, but the
> Unix variant prints first extra-info, then message on a newline. Standardize
> both to print their system errors on newlines below the message.
>
> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>
> - The windows variant prints message, then extra-info if available, but the
> Unix variant prints first extra-info, then message on a newline. Standardize
> both to print their system errors on newlines below the message.
>
On Mon, 8 Aug 2022 13:25:22 GMT, Julian Waters wrote:
>> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>>
>> - The windows variant prints message, then extra-info if available, but the
>> Unix variant prints first extra-info, then message on a newline. Standardize
>> both
On Mon, 8 Aug 2022 12:14:50 GMT, Julian Waters wrote:
>> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>>
>> - The windows variant prints message, then extra-info if available, but the
>> Unix variant prints first extra-info, then message on a newline. Standardize
>> both
> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>
> - The windows variant prints message, then extra-info if available, but the
> Unix variant prints first extra-info, then message on a newline. Standardize
> both to print their system errors on newlines below the message.
>
On Mon, 8 Aug 2022 09:06:39 GMT, David Holmes wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> I feel stupid
>
> src/java.base/unix/native/libjli/java_md_common.c line 209:
>
>> 207: /*
>> 208: * TODO: it
On Mon, 8 Aug 2022 12:14:50 GMT, Julian Waters wrote:
>> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>>
>> - The windows variant prints message, then extra-info if available, but the
>> Unix variant prints first extra-info, then message on a newline. Standardize
>> both
On Mon, 8 Aug 2022 09:06:39 GMT, David Holmes wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> I feel stupid
>
> src/java.base/unix/native/libjli/java_md_common.c line 209:
>
>> 207: /*
>> 208: * TODO: it
> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>
> - The windows variant prints message, then extra-info if available, but the
> Unix variant prints first extra-info, then message on a newline. Standardize
> both to print their system errors on newlines below the message.
>
On Mon, 8 Aug 2022 05:22:28 GMT, Julian Waters wrote:
>> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>>
>> - The windows variant prints message, then extra-info if available, but the
>> Unix variant prints first extra-info, then message on a newline. Standardize
>> both
> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>
> - The windows variant prints message, then extra-info if available, but the
> Unix variant prints first extra-info, then message on a newline. Standardize
> both to print their system errors on newlines below the message.
>
> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>
> - The windows variant prints message, then extra-info if available, but the
> Unix variant prints first extra-info, then message on a newline. Standardize
> both to print their system errors on newlines below the message.
>
> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>
> - The windows variant prints message, then extra-info if available, but the
> Unix variant prints first extra-info, then message on a newline. Standardize
> both to print their system errors on newlines below the message.
>
> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>
> - The windows variant prints message, then extra-info if available, but the
> Unix variant prints first extra-info, then message on a newline. Standardize
> both to print their system errors on newlines below the message.
>
> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>
> - The windows variant prints message, then extra-info if available, but the
> Unix variant prints first extra-info, then message on a newline. Standardize
> both to print their system errors on newlines below the message.
>
> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>
> - The windows variant prints message, then extra-info if available, but the
> Unix variant prints first extra-info, then message on a newline. Standardize
> both to print their system errors on newlines below the message.
>
JLI_ReportErrorMessageSys has a number of issues, as listed below:
- The windows variant prints message, then extra-info if available, but the
Unix variant prints first extra-info, then message on a newline. Standardize
both to print their system errors on newlines below the message.
- The Wind
49 matches
Mail list logo
