On Thu, 7 Mar 2024 07:20:15 GMT, David Holmes wrote:
> Oracle requests/requires that the Oracle copyright always be updated when a
> file is modified.
Got it. Thanks for your explanation.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/18132#discussion_r1515672685
On Thu, 7 Mar 2024 03:00:11 GMT, Guoxiong Li wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Introduce windows jni_util_md.h
>
> src/java.base/aix/native/libnio/ch/Pollset.c line 3:
>
>> 1: /*
>> 2: *
On Wed, 6 Mar 2024 23:36:09 GMT, Ioi Lam wrote:
>> A few clean ups:
>>
>> 1. Rename functions like "`s_loading_full_module_graph()` to
>> `is_using_full_module_graph()`. The meaning of "loading" is not clear: it
>> might be interpreted as to cover only the period where the artifact is being
On Thu, 7 Mar 2024 05:33:16 GMT, Korov wrote:
>> When the specified key did not associated with a value, should check the
>> `key` and `value` type.
>
> Korov has updated the pull request incrementally with one additional commit
> since the last revision:
>
> Use testNG builtin
On Thu, 7 Mar 2024 04:37:24 GMT, Chen Liang wrote:
>> Korov has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> modify the code based on the review
>
> test/jdk/java/util/Collections/CheckedMapBash.java line 193:
>
>> 191:
> When the specified key did not associated with a value, should check the
> `key` and `value` type.
Korov has updated the pull request incrementally with one additional commit
since the last revision:
Use testNG builtin functionalities and modify the test function name
-
On Thu, 7 Mar 2024 04:13:17 GMT, Korov wrote:
>> When the specified key did not associated with a value, should check the
>> `key` and `value` type.
>
> Korov has updated the pull request incrementally with one additional commit
> since the last revision:
>
> modify the code based on the
On Thu, 7 Mar 2024 03:44:55 GMT, Guoxiong Li wrote:
> Good caught. A trivial suggestion.
Thanks for your suggestion, the code has been modified.
-
PR Comment: https://git.openjdk.org/jdk/pull/18141#issuecomment-1982318659
> When the specified key did not associated with a value, should check the
> `key` and `value` type.
Korov has updated the pull request incrementally with one additional commit
since the last revision:
modify the code based on the review
-
Changes:
- all:
On Wed, 6 Mar 2024 18:26:16 GMT, Korov wrote:
> When the specified key did not associated with a value, should check the
> `key` and `value` type.
Good caught. A trivial suggestion.
test/jdk/java/util/Collections/CheckedMapBash.java line 192:
> 190: Map m =
On Wed, 6 Mar 2024 09:26:08 GMT, Aleksey Shipilev wrote:
> ```
> Process p = ProcessTools.startProcess(...);
> OutputAnalyzer oa = new OutputAnalyzer(p);
> oa.shouldNotHaveExitValue(0);
> oa.shouldContain("This command is not for general use");
> ```
Thank you! This shortens things quite
On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken wrote:
>> We define the RESTARTABLE macro again and again at a lot of places in the
>> JDK native codebase. This could be centralized to avoid repeating it again
>> and again !
>
> Matthias Baesken has updated the pull request incrementally
On Wed, 6 Mar 2024 21:32:11 GMT, Naoto Sato wrote:
> Fixing timeout failures in the test case. Time zone names that are missing
> (chiefly for minor locales) are now calculated at runtime after the fix to
> JDK-8174269. This extra calculation time was multiplied in the test case as
> it
On Wed, 6 Mar 2024 21:32:11 GMT, Naoto Sato wrote:
> Fixing timeout failures in the test case. Time zone names that are missing
> (chiefly for minor locales) are now calculated at runtime after the fix to
> JDK-8174269. This extra calculation time was multiplied in the test case as
> it
On Wed, 6 Mar 2024 22:58:54 GMT, Viktor Klang wrote:
> The common ForkJoinPool creating threads as a result of submitting tasks is
> preventing class unloading when the thread construction is initiated from a
> class loaded in a separate classloader. This fix avoids that when no
>
> A few clean ups:
>
> 1. Rename functions like "`s_loading_full_module_graph()` to
> `is_using_full_module_graph()`. The meaning of "loading" is not clear: it
> might be interpreted as to cover only the period where the artifact is being
> loaded, but not the period after the artifact is
Hi Simeon,
Thanks for your email.
After discussing this with Doug Lea and Alan Bateman I've opened the following
PR: https://github.com/openjdk/jdk/pull/18144
On Wed, 6 Mar 2024 22:58:54 GMT, Viktor Klang wrote:
> The common ForkJoinPool creating threads as a result of submitting tasks is
> preventing class unloading when the thread construction is initiated from a
> class loaded in a separate classloader. This fix avoids that when no
>
On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken wrote:
>> We define the RESTARTABLE macro again and again at a lot of places in the
>> JDK native codebase. This could be centralized to avoid repeating it again
>> and again !
>
> Matthias Baesken has updated the pull request incrementally
On Wed, 6 Mar 2024 21:32:11 GMT, Naoto Sato wrote:
> Fixing timeout failures in the test case. Time zone names that are missing
> (chiefly for minor locales) are now calculated at runtime after the fix to
> JDK-8174269. This extra calculation time was multiplied in the test case as
> it
On Wed, 6 Mar 2024 21:32:11 GMT, Naoto Sato wrote:
> Fixing timeout failures in the test case. Time zone names that are missing
> (chiefly for minor locales) are now calculated at runtime after the fix to
> JDK-8174269. This extra calculation time was multiplied in the test case as
> it
creating threads in the common ForkJoinPool preventing class unloading. This
fix avoids that when no SecurityManager is configured.
-
Commit messages:
- Addresses a capture of AccessControlContext when
Changes: https://git.openjdk.org/jdk/pull/18144/files
Webrev:
On Wed, 6 Mar 2024 18:42:01 GMT, Matias Saavedra Silva
wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixed alignments
>
> src/hotspot/share/cds/cdsConfig.hpp line 72:
>
>> 70: static void
> A few clean ups:
>
> 1. Rename functions like "`s_loading_full_module_graph()` to
> `is_using_full_module_graph()`. The meaning of "loading" is not clear: it
> might be interpreted as to cover only the period where the artifact is being
> loaded, but not the period after the artifact is
On Wed, 21 Feb 2024 19:10:16 GMT, Calvin Cheung wrote:
> To avoid the CDS dump error message, a fix is during dumping a classlist,
> check if an invoker can be archived.
> If not, don't write the invoker info into the classlist, i.e. don't call
> `logLambdaFormInvoker()`. While generating
Fixing timeout failures in the test case. Time zone names that are missing
(chiefly for minor locales) are now calculated at runtime after the fix to
JDK-8174269. This extra calculation time was multiplied in the test case as it
iterated over all locales x timezones, which caused timeouts in
On Tue, 5 Mar 2024 18:54:55 GMT, Alan Bateman wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Apply suggestions from code review
>>
>> Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com>
>>
> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
> automatically granted the native access. I am working on an upgrade of JLine
> inside the `jdk.internal.le` module, and I would like to replace the current
> native bindings with FFM-based bindings (which are now
> The atan2 and hypot cases added would fail for a particular test library that
> has errors in the millions of ulps for those inputs, rather than the small
> number of ulps specified for the error.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last
On Tue, 27 Feb 2024 17:24:03 GMT, Chad Rakoczy wrote:
> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
> with Formatter.format taking a long time when there is a lot of padding. This
> test runs Formatter.format with very large padding. Test fails before
>
On Wed, 6 Mar 2024 17:28:01 GMT, Magnus Ihse Bursie wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Only show runtime image suffix for JDK modules
>
> make/ToolsJdk.gmk line 88:
>
>> 86:
On Wed, 6 Mar 2024 19:00:19 GMT, Alan Bateman wrote:
>> Native access is needed for modules which calls restricted methods [1].
>> AFAICT, java.base, java.desktop and jdk.incubator.vector use
>> java.lang.foreign but I don't know if they call restricted methods or not.
>>
>>
On Wed, 6 Mar 2024 18:00:25 GMT, Mandy Chung wrote:
> Native access is needed for modules which calls restricted methods [1].
In time, we'll need it for modules using JNI too. We can do this trimming in
another PR to avoid Jan getting pulled into deeply.
-
PR Review Comment:
On Sat, 2 Mar 2024 01:18:06 GMT, Ioi Lam wrote:
> A few clean ups:
>
> 1. Rename functions like "`s_loading_full_module_graph()` to
> `is_using_full_module_graph()`. The meaning of "loading" is not clear: it
> might be interpreted as to cover only the period where the artifact is being
>
On Wed, 6 Mar 2024 14:14:56 GMT, Jaikiran Pai wrote:
>> Archie Cobbs has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains six additional
>> commits
When the specified key did not associated with a value, should check the `key`
and `value` type.
-
Commit messages:
- 8292955: Collections.checkedMap Map.merge does not properly check key and
value
- 8292955: Collections.checkedMap Map.merge does not properly check key and
value
On Wed, 6 Mar 2024 15:02:07 GMT, Jan Lahoda wrote:
>>> Many of these modules do not need native access in the current
>>> implementation.
>>
>> In addition this will eventually need jlink support. I view the change to
>> ModuleBootstrap initialiser to use ModuleLoaderMap.nativeAccessModules()
The atan2 and hypot cases added would fail for a particular test library that
has errors in the millions of ulps for those inputs, rather than the small
number of ulps specified for the error.
-
Commit messages:
- JDK-8327487: Further augment WorstCaseTests with more cases
On Tue, 27 Feb 2024 15:23:09 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>>
On Wed, Mar 6, 2024 at 5:41 PM Alan Bateman wrote:
This discussion is about the JDK's internal Unsafe, not sun.misc.Unsafe.
>
Thanks Alan, I guess I should have made this more clear from the beginning.
I'll await a response from the wise men on Mandy's JDK-8207146 comment
before proposing a
On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken wrote:
>> We define the RESTARTABLE macro again and again at a lot of places in the
>> JDK native codebase. This could be centralized to avoid repeating it again
>> and again !
>
> Matthias Baesken has updated the pull request incrementally
On Tue, 5 Mar 2024 12:44:10 GMT, Jan Lahoda wrote:
>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are
>> automatically granted the native access. I am working on an upgrade of JLine
>> inside the `jdk.internal.le` module, and I would like to replace the current
>>
On Wed, 6 Mar 2024 00:56:16 GMT, Jaikiran Pai wrote:
>> I believe we could technically reuse the list for boot/platform modules.
>> But, the intent here is to provide more control over the modules with native
>> access, not only being able to add to the list, but also remove from the
>> list.
> We define the RESTARTABLE macro again and again at a lot of places in the JDK
> native codebase. This could be centralized to avoid repeating it again and
> again !
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
Introduce
On Wed, 6 Mar 2024 15:31:40 GMT, Chen Liang wrote:
> Looking at 8326836 #18030, we might need `@since` tags on the new API methods.
Thanks for pointing it out, I've added them.
-
PR Comment: https://git.openjdk.org/jdk/pull/17282#issuecomment-1981230434
On Tue, 5 Mar 2024 00:51:33 GMT, Naoto Sato wrote:
> Fixing test cases. For bad test cases, only the first case was run, and the
> rest were ignored.
This pull request has now been integrated.
Changeset: 9f709407
Author:Naoto Sato
URL:
On Tue, 5 Mar 2024 17:26:11 GMT, Naoto Sato wrote:
>> Fixing test cases. For bad test cases, only the first case was run, and the
>> rest were ignored.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Reflects review
> `java.lang.classfile.CodeBuilder` contains more than 230 API methods.
> Existing ClassFile API use cases proved the concept one big CodeBuilder is
> comfortable. However there are some redundancies, glitches in the naming
> conventions, some frequently used methods are hard to find and some
On Wed, 6 Mar 2024 15:49:05 GMT, Alan Bateman wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> introduce unix jni_util_md.h
>
> src/java.base/aix/native/libnio/ch/Pollset.c line 29:
>
>> 27: #include "jni.h"
On Tue, 5 Mar 2024 23:00:16 GMT, Chad Rakoczy wrote:
>> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
>> with Formatter.format taking a long time when there is a lot of padding.
>> This test runs Formatter.format with very large padding. Test fails before
>>
On Wed, 6 Mar 2024 15:45:16 GMT, Matthias Baesken wrote:
>> We define the RESTARTABLE macro again and again at a lot of places in the
>> JDK native codebase. This could be centralized to avoid repeating it again
>> and again !
>
> Matthias Baesken has updated the pull request incrementally
> We define the RESTARTABLE macro again and again at a lot of places in the JDK
> native codebase. This could be centralized to avoid repeating it again and
> again !
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
introduce
On Wed, 6 Mar 2024 15:00:09 GMT, Adam Sotona wrote:
>> `java.lang.classfile.CodeBuilder` contains more than 230 API methods.
>> Existing ClassFile API use cases proved the concept one big CodeBuilder is
>> comfortable. However there are some redundancies, glitches in the naming
>> conventions,
On Wed, 6 Mar 2024 09:19:44 GMT, Alan Bateman wrote:
>> Many of these modules do not need native access in the current
>> implementation. Should this list be trimmed to list the ones that need
>> native access in the current implementation?
>
>> Many of these modules do not need native
> `java.lang.classfile.CodeBuilder` contains more than 230 API methods.
> Existing ClassFile API use cases proved the concept one big CodeBuilder is
> comfortable. However there are some redundancies, glitches in the naming
> conventions, some frequently used methods are hard to find and some
On Tue, 5 Mar 2024 13:58:50 GMT, Jaikiran Pai wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Apply suggestions from code review
>>
>> Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com>
>>
On Fri, 1 Mar 2024 10:44:14 GMT, Christoph Langer wrote:
>> During analysing a customer case I figured out that we have an inconsistency
>> between documentation and actual behavior in class
>> com.sun.jndi.ldap.Connection. The [method documentation of
>>
On Wed, 6 Mar 2024 14:25:09 GMT, Matthias Baesken wrote:
> We could maybe also use the existing
> https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/include/jni_md.h
> - what do you think ?
jni_md.h goes into the JDK run-time image (for jni.h to include) so I don't
think we
Hi Wen,
I think this change is for jdk.internal's Unsafe (JDK 9+) instead of for
sun.misc's Unsafe. The sun.misc.Unsafe's methods have stayed "getObject"
https://github.com/openjdk/jdk/blob/ae5e3fdd5922a232c9b48fc846c4fcdc8f2b2645/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java#L197
instead
On Wed, 6 Mar 2024 14:13:26 GMT, Alan Bateman wrote:
>> We define the RESTARTABLE macro again and again at a lot of places in the
>> JDK native codebase. This could be centralized to avoid repeating it again
>> and again !
>
> src/java.base/share/native/libjava/jni_util.h line 243:
>
>> 241:
On Mon, 5 Feb 2024 23:53:06 GMT, Archie Cobbs wrote:
>> `GZIPInputStream`, when looking for a concatenated stream, relies on what
>> the underlying `InputStream` says is how many bytes are `available()`. But
>> this is inappropriate because `InputStream.available()` is just an estimate
>> and
On Wed, 6 Mar 2024 09:26:25 GMT, Matthias Baesken wrote:
> We define the RESTARTABLE macro again and again at a lot of places in the JDK
> native codebase. This could be centralized to avoid repeating it again and
> again !
src/java.base/share/native/libjava/jni_util.h line 243:
> 241: }
On 06/03/2024 10:56, wenshao wrote:
Many libraries use Unsafe to improve performance, especially in many
performance-critical scenarios of big data, such as Apache
Flink/Apache Arrow, etc. Direct removal will make it difficult to
adopt the new version of JDK.
It is recommended to use it
On Wed, 6 Mar 2024 13:43:00 GMT, Magnus Ihse Bursie wrote:
>> Currently, our symbol visibility handling for tests are sloppy; we only
>> handle it properly on Windows. We need to bring it up to the same levels as
>> product code. This is a prerequisite for
>>
On Wed, 6 Mar 2024 13:43:00 GMT, Magnus Ihse Bursie wrote:
>> Currently, our symbol visibility handling for tests are sloppy; we only
>> handle it properly on Windows. We need to bring it up to the same levels as
>> product code. This is a prerequisite for
>>
> Currently, our symbol visibility handling for tests are sloppy; we only
> handle it properly on Windows. We need to bring it up to the same levels as
> product code. This is a prerequisite for
> [JDK-8327045](https://bugs.openjdk.org/browse/JDK-8327045), which in turn is
> a building block
On Wed, 6 Mar 2024 11:33:30 GMT, Magnus Ihse Bursie wrote:
> Currently, our symbol visibility handling for tests are sloppy; we only
> handle it properly on Windows. We need to bring it up to the same levels as
> product code. This is a prerequisite for
>
Currently, our symbol visibility handling for tests are sloppy; we only handle
it properly on Windows. We need to bring it up to the same levels as product
code. This is a prerequisite for
[JDK-8327045](https://bugs.openjdk.org/browse/JDK-8327045), which in turn is a
building block for
On Tue, 6 Feb 2024 12:52:15 GMT, Jim Laskey wrote:
> Currently, add is returning intern(e) == null which will always be false. The
> correct test is intern(e) == e , that is, true when element is newly added.
This pull request has now been integrated.
Changeset: a7461de2
Author:Jim Laskey
On Wed, 6 Mar 2024 09:26:25 GMT, Matthias Baesken wrote:
> We define the RESTARTABLE macro again and again at a lot of places in the JDK
> native codebase. This could be centralized to avoid repeating it again and
> again !
Looks good. Nice refactor.
-
Marked as reviewed by gli
Many libraries use Unsafe to improve performance, especially in many
performance-critical scenarios of big data, such as Apache Flink/Apache Arrow,
etc. Direct removal will make it difficult to adopt the new version of JDK.
It is recommended to use it similar to JEP 396, which needs to be
We define the RESTARTABLE macro again and again at a lot of places in the JDK
native codebase. This could be centralized to avoid repeating it again and
again !
-
Commit messages:
- JDK-8327444
Changes: https://git.openjdk.org/jdk/pull/18132/files
Webrev:
On Tue, 5 Mar 2024 20:34:47 GMT, Vladimir Petko wrote:
> > The change in jspawnhelper looks good.
> > I think it would be simpler to have a separate
> > `jdk/java/lang/ProcessBuilder/JspawnhelperMisuse.java` test that simply
> > invokes the `jspawnhelper` and verifies the proper message is
On Tue, 5 Mar 2024 22:44:20 GMT, Mandy Chung wrote:
> Many of these modules do not need native access in the current implementation.
In addition this will eventually need jlink support. I view the change to
ModuleBootstrap initialiser to use ModuleLoaderMap.nativeAccessModules() as
very
On 05/03/2024 22:57, mandy.ch...@oracle.com wrote:
These deprecated methods were added to make jsr166.jar to run on
different JDK releases. I think it's time to remove these deprecated
xxxObject* methods as the renames have been done since JDK 12 for 5
years.
Yes, I think they can be
75 matches
Mail list logo
