On Tue, 6 Dec 2022 22:45:52 GMT, Naoto Sato wrote:
>> This is to allow Console to be used even when it is not attached to the
>> platform provided terminal, such as the case when the standard input is
>> redirected. `System.console()` now returns a Console implementation based on
>> `jdk.inter
On Tue, 6 Dec 2022 22:45:52 GMT, Naoto Sato wrote:
>> This is to allow Console to be used even when it is not attached to the
>> platform provided terminal, such as the case when the standard input is
>> redirected. `System.console()` now returns a Console implementation based on
>> `jdk.inter
On Tue, 6 Dec 2022 13:42:04 GMT, Daniel Jeliński wrote:
>> Please review this patch that removes progress monitoring classes used by
>> UrlConnection.
>> Since Java 9 these classes are not used in the JDK, and are not exported
>> from java.base. If anyone was still using them, reimplementing th
On Tue, 6 Dec 2022 10:16:38 GMT, Alan Bateman wrote:
> The implementation of Thread.yield for virtual threads is currently a "lazy
> submit". This means the task for the virtual thread is queued to the
> carrier/worker local queue without signalling other threads. This behavior
> can be surpri
On Tue, 6 Dec 2022 16:06:34 GMT, Doug Simon wrote:
>> Libgraal is compiled ahead of time and should not need any JVMCI Java code
>> to be dynamically loaded at runtime. Prior to this PR, this is not the case
>> due to:
>>
>> * Code to copy system properties from the HotSpot heap into the libgr
On Tue, 6 Dec 2022 08:56:47 GMT, Doug Simon wrote:
>> src/hotspot/share/jvmci/jvmci.cpp line 234:
>>
>>> 232: if (thread != nullptr && thread->is_Java_thread()) {
>>> 233: ResourceMark rm;
>>> 234: JavaThreadState state = ((JavaThread*) thread)->thread_state();
>>
>> Please use
On Wed, 30 Nov 2022 01:15:54 GMT, Brent Christian wrote:
>> [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the
>> shutdown sequence, noting that calling Runtime.halt() skips the shutdown
>> sequence and immediately terminates the VM. Thus, "threads' current methods
>> do
On Wed, 30 Nov 2022 18:07:07 GMT, Andrew John Hughes wrote:
> Update to the latest tzdata, 2022g.
>
> Primary changes:
> * `America/Ojinaga` (CST) is split, creating `America/Ciudad_Juarez` (MST/MDT)
> * `America/Pangnirtung` becomes a link to `America/Iqaluit`
> * `America/Ojinaga` gains DST (C
On Mon, 5 Dec 2022 14:38:51 GMT, Andrew John Hughes wrote:
>> Update to the latest tzdata, 2022g.
>>
>> Primary changes:
>> * `America/Ojinaga` (CST) is split, creating `America/Ciudad_Juarez`
>> (MST/MDT)
>> * `America/Pangnirtung` becomes a link to `America/Iqaluit`
>> * `America/Ojinaga` gai
> This is to allow Console to be used even when it is not attached to the
> platform provided terminal, such as the case when the standard input is
> redirected. `System.console()` now returns a Console implementation based on
> `jdk.internal.le` terminal by default, or jshell implementation if
On Wed, 30 Nov 2022 01:15:54 GMT, Brent Christian wrote:
>> [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the
>> shutdown sequence, noting that calling Runtime.halt() skips the shutdown
>> sequence and immediately terminates the VM. Thus, "threads' current methods
>> do
On Tue, 6 Dec 2022 18:39:28 GMT, Sergey Tsypanov wrote:
>> I found out that this code
>>
>> public class Main {
>> public static void main(String[] args) {
>> String s = "Hello world!";
>> char[] chars = s.toCharArray();
>> int point = Character.codePointAt(chars, -1,
On Tue, 6 Dec 2022 21:38:45 GMT, Daniel D. Daugherty wrote:
> A trivial fix to ProblemList 4 different tests:
> [JDK-8298214](https://bugs.openjdk.org/browse/JDK-8298214) ProblemList
> java/util/concurrent/forkjoin/AsyncShutdownNow.java
> [JDK-8298218](https://bugs.openjdk.org/browse/JDK-8298218
> This is to allow Console to be used even when it is not attached to the
> platform provided terminal, such as the case when the standard input is
> redirected. `System.console()` now returns a Console implementation based on
> `jdk.internal.le` terminal by default, or jshell implementation if
> JEP 429 implementation.
Andrew Haley has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 71 commits:
- Merge from JDK mainline
- Add comment
- Merge https://github.com/openjdk/jdk into JDK-828
- Feedback from reviewers
- Feedba
On Tue, 6 Dec 2022 16:07:44 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.1.1.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the requiredVersio
On Tue, 6 Dec 2022 15:20:26 GMT, Matthias Baesken wrote:
> We have a number of places in the codebase where a macro could help when we
> check an exception and afterwrads free something and return.
The existing (and new) macro naming doesn't make clear that it always returns
from the function
On Mon, 16 May 2022 21:21:28 GMT, Joe Wang wrote:
>> Update to Xerces 2.12.2.
>>
>> The update also fixes JDK-8144117. Added a test.
>>
>> Tests: local XML tests passed. Tier2 passed. Two JCK tests failed with this
>> update. See related issue report.
>
> Thanks Lance.
>
> Yes, I've notified
On Tue, 6 Dec 2022 16:25:12 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/lang/invoke/MemberName.java line 578:
>>
>>> 576: throw new LinkageError(m.toString());
>>> 577: }
>>> 578: assert(isResolved());
>>
>> I don't see why this can be removed. Can
On Tue, 6 Dec 2022 18:06:36 GMT, Claes Redestad wrote:
>> Various code cleanups around java.lang.invoke code. Started out with dead
>> code removal in `jli.MemberName`, then piled on to fix a set of minor
>> inefficiencies (excessive vararg array allocations, unnecessary defensive
>> cloning o
On Tue, 6 Dec 2022 19:17:44 GMT, Naoto Sato wrote:
>> This is to allow Console to be used even when it is not attached to the
>> platform provided terminal, such as the case when the standard input is
>> redirected. `System.console()` now returns a Console implementation based on
>> `jdk.inter
> This is to allow Console to be used even when it is not attached to the
> platform provided terminal, such as the case when the standard input is
> redirected. `System.console()` now returns a Console implementation based on
> `jdk.internal.le` terminal by default, or jshell implementation if
> I found out that this code
>
> public class Main {
> public static void main(String[] args) {
> String s = "Hello world!";
> char[] chars = s.toCharArray();
> int point = Character.codePointAt(chars, -1, 1);
> }
> }
>
> throws `ArrayIndexOutOfBoundsException` ins
On Tue, 6 Dec 2022 15:20:26 GMT, Matthias Baesken wrote:
> We have a number of places in the codebase where a macro could help when we
> check an exception and afterwrads free something and return.
I'm OK with the idea and the specific desktop change.
I'll leave the rest to the appropriate com
On Tue, 6 Dec 2022 07:34:45 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/io/Console.java line 616:
>>
>>> 614:
>>> JdkConsoleProvider.DEFAULT_PROVIDER_MODULE_NAME);
>>> 615: return
>>> ServiceLoader.load(JdkConsoleProvider.class).stream()
On Tue, 6 Dec 2022 06:19:37 GMT, Jaikiran Pai wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed the copyright year
>
> src/java.base/share/classes/java/io/Console.java line 99:
>
>> 97: */
>> 98:
>> 99: public
> This is to allow Console to be used even when it is not attached to the
> platform provided terminal, such as the case when the standard input is
> redirected. `System.console()` now returns a Console implementation based on
> `jdk.internal.le` terminal by default, or jshell implementation if
> Various code cleanups around java.lang.invoke code. Started out with dead
> code removal in `jli.MemberName`, then piled on to fix a set of minor
> inefficiencies (excessive vararg array allocations, unnecessary defensive
> cloning of parameter arrays etc).
Claes Redestad has updated the pull
On Tue, 6 Dec 2022 17:45:06 GMT, Christian Stein wrote:
>> Please review the change to update to using jtreg 7.1.1.
>>
>> The primary change is to the `jib-profiles.js` file, which specifies the
>> version of jtreg to use, for those systems that rely on this file. In
>> addition, the requiredV
> Please review the change to update to using jtreg 7.1.1.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the requiredVersion has been updated in the various `TEST.ROOT`
> files.
>
> Please review the change to update to using jtreg 7.1.1.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the requiredVersion has been updated in the various `TEST.ROOT`
> files.
>
> Usual start-of-release updates. Symbol updates in initial version reflect JDK
> 20 build 21.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Respond to review feedback; reformat test.
-
Changes:
- all: https://git.open
On Tue, 6 Dec 2022 16:07:44 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.1.1.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the requiredVersio
On Tue, 6 Dec 2022 17:05:16 GMT, Joe Darcy wrote:
>> Usual start-of-release updates. Symbol updates in initial version reflect
>> JDK 20 build 21.
>
> Joe Darcy has updated the pull request with a new target base due to a merge
> or a rebase. The pull request now contains 19 commits:
>
> - Me
On Tue, 6 Dec 2022 16:07:44 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.1.1.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the requiredVersio
> Usual start-of-release updates. Symbol updates in initial version reflect JDK
> 20 build 21.
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The pull request now contains 19 commits:
- Merge branch 'master' into JDK-8296149
- Merge branch 'master' i
On Tue, 15 Nov 2022 12:15:42 GMT, Hannes Wallnöfer wrote:
> Please review a simple change to hide internal classes in generated
> documentation by adding doc comments containing a `@hidden` tag. I verified
> the fix by making sure `grep -r jdk.internal` returns no matches in the
> generated do
On Tue, 6 Dec 2022 15:41:20 GMT, Doug Simon wrote:
>> src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 66:
>>
>>> 64: * only contains String keys and values.
>>> 65: */
>>> 66: private static byte[] serializePropertiesToByteArray(Properties p,
>>> bool
On Mon, 5 Dec 2022 14:38:51 GMT, Andrew John Hughes wrote:
>> Update to the latest tzdata, 2022g.
>>
>> Primary changes:
>> * `America/Ojinaga` (CST) is split, creating `America/Ciudad_Juarez`
>> (MST/MDT)
>> * `America/Pangnirtung` becomes a link to `America/Iqaluit`
>> * `America/Ojinaga` gai
On Tue, 6 Dec 2022 15:28:24 GMT, Sergey Tsypanov wrote:
>> I found out that this code
>>
>> public class Main {
>> public static void main(String[] args) {
>> String s = "Hello world!";
>> char[] chars = s.toCharArray();
>> int point = Character.codePointAt(chars, -1,
On Mon, 5 Dec 2022 21:38:20 GMT, Oliver Kopp wrote:
>> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567):
>> "MethodTooLargeException thrown while creating a jlink image".
>>
>> Java still has a 64kb limit: A method may not be longer than 64kb. The idea
>> of the fix is to spl
> Various code cleanups around java.lang.invoke code. Started out with dead
> code removal in `jli.MemberName`, then piled on to fix a set of minor
> inefficiencies (excessive vararg array allocations, unnecessary defensive
> cloning of parameter arrays etc).
Claes Redestad has updated the pull
On Tue, 6 Dec 2022 16:13:12 GMT, Jorn Vernee wrote:
>> Various code cleanups around java.lang.invoke code. Started out with dead
>> code removal in `jli.MemberName`, then piled on to fix a set of minor
>> inefficiencies (excessive vararg array allocations, unnecessary defensive
>> cloning of p
On Mon, 5 Dec 2022 19:42:44 GMT, Brian Burkhalter wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixed bug number
>
> test/jdk/java/io/SequenceInputStream/TransferTo.java line 206:
>
>> 204: }
>> 205:
>> 206:
On Tue, 6 Dec 2022 15:22:27 GMT, Claes Redestad wrote:
> Various code cleanups around java.lang.invoke code. Started out with dead
> code removal in `jli.MemberName`, then piled on to fix a set of minor
> inefficiencies (excessive vararg array allocations, unnecessary defensive
> cloning of pa
On Tue, 6 Dec 2022 16:07:44 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.1.1.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the requiredVersio
Please review the change to update to using jtreg 7.1.1.
The primary change is to the `jib-profiles.js` file, which specifies the
version of jtreg to use, for those systems that rely on this file. In addition,
the requiredVersion has been updated in the various `TEST.ROOT` files.
This pull requ
> Libgraal is compiled ahead of time and should not need any JVMCI Java code to
> be dynamically loaded at runtime. Prior to this PR, this is not the case due
> to:
>
> * Code to copy system properties from the HotSpot heap into the libgraal
> heap. This is in
> `jdk.vm.ci.services.Services.in
> The accessFlags() methods added (in JDK 20, the current release) to
> java.lang.Class, java.lang.reflect.Executable, and java.lang.reflect.Field
> implicitly uses the access flags from the current/most recent class file
> format version. For current and past class file format versions there ar
On Mon, 5 Dec 2022 12:31:15 GMT, Andrew Haley wrote:
>> JEP 429 implementation.
>
> Andrew Haley has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add comment
Marked as reviewed by mcimadamore (Reviewer).
-
PR: https://git.open
On Tue, 6 Dec 2022 13:02:40 GMT, Alan Bateman wrote:
>> Doug Simon has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - incorporate review feedback [skip ci]
>> - removed hard-coded module name [skip ci]
>
> src/java.base/share/classes/jdk
On Tue, 6 Dec 2022 13:42:04 GMT, Daniel Jeliński wrote:
>> Please review this patch that removes progress monitoring classes used by
>> UrlConnection.
>> Since Java 9 these classes are not used in the JDK, and are not exported
>> from java.base. If anyone was still using them, reimplementing th
Various code cleanups around java.lang.invoke code. Started out with dead code
removal in `jli.MemberName`, then piled on to fix a set of minor inefficiencies
(excessive vararg array allocations, unnecessary defensive cloning of parameter
arrays etc).
-
Commit messages:
- Restore
We have a number of places in the codebase where a macro could help when we
check an exception and afterwrads free something and return.
-
Commit messages:
- JDK-8298170
Changes: https://git.openjdk.org/jdk/pull/11539/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11539&r
> I found out that this code
>
> public class Main {
> public static void main(String[] args) {
> String s = "Hello world!";
> char[] chars = s.toCharArray();
> int point = Character.codePointAt(chars, -1, 1);
> }
> }
>
> throws `ArrayIndexOutOfBoundsException` ins
On Mon, 5 Dec 2022 12:31:15 GMT, Andrew Haley wrote:
>> JEP 429 implementation.
>
> Andrew Haley has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add comment
Marked as reviewed by alanb (Reviewer).
-
PR: https://git.openjdk.or
> JEP 436 proposes a second preview of Virtual Threads to allow time for more
> feedback and to get more experience with this feature. There is no change in
> direction, no API changes, and no bulk update of the implementation. For the
> implementation, there has been ~35 changes/issues pushed t
The implementation of Thread.yield for virtual threads is currently a "lazy
submit". This means the task for the virtual thread is queued to the
carrier/worker local queue without signalling other threads. This behavior can
be surprising/unfair when there are tasks in the submission queues, say
On Mon, 26 Sep 2022 18:15:17 GMT, Dmitry Samersoff
wrote:
> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options
> from the JDK_JAVA_OPTIONS environment variable are picked up twice.
>
> If an option cannot be accepted twice (e.g., -agentlib), the application
> fails to
On Mon, 26 Sep 2022 18:15:17 GMT, Dmitry Samersoff
wrote:
> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options
> from the JDK_JAVA_OPTIONS environment variable are picked up twice.
>
> If an option cannot be accepted twice (e.g., -agentlib), the application
> fails to
On Tue, 6 Dec 2022 13:42:04 GMT, Daniel Jeliński wrote:
>> Please review this patch that removes progress monitoring classes used by
>> UrlConnection.
>> Since Java 9 these classes are not used in the JDK, and are not exported
>> from java.base. If anyone was still using them, reimplementing th
On Tue, 6 Dec 2022 12:43:44 GMT, Daniel Fuchs wrote:
>> test/jdk/sun/net/www/http/KeepAliveStream/KeepAliveStreamFinalizer.java line
>> 175:
>>
>>> 173: public InputStream getInputStream() throws IOException {
>>> 174: if (finalized) {
>>> 175: System.out.pri
> Please review this patch that removes progress monitoring classes used by
> UrlConnection.
> Since Java 9 these classes are not used in the JDK, and are not exported from
> java.base. If anyone was still using them, reimplementing them in user code
> should be pretty straightforward.
>
> This
On Tue, 6 Dec 2022 12:38:42 GMT, Daniel Fuchs wrote:
>> test/jdk/sun/net/www/http/KeepAliveStream/KeepAliveStreamFinalizer.java line
>> 28:
>>
>>> 26: * @bug 8240275
>>> 27: * @library /test/lib
>>> 28: * @run main/othervm KeepAliveStreamFinalizer
>>
>> Hello Daniel, it doesn't look like we
On Tue, 6 Dec 2022 09:47:29 GMT, Doug Simon wrote:
>> Libgraal is compiled ahead of time and should not need any JVMCI Java code
>> to be dynamically loaded at runtime. Prior to this PR, this is not the case
>> due to:
>>
>> * Code to copy system properties from the HotSpot heap into the libgr
On Tue, 6 Dec 2022 12:05:26 GMT, Jaikiran Pai wrote:
>> Daniel Jeliński has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add test
>
> test/jdk/sun/net/www/http/KeepAliveStream/KeepAliveStreamFinalizer.java line
> 175:
>
>> 173:
On Mon, 5 Dec 2022 14:12:05 GMT, Daniel Jeliński wrote:
>> Please review this patch that removes progress monitoring classes used by
>> UrlConnection.
>> Since Java 9 these classes are not used in the JDK, and are not exported
>> from java.base. If anyone was still using them, reimplementing th
On Tue, 6 Dec 2022 12:07:35 GMT, Jaikiran Pai wrote:
>> Daniel Jeliński has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add test
>
> test/jdk/sun/net/www/http/KeepAliveStream/KeepAliveStreamFinalizer.java line
> 28:
>
>> 26: * @bug 82
On Mon, 5 Dec 2022 14:06:10 GMT, Daniel Jeliński wrote:
>> Please review this patch that removes progress monitoring classes used by
>> UrlConnection.
>> Since Java 9 these classes are not used in the JDK, and are not exported
>> from java.base. If anyone was still using them, reimplementing th
On Tue, 6 Dec 2022 07:35:44 GMT, Jaikiran Pai wrote:
> So the `Console` instance returned from `System.console()`, thus far, follows
> these semantics. However, with the change proposed in this PR, the default
> implementation will now be the jline backed `JdkConsoleImpl` implementation.
> Fro
On Mon, 21 Nov 2022 10:53:07 GMT, Per Minborg wrote:
> This PR proposes the introduction of **guarding** of the use of
> `DirectBuffer::address` within the JDK. With the introduction of the Foreign
> Function and Memory access, it is possible to derive Buffer instances that
> are backed by nat
> This PR proposes the introduction of **guarding** of the use of
> `DirectBuffer::address` within the JDK. With the introduction of the Foreign
> Function and Memory access, it is possible to derive Buffer instances that
> are backed by native memory that, in turn, can be closed asynchronously
> Libgraal is compiled ahead of time and should not need any JVMCI Java code to
> be dynamically loaded at runtime. Prior to this PR, this is not the case due
> to:
>
> * Code to copy system properties from the HotSpot heap into the libgraal
> heap. This is in
> `jdk.vm.ci.services.Services.in
On Tue, 6 Dec 2022 05:28:24 GMT, David Holmes wrote:
>> Doug Simon has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> renamed is_module_resolvable to is_module_observable
>
> src/hotspot/share/jvmci/jvmci.cpp line 234:
>
>> 232: if (th
74 matches
Mail list logo
