On Wed, 21 May 2025 21:31:16 GMT, Chen Liang wrote:
>> In offline discussion, we noted that the documentation on this annotation
>> does not recommend minimizing the intrinsified section and moving whatever
>> can be done in Java to Java; thus I prepared this docume
On Tue, 24 Jun 2025 22:32:30 GMT, Chen Liang wrote:
> Currently, fake parameters are created with "arg0" etc. strings that are
> retained for class file methods with no MethodParameters attribute. The
> original issue report observes many of these strings present in the
On Thu, 17 Jul 2025 21:40:13 GMT, Joe Darcy wrote:
>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Implement review feedback.
This array unrolling l
no other places where most significant bits are ever
> meaningful, and I special cased it and consistently fail fast for all other
> OOB values, which always mean programmer errors.
>
> A CSR will be created soon as well.
Chen Liang has updated the pull request incrementally wit
> Sometimes, for version-specific feature access APIs, we wish to access the
> preview features of the current Java SE release. To reduce the impact of
> adding one preview-specific version on every site, we can add a constant
> modeling the preview features as a fake version.
Ch
> Sometimes, for version-specific feature access APIs, we wish to access the
> preview features of the current Java SE release. To reduce the impact of
> adding one preview-specific version on every site, we can add a constant
> modeling the preview features as a fake version.
Ch
com/en/java/javase/24/docs/api/java.base/java/lang/foreign/MemoryLayout.html#access-mode-restrictions
Chen Liang has updated the pull request incrementally with one additional
commit since the last revision:
Simplify wording
-
Changes:
- all: https://git.openjdk.org/jdk/p
On Thu, 17 Jul 2025 18:18:21 GMT, Maurizio Cimadamore
wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> avoid "non-atomic"
>
> src/java.base/share/classes/java/lang/forei
On Thu, 17 Jul 2025 17:44:04 GMT, Joe Darcy wrote:
>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Respond to review feedback and update copyright.
On Thu, 17 Jul 2025 17:44:04 GMT, Joe Darcy wrote:
>> Add `@Stable` to the static final arrays used in the Java port of FDLIBM.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Respond to review feedback and update copyright.
On Wed, 16 Jul 2025 09:28:28 GMT, Raffaello Giulietti
wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> "may be non-atomic"
>
> src/java.base/share/classes/java/lang/forei
com/en/java/javase/24/docs/api/java.base/java/lang/foreign/MemoryLayout.html#access-mode-restrictions
Chen Liang has updated the pull request incrementally with one additional
commit since the last revision:
avoid "non-atomic"
-
Changes:
- all: https://git.openjdk
On Thu, 17 Jul 2025 15:32:32 GMT, cagliostro92 wrote:
>> Trivial PR to enhance Javadoc for the `Properties#list` method, which has
>> cost me some debugging time.
>
> cagliostro92 has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8358530: ad
On Wed, 16 Jul 2025 17:45:23 GMT, Ioi Lam wrote:
> Please review this documentation update, authored by @rose00 and originally
> pushed to the Leyden repo in [this
> PR](https://github.com/openjdk/leyden/pull/26), where more comments can be
> found regarding this update.
Marked as reviewed by
The detection of catch builder arguments is not working for catch-all blocks.
Update this to track CP indices including 0 so we can more easily validate the
incoming ClassDesc are all non-primitive and there is no duplicate.
-
Commit messages:
- Formatting
- 8361638: java.lang.cla
On Tue, 1 Jul 2025 17:02:27 GMT, David Beaumont wrote:
>> Initial benchmark to capture at least some comparative measures of
>> ImageReader performance.
>>
>> Current results on my laptop:
>>
>> Benchmark Mode Cnt ScoreError
>> Units
>> NewImage
On Tue, 1 Jul 2025 17:02:27 GMT, David Beaumont wrote:
>> Initial benchmark to capture at least some comparative measures of
>> ImageReader performance.
>>
>> Current results on my laptop:
>>
>> Benchmark Mode Cnt ScoreError
>> Units
>> NewImage
On Fri, 11 Jul 2025 19:02:31 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We c
On Mon, 16 Jun 2025 21:19:45 GMT, Johannes Graham wrote:
>> This PR replaces construction of intermediate strings to be parsed with more
>> direct manipulation of numbers. It also has a more streamlined mechanism of
>> handling `Long.MIN_VALUE` when parsing longs by using
>> `Long.parseUnsigne
On Thu, 10 Jul 2025 22:32:45 GMT, Chen Liang wrote:
> Currently, the aforementioned two methods do not throw NPE upon null input,
> but throw IAE.
>
> This behavior is bad for composition: `bsmEntry` actually throws IAE for
> nested null in the argument list/array, and
On Thu, 10 Jul 2025 22:32:45 GMT, Chen Liang wrote:
> Currently, the aforementioned two methods do not throw NPE upon null input,
> but throw IAE.
>
> This behavior is bad for composition: `bsmEntry` actually throws IAE for
> nested null in the argument list/array, and
On Mon, 14 Jul 2025 04:53:13 GMT, Xueming Shen wrote:
> Regex class should conform to **_Level 1_** of [Unicode Technical Standard
> #18: Unicode Regular Expressions](http://www.unicode.org/reports/tr18/), plus
> RL2.1 Canonical Equivalents and RL2.2 Extended Grapheme Clusters.
>
> This PR pri
an error; we should eagerly
> reject lists that would never be encodable in the `class` file format when
> users construct model objects.
Chen Liang has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated changes brough
no other places where most significant bits are ever
> meaningful, and I special cased it and consistently fail fast for all other
> OOB values, which always mean programmer errors.
>
> A CSR will be created soon as well.
Chen Liang has updated the pull request with a new target bas
On Mon, 30 Jun 2025 06:01:44 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which proposes to clarify
>> the current implementation of the `java.util.Properties.list(...)` methods?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8360575, the current
>> impl
On Thu, 10 Jul 2025 21:47:35 GMT, Chen Liang wrote:
> Noticed this error when I was verifying all sizes are u2 compatible and
> verified with a test that fails on mainline with ConstantPoolException
> (because we write a size of 2 with 1-length list content) and works in this
> pa
On Wed, 9 Jul 2025 19:33:38 GMT, Chen Liang wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [c9bea773](https://github.com/openjdk/jdk/commit/c9bea77342672715f8f720d7311d66c2b3ac9f8a)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
On Thu, 10 Jul 2025 21:47:35 GMT, Chen Liang wrote:
> Noticed this error when I was verifying all sizes are u2 compatible and
> verified with a test that fails on mainline with ConstantPoolException
> (because we write a size of 2 with 1-length list content) and works in this
> pa
On Wed, 9 Jul 2025 19:33:38 GMT, Chen Liang wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [c9bea773](https://github.com/openjdk/jdk/commit/c9bea77342672715f8f720d7311d66c2b3ac9f8a)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
On Wed, 9 Jul 2025 21:14:17 GMT, Chen Liang wrote:
> Currently, DirectCodeBuilder is erroneously missing argument checks for a few
> of its override methods that take arguments such as Opcode and the array size
> for multianewarray and the switches, which would write somethi
On Wed, 9 Jul 2025 21:14:17 GMT, Chen Liang wrote:
> Currently, DirectCodeBuilder is erroneously missing argument checks for a few
> of its override methods that take arguments such as Opcode and the array size
> for multianewarray and the switches, which would write somethi
On Fri, 11 Jul 2025 14:27:21 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We c
On Fri, 11 Jul 2025 17:45:01 GMT, Paul Sandoz wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Correct term is atomic, not word tearing
>
> src/java.base/share/classes/java/lang/fore
com/en/java/javase/24/docs/api/java.base/java/lang/foreign/MemoryLayout.html#access-mode-restrictions
Chen Liang has updated the pull request incrementally with one additional
commit since the last revision:
"may be non-atomic"
-
Changes:
- all: https://git.openjdk
On Fri, 11 Jul 2025 14:03:44 GMT, Adam Sotona wrote:
>> Currently, DirectCodeBuilder is erroneously missing argument checks for a
>> few of its override methods that take arguments such as Opcode and the array
>> size for multianewarray and the switches, which would write something before
>> t
On Fri, 11 Jul 2025 15:31:53 GMT, Nizar Benalla wrote:
>> Once https://bugs.openjdk.org/browse/JDK-8358769 is resolved,
>> JavaBaseCheckSince no longer needs to be problemlisted.
>
> Nizar Benalla has updated the pull request with a new target base due to a
> merge or a rebase. The pull request
On Fri, 11 Jul 2025 13:17:04 GMT, Chen Liang wrote:
>> Right, "word tearing" and "non-atomic access" are different notions.
>
> True, word tearing is racing a single memory location. Good that we
> discovered another spec bug and could fix it in time for 25.
On Thu, 10 Jul 2025 21:01:18 GMT, Chen Liang wrote:
> The `class` file format often only stores lists up to 65535 in size because
> size is encoded as a u2. Currently, we truncate the list size and write all
> contents, creating malformed `class` files. Almost all scenarios w
com/en/java/javase/24/docs/api/java.base/java/lang/foreign/MemoryLayout.html#access-mode-restrictions
Chen Liang has updated the pull request incrementally with one additional
commit since the last revision:
Correct term is atomic, not word tearing
-
Changes:
- all: https://git.op
On Fri, 11 Jul 2025 13:05:09 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4311:
>>
>>> 4309: * access modes {@code get} and {@code set} for {@code long},
>>> {@code
>>> 4310: * double} are supported but might lead to
On 32 bit platforms, when an access to long/double is aligned, it is supported
but not atomic. The original wording in
`MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
all. We can fix that by borrowing the improved specification from
`MemoryLayout::varHandle`.
-
Currently, the aforementioned two methods do not throw NPE upon null input, but
throw IAE.
This behavior is bad for composition: `bsmEntry` actually throws IAE for nested
null in the argument list/array, and other APIs are similarly affected.
Given this domino effect, I think the best way is to
Noticed this error when I was verifying all sizes are u2 compatible and
verified with a test that fails on mainline with ConstantPoolException (because
we write a size of 2 with 1-length list content) and works in this patch.
Problem wasn't discovered before because we use the `handlersSize <
h
The `class` file format often only stores lists up to 65535 in size because
size is encoded as a u2. Currently, we truncate the list size and write all
contents, creating malformed `class` files. Almost all scenarios where such
oversized lists are created can be considered an error; we should ea
On Fri, 27 Jun 2025 07:22:48 GMT, Tobias Hartmann wrote:
>> src/java.base/share/classes/java/lang/StringCoding.java line 93:
>>
>>> 91: public static int countPositives(byte[] ba, int off, int len) {
>>> 92: Objects.requireNonNull(ba, "ba");
>>> 93: Objects.checkFromIndexSize
On Thu, 26 Jun 2025 10:48:37 GMT, Volkan Yazici wrote:
> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve
> their documentation, enhance the checks in the associated C++ methods, and
> adapt them to cause VM crash on invalid input.
>
> ## Implementation notes
>
> Th
Currently, DirectCodeBuilder is erroneously missing argument checks for a few
of its override methods that take arguments such as Opcode and the array size
for multianewarray and the switches, which would write something before
throwing an exception. We correct these problems and verify with som
On Tue, 8 Jul 2025 20:45:20 GMT, simon wrote:
>> 8360122: Refine formatting of Connection.java interface
>>
>> -
>> ### Progress
>> - [x] Change must be properly reviewed (1 review required, with at least 1
>> [Reviewer](https://openjdk.org/bylaws#reviewer))
>> - [x] Change must not con
On Wed, 9 Jul 2025 19:35:54 GMT, simon wrote:
> Can you integrate it when you think it is appropriate? I guess I do not have
> permission to do it.
They are done with GitHub comments parsed by bots, so if there is a line:
> /integrate
in a comment from you, the bot will integrate this patch (
On Tue, 8 Jul 2025 18:46:00 GMT, Chen Liang wrote:
> In a recent inspection of all methods that accept an `int` argument in the
> Class-File API, I noticed this method that validates its argument but did not
> document the validation. The behavior is to throw IOOBE. We can simply
&
Hi all,
This pull request contains a backport of commit
[c9bea773](https://github.com/openjdk/jdk/commit/c9bea77342672715f8f720d7311d66c2b3ac9f8a)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. #26200
The commit being backported was authored by Chen Liang on 9 Jul 2025 and was
On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato wrote:
> Replaced Collections.emptyList() with List.of() as part of refactoring. This
> was discussed in the context of investigating a CDS-related issue
> (https://bugs.openjdk.org/browse/JDK-8357281?focusedId=14796714&page=com.atlassian.jira.plugin.
On Tue, 8 Jul 2025 18:46:00 GMT, Chen Liang wrote:
> In a recent inspection of all methods that accept an `int` argument in the
> Class-File API, I noticed this method that validates its argument but did not
> document the validation. The behavior is to throw IOOBE. We can simply
&
On Tue, 8 Jul 2025 18:46:00 GMT, Chen Liang wrote:
> In a recent inspection of all methods that accept an `int` argument in the
> Class-File API, I noticed this method that validates its argument but did not
> document the validation. The behavior is to throw IOOBE. We can simply
&
On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato wrote:
> Replaced Collections.emptyList() with List.of() as part of refactoring. This
> was discussed in the context of investigating a CDS-related issue
> (https://bugs.openjdk.org/browse/JDK-8357281?focusedId=14796714&page=com.atlassian.jira.plugin.
se
> lists to core library annotations as a first step, we can gradually expose
> the AOT contracts as program semantics described by internal annotations, and
> also helps us to explore how we can expose these functionalities to the
> public later.
Chen Liang has updated the pull r
On Mon, 7 Jul 2025 23:21:58 GMT, Chen Liang wrote:
> The class file API verifier seems to be based off a version of hotspot
> verifier before Mar 3 2021. We are thus missing a few patches in the hotspot
> verifier:
> [JDK-8350029](https://bugs.openjdk.org/browse/JDK-8350029)
&g
On Mon, 7 Jul 2025 23:21:58 GMT, Chen Liang wrote:
> The class file API verifier seems to be based off a version of hotspot
> verifier before Mar 3 2021. We are thus missing a few patches in the hotspot
> verifier:
> [JDK-8350029](https://bugs.openjdk.org/browse/JDK-8350029)
&g
no other places where most significant bits are ever
> meaningful, and I special cased it and consistently fail fast for all other
> OOB values, which always mean programmer errors.
>
> A CSR will be created soon as well.
Chen Liang has updated the pull request incrementally wit
In the `class` file format, a lot of the values are `u1` or `u2`; the
Class-File API consistently model them with `int`. However, the API does not,
in general, validate that int values passed to the factory methods are not out
of the bounds as defined in the class file format. This patch propose
In a recent inspection of all methods that accept an `int` argument in the
Class-File API, I noticed this method that validates its argument but did not
document the validation. The behavior is to throw IOOBE. We can simply document
this behavior and enhance existing tests to verify exceptional
On Thu, 3 Jul 2025 18:41:27 GMT, Chen Liang wrote:
>> Unsafe throws IAE for misusing static vs instance fields, and it's revealed
>> that AtomicXxxFieldUpdaters are using this mechanism to reject static
>> fields. This is not a good practice, but we can at least docume
se
> lists to core library annotations as a first step, we can gradually expose
> the AOT contracts as program semantics described by internal annotations, and
> also helps us to explore how we can expose these functionalities to the
> public later.
Chen Liang has updated the pull r
On Tue, 8 Jul 2025 16:28:45 GMT, ExE Boss wrote:
>> The class file API verifier seems to be based off a version of hotspot
>> verifier before Mar 3 2021. We are thus missing a few patches in the hotspot
>> verifier:
>> [JDK-8350029](https://bugs.openjdk.org/browse/JDK-8350029)
>> [JDK-8340110]
On Fri, 30 May 2025 12:00:28 GMT, Darragh Clarke wrote:
> This PR aims to Panamize the Java Kqueue implementation, This is based on the
> work that was previously shared in https://github.com/openjdk/jdk/pull/22307
> , The main change since then is that this branch takes advantage of the
> cha
On Mon, 7 Jul 2025 16:13:08 GMT, Andrew Haley wrote:
> Neither `ScopedValue.orElse` nor `ScopedValue.orElseThrow` consult the cache
> when searching for a binding. Neither do they update the cache when a binding
> is found.
> While this issue does not affect spec compliance, it is surprising to
The class file API verifier seems to be based off a version of hotspot verifier
before Mar 3 2021. We are thus missing a few patches in the hotspot verifier:
[JDK-8350029](https://bugs.openjdk.org/browse/JDK-8350029)
[JDK-8340110](https://bugs.openjdk.org/browse/JDK-8340110)
[JDK-8330606](https:
On Mon, 7 Jul 2025 16:13:08 GMT, Andrew Haley wrote:
> Neither `ScopedValue.orElse` nor `ScopedValue.orElseThrow` consult the cache
> when searching for a binding. Neither do they update the cache when a binding
> is found.
> While this issue does not affect spec compliance, it is surprising to
On Mon, 7 Jul 2025 09:58:15 GMT, Viktor Klang wrote:
>> src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java
>> line 407:
>>
>>> 405: if (Modifier.isStatic(modifiers))
>>> 406: throw new IllegalArgumentException("Must not be a
>>> s
On Mon, 7 Jul 2025 09:54:28 GMT, Per Minborg wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Test to verify observed internal unsafe behaviors
>
> src/java.base/share/class
On Sun, 6 Jul 2025 18:32:56 GMT, ExE Boss wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Test to verify observed internal unsafe behaviors
>
> test/jdk/jdk/internal/misc/Unsafe/Addre
> Unsafe throws IAE for misusing static vs instance fields, and it's revealed
> that AtomicXxxFieldUpdaters are using this mechanism to reject static fields.
> This is not a good practice, but we can at least document this so we don't
> accidentally introduce problems.
On Thu, 26 Jun 2025 05:42:24 GMT, ExE Boss wrote:
>> Unsafe throws IAE for misusing static vs instance fields, and it's revealed
>> that AtomicXxxFieldUpdaters are using this mechanism to reject static
>> fields. This is not a good practice, but we can at least document this so we
>> don't acc
se
> lists to core library annotations as a first step, we can gradually expose
> the AOT contracts as program semantics described by internal annotations, and
> also helps us to explore how we can expose these functionalities to the
> public later.
Chen Liang has updated the pul
On Thu, 3 Jul 2025 00:09:14 GMT, Ioi Lam wrote:
>> Also quick question: Should I use `_transitive_interfaces` or can I use
>> `_local_interfaces`?
>
> local_interfaces is fine, because the interfaces implemented by the super
> classes would have been checked when the super classes were loaded.
On Thu, 3 Jul 2025 13:34:23 GMT, Andrew Haley wrote:
>> Scoped values cannot be used early in the JDK boot process because of some
>> dependencies on System.getProperty(). This dependency should be removed in a
>> way that allows scoped values to be created (but not necessarily bound) at
>> an
On Thu, 3 Jul 2025 13:56:24 GMT, Chen Liang wrote:
>> Unsafe throws IAE for misusing static vs instance fields, and it's revealed
>> that AtomicXxxFieldUpdaters are using this mechanism to reject static
>> fields. This is not a good practice, but we can at least docume
> Unsafe throws IAE for misusing static vs instance fields, and it's revealed
> that AtomicXxxFieldUpdaters are using this mechanism to reject static fields.
> This is not a good practice, but we can at least document this so we don't
> accidentally introduce problems.
> Unsafe throws IAE for misusing static vs instance fields, and it's revealed
> that AtomicXxxFieldUpdaters are using this mechanism to reject static fields.
> This is not a good practice, but we can at least document this so we don't
> accidentally introduce problems.
> Sometimes, for version-specific feature access APIs, we wish to access the
> preview features of the current Java SE release. To reduce the impact of
> adding one preview-specific version on every site, we can add a constant
> modeling the preview features as a fake version.
Ch
On Wed, 2 Jul 2025 21:18:14 GMT, Ioi Lam wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Documentation
>
> src/hotspot/share/classfile/classFileParser.cpp line 5171:
>
&
On Tue, 24 Jun 2025 00:04:54 GMT, Chen Liang wrote:
> Unsafe throws IAE for misusing static vs instance fields, and it's revealed
> that AtomicXxxFieldUpdaters are using this mechanism to reject static fields.
> This is not a good practice, but we can at least document th
On Tue, 24 Jun 2025 18:34:02 GMT, ExE Boss wrote:
>> Unsafe throws IAE for misusing static vs instance fields, and it's revealed
>> that AtomicXxxFieldUpdaters are using this mechanism to reject static
>> fields. This is not a good practice, but we can at least document this so we
>> don't acc
On Tue, 24 Jun 2025 18:16:29 GMT, Chen Liang wrote:
>> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 1070:
>>
>>> 1068: *
>>> 1069: * @throws NullPointerException if the field is {@code null}
>>> 1070: * @throws IllegalA
Unsafe throws IAE for misusing static vs instance fields, and it's revealed
that AtomicXxxFieldUpdaters are using this mechanism to reject static fields.
This is not a good practice, but we can at least document this so we don't
accidentally introduce problems.
-
Commit messages:
se
> lists to core library annotations as a first step, we can gradually expose
> the AOT contracts as program semantics described by internal annotations, and
> also helps us to explore how we can expose these functionalities to the
> public later.
Chen Liang has updated the pul
se
> lists to core library annotations as a first step, we can gradually expose
> the AOT contracts as program semantics described by internal annotations, and
> also helps us to explore how we can expose these functionalities to the
> public later.
Chen Liang has updated the pul
I think Brett is right. The spec of CharBuffer says:
The methods defined by {@code CharSequence} operate relative to the current
position of the buffer when they are invoked.
Yet getChars is an absolute bulk get method.
Since JDK25 is still in RDP, we still have a chance to fix this up.
On Wed, 2 Jul 2025 07:48:05 GMT, Andrew Dinn wrote:
>> src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 68:
>>
>>> 66: * @param species data type.
>>> 67: */
>>> 68: @AOTSafeClassInitializer
>>
>> This should be placed below the `/*non-public*/` comment.
>
> Perhaps al
se
> lists to core library annotations as a first step, we can gradually expose
> the AOT contracts as program semantics described by internal annotations, and
> also helps us to explore how we can expose these functionalities to the
> public later.
Chen Liang has updated the pull
On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen wrote:
>> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>>
>> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder
>> has a ByteBuffer. There are two layers of cache here, or the BufferedWriter
>> layer can be removed. A
On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen wrote:
>> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>>
>> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder
>> has a ByteBuffer. There are two layers of cache here, or the BufferedWriter
>> layer can be removed. A
Indeed, given that ByteOrder is more widely used and appears in many other
APIs like FFM, it would be quite helpful to modernize it. There are other
eligible candidates like CodingErrorAction, but their usages are more
restricted to Buffer itself.
On Tue, Jul 1, 2025 at 11:15 AM Rob Spoor wrote:
On Tue, 1 Jul 2025 23:03:32 GMT, Chen Liang wrote:
>> I have updated this patch to avoid a redundant `runtimeSetup` annotation -
>> we have agreed that the requirement for setup is a side effect of
>> initialization, and such methods in AOTCI classes must be automatically
&
se
> lists to core library annotations as a first step, we can gradually expose
> the AOT contracts as program semantics described by internal annotations, and
> also helps us to explore how we can expose these functionalities to the
> public later.
Chen Liang has updated the pul
se
> lists to core library annotations as a first step, we can gradually expose
> the AOT contracts as program semantics described by internal annotations, and
> also helps us to explore how we can expose these functionalities to the
> public later.
Chen Liang has updated the pul
Hi Brett, I think your suggestion makes sense. I have created
https://bugs.openjdk.org/browse/JDK-8361209 to track this RFE.
Feel free to contribute a patch to implement this enhancement.
From: core-libs-dev on behalf of Brett Okken
Sent: Tuesday, July 1, 2025
On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen wrote:
>> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>>
>> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder
>> has a ByteBuffer. There are two layers of cache here, or the BufferedWriter
>> layer can be removed. A
se
> lists to core library annotations as a first step, we can gradually expose
> the AOT contracts as program semantics described by internal annotations, and
> also helps us to explore how we can expose these functionalities to the
> public later.
Chen Liang has updated the pul
On Sat, 21 Jun 2025 00:03:26 GMT, Chen Liang wrote:
> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we
> have agreed that the requirement for setup is a side effect of
> initialization, and such methods in AOTCI classes must be automatically
> reco
1 - 100 of 2214 matches
Mail list logo
