The 19 release candidate appears to have new issues on this?
java --version
openjdk 19 2022-09-20
OpenJDK Runtime Environment (build 19+36-2238)
OpenJDK 64-Bit Server VM (build 19+36-2238, mixed mode, sharing)
which jpackage
jpackage: aliased to
On Mon, 5 Sep 2022 18:05:04 GMT, Markus KARG wrote:
>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional
> commit since the last revision:
>
> HexPrinter::transferTo
test/lib/jdk/test/lib/hexdump/HexPrinter.java line 1194:
> 1192:
> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel
> execution of (long-running or infinite loops) user code in JShell, however
> Thread::stop is deprecated and planned for removal.
>
> Proposed patch instruments all user code to call
> LocalExecutionControl::stopCheck
On Mon, 5 Sep 2022 18:05:04 GMT, Markus KARG wrote:
>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional
> commit since the last revision:
>
> HexPrinter::transferTo
It looks like this patch is against a repository that hasn't been
On Mon, 5 Sep 2022 15:53:32 GMT, Adam Sotona wrote:
>> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel
>> execution of (long-running or infinite loops) user code in JShell, however
>> Thread::stop is deprecated and planned for removal.
>>
>> Proposed patch instruments
> Implementation of JDK-8279283
Markus KARG has updated the pull request incrementally with one additional
commit since the last revision:
HexPrinter::transferTo
-
Changes:
- all: https://git.openjdk.org/jdk/pull/6935/files
- new:
On Wed, 12 Jan 2022 13:24:12 GMT, Daniel Fuchs wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixed missing BufferedInputStream
>
> src/java.base/share/classes/java/io/BufferedInputStream.java line 501:
>
>> 499:
On Thu, 7 Jul 2022 07:34:32 GMT, Сергей Цыпанов wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixed missing BufferedInputStream
>
> src/java.base/share/classes/java/io/BufferedInputStream.java line 495:
>
>>
> Implementation of JDK-8279283
Markus KARG has updated the pull request incrementally with one additional
commit since the last revision:
using getBufIfOpen() instead of direct buf access
-
Changes:
- all: https://git.openjdk.org/jdk/pull/6935/files
- new:
This PR introduces a system property that creates stable names for the lambda
classes in the JDK. Instead of using an atomic counter in the lambda name, we
can use a 32-bit hash after `$$Lambda$`. Thus, the name becomes
`lambdaCapturingClass$$Lambda$hashValue`.
Parameters used to create a
On Mon, 5 Sep 2022 15:53:32 GMT, Adam Sotona wrote:
>> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel
>> execution of (long-running or infinite loops) user code in JShell, however
>> Thread::stop is deprecated and planned for removal.
>>
>> Proposed patch instruments
> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel
> execution of (long-running or infinite loops) user code in JShell, however
> Thread::stop is deprecated and planned for removal.
>
> Proposed patch instruments all user code to call
> LocalExecutionControl::stopCheck
On Mon, 5 Sep 2022 14:42:56 GMT, Adam Sotona wrote:
>> This is the last usage of Thread.stop in the JDK so this change is welcome.
>>
>> The instrumentation to check a flag at jump instrumentation looks
>> reasonable, and works here because the method is public on a public class in
>> an
On Mon, 5 Sep 2022 13:18:08 GMT, Alan Bateman wrote:
>> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel
>> execution of (long-running or infinite loops) user code in JShell, however
>> Thread::stop is deprecated and planned for removal.
>>
>> Proposed patch
On Mon, 5 Sep 2022 12:39:41 GMT, Adam Sotona wrote:
> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel
> execution of (long-running or infinite loops) user code in JShell, however
> Thread::stop is deprecated and planned for removal.
>
> Proposed patch instruments all
On Mon, 5 Sep 2022 12:39:41 GMT, Adam Sotona wrote:
> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel
> execution of (long-running or infinite loops) user code in JShell, however
> Thread::stop is deprecated and planned for removal.
>
> Proposed patch instruments all
On Mon, 5 Sep 2022 12:39:41 GMT, Adam Sotona wrote:
> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel
> execution of (long-running or infinite loops) user code in JShell, however
> Thread::stop is deprecated and planned for removal.
>
> Proposed patch instruments all
On Mon, 5 Sep 2022 12:39:41 GMT, Adam Sotona wrote:
> LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel
> execution of (long-running or infinite loops) user code in JShell, however
> Thread::stop is deprecated and planned for removal.
>
> Proposed patch instruments all
LocalExecutionControl in jdk.jshell actually uses Thread::stop to cancel
execution of (long-running or infinite loops) user code in JShell, however
Thread::stop is deprecated and planned for removal.
Proposed patch instruments all user code to call
LocalExecutionControl::stopCheck method
On Mon, 5 Sep 2022 07:38:33 GMT, Thomas Stuefe wrote:
> So I guess at the minimum we would have to downport those test changes to be
> able to test older JDKs with the new jtreg, right?
Yes. Otherwise those tests will fail as they still do depend on hard-coded
names of 3rd-party JAR files.
On Mon, 5 Sep 2022 07:18:09 GMT, Christian Stein wrote:
> > Is jtreg 7 downward compatible? Can I use it to test older JDKs, if yes,
> > down to which version?
>
> Yes, down to JDK 11.
>
> Quote from [Coming soon: jtreg
> 7](https://mail.openjdk.org/pipermail/jdk-dev/2022-August/006869.html)
On Mon, 5 Sep 2022 06:36:04 GMT, Thomas Stuefe wrote:
> Is jtreg 7 downward compatible? Can I use it to test older JDKs, if yes, down
> to which version?
Yes, down to JDK 11.
Quote from [Coming soon: jtreg
7](https://mail.openjdk.org/pipermail/jdk-dev/2022-August/006869.html)
> Also
On Mon, 5 Sep 2022 06:12:18 GMT, Christian Stein wrote:
>> Please review the change to update to using jtreg 7.
>>
>> 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
> Please review the change to update to using jtreg 7.
>
> 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.
24 matches
Mail list logo