On Mon, 5 Sep 2022 19:23:30 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
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
/Library/Java/JavaVirtualMachines/jdk-19.jdk/Conte
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 m
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 s
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: https://git.openjdk.org/jdk/pull/6935/files/2
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:
>
>> 493:
> 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: https://git.openjd
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 stable
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 m
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 expor
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 instruments
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 u
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 u
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 u
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 u
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 before
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. Fin
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 starting
23 matches
Mail list logo
