On Tue, 30 Aug 2022 07:10:36 GMT, Andrey Turbanov wrote:
> After integration of
> [JDK-8259021](https://bugs.openjdk.org/browse/JDK-8259021) a few more fields
> were added to `SharedSecrets` class. It make sense to update their reading
> code to use the same idiom.
This pull request has now b
THREAD_NOT_ALIVE originates from JVMTI. However, the debug agent converts it to
INVALID_THREAD before passing it on to the debug agent client (the debugger,
usually JDI), so debug agent users (JDI) should never see it. Currently
ThreadReference.forceEarlyReturn() is the only API that even bother
> On Sep 6, 2022, at 4:52 PM, Michael Hall wrote:
>
>
>
>> On Sep 6, 2022, at 4:48 PM, Alexander Matveev
>> wrote:
>>
>> Hi Michael,
>>
>> Did you generate application image with same JDK version (19+36-2238)? With
>> latest JDK version .jpackage.xml file should be present. We do not su
> On Sep 6, 2022, at 4:52 PM, Michael Hall wrote:
>
>
>
>> On Sep 6, 2022, at 4:48 PM, Alexander Matveev
>> wrote:
>>
>> Hi Michael,
>>
>> Did you generate application image with same JDK version (19+36-2238)? With
>> latest JDK version .jpackage.xml file should be present. We do not sup
> On Sep 6, 2022, at 4:48 PM, Alexander Matveev
> wrote:
>
> Hi Michael,
>
> Did you generate application image with same JDK version (19+36-2238)? With
> latest JDK version .jpackage.xml file should be present. We do not support
> signing of application images generate by another versions
Hi Michael,
Did you generate application image with same JDK version (19+36-2238)? With
latest JDK version .jpackage.xml file should be present. We do not support
signing of application images generate by another versions of JDK. It should be
same JDK.
Thanks,
Alexander
> On Sep 5, 2022, at 4
On Thu, 1 Sep 2022 21:17:30 GMT, Vladimir Kozlov wrote:
>> Yes; I removed support for --release 7 in JDK 20 early today.
>>
>>
>> On Thu, Sep 1, 2022 at 1:36 PM Paul Sandoz ***@***.***> wrote:
>>
>>> Likely requires a merge with master.
>>>
>>> —
>>> Reply to this email directly, view it on Gi
> Fixed the max week number on parsing the week of week-based year field in
> strict mode. It used to be always returning the largest maximum, which should
> be adjusted by the actual week-based year.
Naoto Sato has updated the pull request with a new target base due to a merge
or a rebase. The
Fixed the max week number on parsing the week of week-based year field in
strict mode. It used to be always returning the largest maximum, which should
be adjusted by the actual week-based year.
-
Commit messages:
- 8293146: Strict DateTimeFormatter fails to report an invalid week
On Tue, 6 Sep 2022 17:11:39 GMT, Daniel Fuchs wrote:
>> Thank you all for your kind help and feedback.
>>
>> @AlanBateman So is now the time to switch this PR from Draft to Ready?
>
> The source changes LGTM. I suppose you should now revert the changes above
> (in `HexPrinter.java`), otherwise
> Implementation of JDK-8279283
Markus KARG has updated the pull request incrementally with one additional
commit since the last revision:
Revert "HexPrinter::transferTo"
This reverts commit 6f0e2a8f7be5706b39a8e9bc88a97f34d2819098.
-
Changes:
- all: https://git.openjdk.or
On Tue, 6 Sep 2022 17:01:09 GMT, Markus KARG wrote:
>>> @AlanBateman Async close leaves BIS in an invalid state. The JavaDocs say `
>>> The behavior for the case where the input and/or output stream is
>>> asynchronously closed, or the thread interrupted during the transfer, is
>>> highly inpu
On Tue, 6 Sep 2022 16:29:39 GMT, Alan Bateman wrote:
>> BIS dates from JDK 1.0 and it's not hard to find examples that extend it.
>> The HexPrinter test reminds us that it has been possible for 25+ years to
>> override the read methods and snoop on all bytes that are read. Adding an
>> overrid
On Tue, 6 Sep 2022 16:56:03 GMT, Markus KARG wrote:
>> src/java.base/share/classes/java/io/BufferedInputStream.java line 608:
>>
>>> 606: private long implTransferTo(OutputStream out) throws IOException {
>>> 607: if (getClass() == BufferedInputStream.class
>>> 608: &
On Tue, 6 Sep 2022 14:51:20 GMT, Сергей Цыпанов wrote:
>> Markus KARG has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains ten commits:
>>
>> - proposal by Alan Bateman
>> - modified locking
>> - HexPrinter::transferTo
>> - using g
On Thu, 25 Aug 2022 14:32:06 GMT, Strahinja Stanojevic wrote:
> 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
> `lam
On Tue, 6 Sep 2022 12:14:37 GMT, Alan Bateman wrote:
>> With the changes you proposed a CSR will definitely be needed.
>
> BIS dates from JDK 1.0 and it's not hard to find examples that extend it. The
> HexPrinter test reminds us that it has been possible for 25+ years to
> override the read me
On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato wrote:
> Please review this PR. The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.
This pull request has now been integrated.
Changeset
On Tue, 6 Sep 2022 13:00:23 GMT, Markus KARG wrote:
>> Rebased and fixed locking, using your proposed code now.
>>
>> @AlanBateman Async close leaves BIS in an invalid state. The JavaDocs say `
>> The behavior for the case where the inputand/or output stream is
>> asynchronously closed, or th
On Tue, 6 Sep 2022 12:50:50 GMT, Markus KARG wrote:
>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains ten commits:
>
> - proposal by Alan Bateman
> - modified locking
> - HexPrinter
On Tue, 6 Sep 2022 12:32:46 GMT, Markus KARG wrote:
>> BIS dates from JDK 1.0 and it's not hard to find examples that extend it.
>> The HexPrinter test reminds us that it has been possible for 25+ years to
>> override the read methods and snoop on all bytes that are read. Adding an
>> override
On Tue, 6 Sep 2022 12:56:46 GMT, Markus KARG wrote:
>> Thank you for your decision about this issue, so instead of fixing the
>> existing bugs I will implement as you outlined.
>>
>> BTW, locking and rebasing is on the way.
>
> Rebased and fixed locking, using your proposed code now.
>
> @Alan
> Implementation of JDK-8279283
Markus KARG has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains ten commits:
- proposal by Alan Bateman
- modified locking
- HexPrinter::transferTo
- using getBufIfOpen() instead of direct buf access
-
On Tue, 6 Sep 2022 12:14:37 GMT, Alan Bateman wrote:
>> With the changes you proposed a CSR will definitely be needed.
>
> BIS dates from JDK 1.0 and it's not hard to find examples that extend it. The
> HexPrinter test reminds us that it has been possible for 25+ years to
> override the read me
> The symbolic constants API (`java.lang.constant`) was designed, in part, to
> provide bytecode parsing and generation APIs with a validated, common,
> symbolic form for constants in Java class files.
>
> There is an easy way to create a `ClassDesc` from a binary name
> (`ClassDesc::of`) or a
> Please review this patch adding new lint option, **lossy-conversions**, to
> javac to warn about type casts in compound assignments with possible lossy
> conversions.
>
> The new lint warning is shown if the type of the right-hand operand of a
> compound assignment is not assignment compatibl
On Tue, 6 Sep 2022 08:06:13 GMT, Rémi Forax wrote:
>> Adam Sotona has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - allStop field and stopCheck method moved to synthetic REPL.$Cancel$
>> - Revert "alternative implementation where instru
On Tue, 6 Sep 2022 12:10:00 GMT, Daniel Fuchs wrote:
>>> It's a well known behavior that overriding the`read(...)` method is
>>> sufficient to implement subclass behavior. This will no longer be the case
>>> if `transferTo(...)` no longer calls `this.read(...)` as it used to. There
>>> are man
On Tue, 6 Sep 2022 11:26:18 GMT, Markus KARG wrote:
>> It's a well known behavior that overriding the`read(...)` method is
>> sufficient to implement subclass behavior. This will no longer be the case
>> if `transferTo(...)` no longer calls `this.read(...)` as it used to. There
>> are many und
On Tue, 6 Sep 2022 09:49:16 GMT, Daniel Fuchs wrote:
> It's a well known behavior that overriding the`read(...)` method is
> sufficient to implement subclass behavior. This will no longer be the case if
> `transferTo(...)` no longer calls `this.read(...)` as it used to. There are
> many undocu
On Tue, 6 Sep 2022 07:55:55 GMT, Markus KARG wrote:
>> test/lib/jdk/test/lib/hexdump/HexPrinter.java line 1194:
>>
>>> 1192: byteOffset += size;
>>> 1193: return size;
>>> 1194: }
>>
>> This is an indication that overriding `transferTo()` in
>> `BufferedInputStr
> 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 Tue, 6 Sep 2022 08:04:07 GMT, Rémi Forax wrote:
>> Adam Sotona has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - allStop field and stopCheck method moved to synthetic REPL.$Cancel$
>> - Revert "alternative implementation where instru
On Mon, 5 Sep 2022 20:21:01 GMT, Daniel Fuchs wrote:
>> 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: byteOffset +=
34 matches
Mail list logo
