On Fri, 7 Feb 2025 20:05:49 GMT, Naoto Sato wrote:
>> This is a follow-on fix to
>> [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java
>> launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so
>> the same processing is needed. Also, obsolete code for Win
On Fri, 7 Feb 2025 18:39:25 GMT, Naoto Sato wrote:
>> src/java.base/share/native/libjli/args.c line 472:
>>
>>> 470: JLI_AddArgsFromEnvVar(JLI_List args, const char *var_name) {
>>> 471: #ifdef _WIN32
>>> 472: char *env = winGetEnv(var_name);
>>
>> I see that we are limiting this call to us
On Thu, 28 Nov 2024 01:09:47 GMT, Zheng Feng wrote:
> …String)
>
> This bug seems from the improper handling of package and class name
> initialization in `XSLTC` since there is a default value of `_packageName`
> with `die.verwandlung`. This fix is just adjusting to call `setPackageName`
>
On Fri, 7 Feb 2025 20:03:21 GMT, Joe Wang wrote:
> Fix an error handling where the XMLStreamReader impl throws EOFException
> instead of XMLStreamException as defined.
This pull request has now been integrated.
Changeset: 5395ffa0
Author:Joe Wang
URL:
https://git.openjdk.org/jdk/co
On Fri, 7 Feb 2025 20:03:21 GMT, Joe Wang wrote:
> Fix an error handling where the XMLStreamReader impl throws EOFException
> instead of XMLStreamException as defined.
RN added. Thanks all!
-
PR Comment: https://git.openjdk.org/jdk/pull/23524#issuecomment-267199
On Thu, 28 Nov 2024 01:09:47 GMT, Zheng Feng wrote:
> …String)
>
> This bug seems from the improper handling of package and class name
> initialization in `XSLTC` since there is a default value of `_packageName`
> with `die.verwandlung`. This fix is just adjusting to call `setPackageName`
>
On Thu, 28 Nov 2024 01:09:47 GMT, Zheng Feng wrote:
> …String)
>
> This bug seems from the improper handling of package and class name
> initialization in `XSLTC` since there is a default value of `_packageName`
> with `die.verwandlung`. This fix is just adjusting to call `setPackageName`
>
I would like to amplify this point — undermining Java’s integrity is a big
deal. Every time we use unsafe mechanisms within the JDK we risk doing that.
The more complex such code is the harder it is reason about whether overall it
is safe [*]. We need to balance reasoning about code, quality, an
Please review this change that adds the `jdk.static` VMProps. It can be used to
skip tests not for running on static JDK.
This also adds a new WhiteBox native method,
`jdk.test.whitebox.WhiteBox.isStatic()`, which is used by VMProps to determine
if it's static at runtime.
`@requires !jdk.stat
On Fri, 7 Feb 2025 20:11:06 GMT, Naoto Sato wrote:
>> src/java.base/share/native/libjli/args.c line 611:
>>
>>> 609: LPWSTR wcVarName = JLI_MemAlloc(wcCount * sizeof(wchar_t));
>>> 610: if (MultiByteToWideChar(CP_ACP, 0, var_name, -1, wcVarName,
>>> wcCount) != 0) {
>>> 611:
On Fri, 7 Feb 2025 20:05:49 GMT, Naoto Sato wrote:
>> This is a follow-on fix to
>> [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java
>> launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so
>> the same processing is needed. Also, obsolete code for Win
On Wed, 5 Feb 2025 20:11:36 GMT, Alexey Semenyuk wrote:
> Enable MSI installers to block installation if the version of Windows is too
> old.
>
> jpackage will read major and minor OS versions from PE headers of the main
> launcher and `java.dll` in the app image. The combined version is the m
On Fri, 7 Feb 2025 12:34:40 GMT, Coleen Phillimore wrote:
>> The Class.getModifiers() method is implemented as a native method in
>> java.lang.Class to access a field that we've calculated when creating the
>> mirror. The field is final after that point. The VM doesn't need it
>> anymore, so
On Tue, 5 Nov 2024 16:16:13 GMT, Christian Stein wrote:
> Please review this change that improves the launcher mode detection by
> reading the initial two characters from the started file for being a shebang
> script. It addresses the reported confusing error messages and also supports
> more
On Wed, 5 Feb 2025 20:11:36 GMT, Alexey Semenyuk wrote:
> Enable MSI installers to block installation if the version of Windows is too
> old.
>
> jpackage will read major and minor OS versions from PE headers of the main
> launcher and `java.dll` in the app image. The combined version is the m
On Fri, 7 Feb 2025 20:03:21 GMT, Joe Wang wrote:
> Fix an error handling where the XMLStreamReader impl throws EOFException
> instead of XMLStreamException as defined.
LGTM
-
Marked as reviewed by naoto (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/23524#pullrequestrevi
On Fri, 7 Feb 2025 19:58:12 GMT, Vladimir Ivanov wrote:
> Good point. Moreover, it seems most of intrinsics on Class queries can be
> replaced with a flag bit check on the mirror. (Do we have 16 unused bits in
> Class::modifiers after this change?)
Yes, I think so. isArray and isPrimitive def
On Fri, 7 Feb 2025 20:03:21 GMT, Joe Wang wrote:
> Fix an error handling where the XMLStreamReader impl throws EOFException
> instead of XMLStreamException as defined.
Looks OK Joe
I might suggest an RN to give a heads up on the change of Exception to match he
spec
-
Marked as r
On Fri, 7 Feb 2025 20:03:21 GMT, Joe Wang wrote:
> Fix an error handling where the XMLStreamReader impl throws EOFException
> instead of XMLStreamException as defined.
Marked as reviewed by iris (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/23524#pullrequestreview-2602
On Wed, 5 Feb 2025 20:11:36 GMT, Alexey Semenyuk wrote:
> Enable MSI installers to block installation if the version of Windows is too
> old.
>
> jpackage will read major and minor OS versions from PE headers of the main
> launcher and `java.dll` in the app image. The combined version is the m
> Update the specification of `java.io.File.exists()` to match its behavior,
> which seems correct in the context of how the empty abstract pathname is
> documented elsewhere in the class.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revi
On Fri, 7 Feb 2025 18:53:40 GMT, Justin Lu wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reflects review
>
> src/java.base/share/native/libjli/args.c line 603:
>
>> 601: /*
>> 602: * getenv() without best-fit map
On Fri, 7 Feb 2025 10:38:37 GMT, Alan Bateman wrote:
> Can you look at adding native init method instead? This could be called from
> the System.loadLibraray and avoid introduce a side effect of startThreads
> initialising GetCreatedJavaVMs.
Done, thanks. Moved `JNI_GetCreatedJavaVMs` lookup i
> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It
> removes libjvm.so as a recorded dependency for libExplicitAttach.so by not
> explicitly link libExplicitAttach.so with libjvm.so at build time. To do
> that, it also changes libExplicitAttach.c to dynamically lookup the
Fix an error handling where the XMLStreamReader impl throws EOFException
instead of XMLStreamException as defined.
-
Commit messages:
- 8327378: XMLStreamReader throws EOFException instead of XMLStreamException
Changes: https://git.openjdk.org/jdk/pull/23524/files
Webrev: https:/
> This is a follow-on fix to
> [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher
> can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same
> processing is needed. Also, obsolete code for Windows 9x has been removed.
Naoto Sato has updated the pul
On Thu, 6 Feb 2025 23:19:16 GMT, Alexander Matveev wrote:
> - Removed unused `INSTALLER_SUFFIX` bundler param.
> - Removed unreachable if branch in `MacAppImageBuilder`.
This pull request has now been integrated.
Changeset: f0ea38b3
Author:Alexander Matveev
URL:
https://git.openjdk.
On Fri, 7 Feb 2025 19:13:07 GMT, Coleen Phillimore wrote:
> I think the intrinsic for isInterface can be removed
Good point. Moreover, it seems most of intrinsics on Class queries can be
replaced with a flag bit check on the mirror. (Do we have 16 unused bits in
Class::modifiers after this cha
On Fri, 7 Feb 2025 12:34:40 GMT, Coleen Phillimore wrote:
>> The Class.getModifiers() method is implemented as a native method in
>> java.lang.Class to access a field that we've calculated when creating the
>> mirror. The field is final after that point. The VM doesn't need it
>> anymore, so
In CodeBuilder, validation for a slot was missing due to concurrent patches,
and the original patch did not add effective tests for CodeBuilder because of
the complex exceptional behaviors. Now the bug is fixed with renames to prevent
future risky usages, and the tests have been enhanced to ensu
On Fri, 7 Feb 2025 18:32:26 GMT, Naoto Sato wrote:
>> This is a follow-on fix to
>> [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java
>> launcher can take arguments from "JDK_JAVA_OPTIONS" environment variable, so
>> the same processing is needed. Also, obsolete code for Win
On Fri, 7 Feb 2025 12:34:40 GMT, Coleen Phillimore wrote:
>> The Class.getModifiers() method is implemented as a native method in
>> java.lang.Class to access a field that we've calculated when creating the
>> mirror. The field is final after that point. The VM doesn't need it
>> anymore, so
On Fri, 7 Feb 2025 14:42:44 GMT, Jaikiran Pai wrote:
> In (the Windows specific) `src/java.base/windows/native/libjli/cmdtoargs.c`
> there's an additional call to lookup (a different) `_JAVA_OPTIONS`
> environment variable through `getenv()` just to log out that environment
> variable's value.
On Fri, 7 Feb 2025 13:41:03 GMT, Jaikiran Pai wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reflects review
>
> src/java.base/share/native/libjli/args.c line 472:
>
>> 470: JLI_AddArgsFromEnvVar(JLI_List args, con
> This is a follow-on fix to
> [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher
> can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same
> processing is needed. Also, obsolete code for Windows 9x has been removed.
Naoto Sato has updated the pul
On Tue, 4 Feb 2025 14:26:23 GMT, Volkan Yazici wrote:
>> Adds `test.lib.Utils::createTempFileOfSize` to generate
>> `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory
>> contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file
>> tracked by git:
>>
>>
On Mon, 3 Feb 2025 21:43:56 GMT, Volodymyr Paprotski
wrote:
>> (Also see `8319429: Resetting MXCSR flags degrades ecore`)
>>
>> This PR fixes two issues:
>> - the original issue is a crash caused by `__ warn` corrupting the stack on
>> Windows only
>> - This issue also uncovered that -Xcheck:j
On Fri, 7 Feb 2025 17:08:06 GMT, Severin Gehwolf wrote:
>> test/jdk/tools/jpackage/share/JLinkOptionsTest.java line 145:
>>
>>> 143: public void testNoBindServicesByDefault() {
>>> 144: final var defaultModules =
>>> getModulesInRuntime("--limit-modules
>>> java.smartcardio,jdk.cry
On Fri, 7 Feb 2025 16:48:09 GMT, Severin Gehwolf wrote:
>> The change for JDK-8346434 added a new test case to
>> tools/jpackage/share/JLinkOptionsTest.java which does not respect the
>> constraint of the linkable runtime (JEP 493) that no jdk.jlink module can be
>> part of the target image.
>
On Wed, 5 Feb 2025 21:25:56 GMT, Justin Lu wrote:
> Please review this PR which removes _sun.util.locale.ParseStatus_ which is a
> Locale helper class used for parsing language tags.
>
> Such usages should be replaced by _java.text.ParsePosition_ which has almost
> 1 to 1 behavior. Note that
On Fri, 7 Feb 2025 13:13:24 GMT, Christoph Langer wrote:
> The change for JDK-8346434 added a new test case to
> tools/jpackage/share/JLinkOptionsTest.java which does not respect the
> constraint of the linkable runtime (JEP 493) that no jdk.jlink module can be
> part of the target image.
> Th
On Tue, Feb 4, 2025 at 5:26 PM Shaojin Wen wrote:
> I think you are talking about the problem of PR #23420, which is caused by
> the use of thread-unsafe StringBuilder in multi-threaded scenarios. This
> problem is very obscure and I didn't consider it before. I have started to
> solve this probl
On Mon, 13 Jan 2025 02:59:52 GMT, SendaoYan wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [e7e8f60c](https://github.com/openjdk/jdk/commit/e7e8f60c9bedd5622525cc4339300b438eedc9fd)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk24.
>
> Test tes
On Mon, 13 Jan 2025 02:59:52 GMT, SendaoYan wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [e7e8f60c](https://github.com/openjdk/jdk/commit/e7e8f60c9bedd5622525cc4339300b438eedc9fd)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk24.
>
> Test tes
Going forward, converting older JDK code to use the relatively new FFM API
requires system calls that can provide `errno` and the likes to explicitly
allocate a `MemorySegment` to capture potential error states. This can lead to
negative performance implications if not designed carefully and als
On Tue, 4 Feb 2025 14:26:23 GMT, Volkan Yazici wrote:
>> Adds `test.lib.Utils::createTempFileOfSize` to generate
>> `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory
>> contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file
>> tracked by git:
>>
>>
On Fri, 7 Feb 2025 13:13:24 GMT, Christoph Langer wrote:
> The change for JDK-8346434 added a new test case to
> tools/jpackage/share/JLinkOptionsTest.java which does not respect the
> constraint of the linkable runtime (JEP 493) that no jdk.jlink module can be
> part of the target image.
> Th
On Mon, 20 Jan 2025 11:43:13 GMT, Aviad Zer wrote:
>> This change extends the Math.min function to support multiple parameters,
>> improving its usability and code readability.
>>
>> Previously, finding the minimum value among multiple variables required
>> using nested Math.min calls or conve
On Thu, 6 Feb 2025 19:46:21 GMT, Naoto Sato wrote:
> This is a follow-on fix to
> [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher
> can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same
> processing is needed. Also, obsolete code for Windows
On Thu, 6 Feb 2025 19:46:21 GMT, Naoto Sato wrote:
> This is a follow-on fix to
> [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher
> can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same
> processing is needed. Also, obsolete code for Windows
On Thu, 6 Feb 2025 19:46:21 GMT, Naoto Sato wrote:
> This is a follow-on fix to
> [JDK-8337506](https://bugs.openjdk.org/browse/JDK-8337506). The Java launcher
> can take arguments from "JDK_JAVA_OPTIONS" environment variable, so the same
> processing is needed. Also, obsolete code for Windows
On Mon, 20 Jan 2025 12:51:47 GMT, Aviad Zer wrote:
>> Aviad Zer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update Math.java by adding extended max function
>
>> Before dealing with a CSR, I suggest you socialize your idea/PR in the
The change for JDK-8346434 added a new test case to
tools/jpackage/share/JLinkOptionsTest.java which does not respect the
constraint of the linkable runtime (JEP 493) that no jdk.jlink module can be
part of the target image.
This can be circumvented by limiting the modules.
-
Commi
> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in
> order to help improve vectorization performance.
>
> Currently vectorization does not kick in for loops containing either of these
> calls because of the following error:
>
>
> VLoop::check_preconditions: failed:
> The Class.getModifiers() method is implemented as a native method in
> java.lang.Class to access a field that we've calculated when creating the
> mirror. The field is final after that point. The VM doesn't need it anymore,
> so there's no real need for the jdk code to call into the VM to get
On Fri, 17 Jan 2025 17:53:24 GMT, Galder Zamarreño wrote:
>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in
>> order to help improve vectorization performance.
>>
>> Currently vectorization does not kick in for loops containing either of
>> these calls because of
On Thu, 6 Feb 2025 20:14:36 GMT, Jiangli Zhou wrote:
> This is similar to https://github.com/openjdk/jdk/pull/23431 change. It
> removes libjvm.so as a recorded dependency for libExplicitAttach.so by not
> explicitly link libExplicitAttach.so with libjvm.so at build time. To do
> that, it also
>Sorry, did the PR stop using Semaphore?
No, not that PR. See:
https://github.com/openjdk/jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e
The problem with interruption under parallel evaluation is that there is no
general support for propagation of interruption in CountedCompleters. Adding
On Thu, 28 Nov 2024 01:09:47 GMT, Zheng Feng wrote:
> …String)
>
> This bug seems from the improper handling of package and class name
> initialization in `XSLTC` since there is a default value of `_packageName`
> with `die.verwandlung`. This fix is just adjusting to call `setPackageName`
>
59 matches
Mail list logo
