Brainstorming time:
I think Brett's suggestion makes sense: BufferedWriter now can handle a mix
of String and char[] inputs. So if the input is all LATIN1 Strings, we can
allow them to stay LATIN1 in the StringBuilder and let OutputStreamWriter
decide if the OSW has a fast path for LATIN1 when it i
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 Sat, 28 Jun 2025 07:01:29 GMT, Alan Bateman wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Andy's review suggestions
>
> src/java.base/share/classes/java/util/Properties.java line 1219:
>
>> 1217: * @impl
> 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
> implementation trims each value to a size of 37 when printing out
On 29/06/2025 17:03, wenshao 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.
LATIN1 (byte[]) -> UTF16 (ch
> 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. And when charset is UTF8, if the content of write(String) is
On Fri, 27 Jun 2025 16:48:40 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. And w
On Fri, 27 Jun 2025 16:48:40 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. And w
On Fri, 27 Jun 2025 16:48:40 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. And w
On Fri, 27 Jun 2025 16:48:40 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. And w
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. And when charset is UTF8, if the content of write(String) is
LATIN1,
Both Writer and CharsetEncoder are designed for char[]. Converting
BufferedWriter to use byte[] value + byte coder like StringBuilder will also
require redundant encoding conversion when using LATIN1 String, and the
performance will not be good.
--
On Fri, 2 May 2025 22:55:09 GMT, Chen Liang wrote:
> 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 p
Maybe another option would be to implement BufferedWriter with a
StringBuilder rather than a char[]. This would remove the force to utf-16
On Sun, Jun 29, 2025 at 10:36 PM Brett Okken
wrote:
> Is StreamEncoder buffering content to only write to the underlying
> OutputStream when some threshold i
Is StreamEncoder buffering content to only write to the underlying
OutputStream when some threshold is hit? While the layers of conversions
are unfortunate, it seems there could be negative performance implications
of having many extremely small writes (such as 1 character/byte) at a time
to the un
On Fri, 27 Jun 2025 20:45:14 GMT, Naoto Sato wrote:
> The ICU4J component currently stores binary data files directly in the
> repository. This change replaces them with base64-encoded text files and
> converts them to binary during the build process
I don't see any benefit of checking in base
> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
> use java.lang.ref.Cleaner.
>
> This change is algorithmica
On Fri, 27 Jun 2025 17:43:34 GMT, Brent Christian wrote:
>> Kim Barrett has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 11 additional
>> commits
On Fri, 27 Jun 2025 19:29:18 GMT, Brent Christian wrote:
>> I intentionally (re)used the "Cleaner" name to avoid a bunch of renames that
>> would increase the size of the change and distract from the meat of it. I
>> think the name to use might be affected by how the implementation of the set
>>
On Fri, 27 Jun 2025 21:06:03 GMT, Brent Christian wrote:
>> Kim Barrett has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 11 additional
>> commits
On Fri, 27 Jun 2025 20:57:01 GMT, Brent Christian wrote:
>> Kim Barrett has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 11 additional
>> commits
On Fri, 27 Jun 2025 20:21:07 GMT, Brent Christian wrote:
>> Kim Barrett has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 11 additional
>> commits
On Fri, 27 Jun 2025 18:24:46 GMT, Brent Christian wrote:
>> Kim Barrett has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 11 additional
>> commits
On Wed, 29 Jan 2025 16:36:24 GMT, Shaojin Wen wrote:
> The byte[] allocated in Integer/Long.toString is fully filled, so we can use
> StringConcatHelper::newArray to create byte[] to improve performance.
This pull request has been closed without being integrated.
-
PR: https://git
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.
LATIN1 (byte[]) -> UTF16 (char[]) -> UTF8 (byte[])
And when charset is
> Can I please get a review of this change which proposes to address the issue
> noted in https://bugs.openjdk.org/browse/JDK-8357708?
>
> As noted in the issue, the current code in
> `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a
> `ServiceUnavailableException` even wh
26 matches
Mail list logo
