On Wed, 18 Jun 2025 00:04:37 GMT, Brian Burkhalter wrote:
> Replaces the implementation `readAllCharsAsString().lines().toList()` with
> reading into a temporary `char` array which is then processed to detect line
> terminators and copy non-terminating characters into strings which are added
>
On Wed, 18 Jun 2025 16:57:22 GMT, Brian Burkhalter wrote:
>> src/java.base/share/classes/java/io/Reader.java line 455:
>>
>>> 453: List lines = new ArrayList();
>>> 454:
>>> 455: StringBuilder sb = new StringBuilder(82);
>>
>> Is there a reason for this pre-allocation? If the w
On Wed, 18 Jun 2025 16:45:33 GMT, Brian Burkhalter wrote:
>> I think we should treat "\r\n" as a single line terminator? for example
>>
>> "hello\r\nworld".lines().forEach(line -> out.format("[%s]\n", line));
>> =>
>> [hello]
>> [world]
>>
>> instead of (the current impl)
>>
>> [hello]
>> []
re-libs-dev on behalf of
Alan Bateman
*Sent:* Monday, 16 June 2025 17:23
*To:* Markus KARG
*Cc:* core-libs-dev
*Subject:* Re: Best Practice for Busy Waiting in Java
On 16/06/2025 12:09, Markus KARG wrote:
>
>
> In case you MUST use busy-wait, apply the following rules:
>
>
> * N
5, 2025 10:42 PM
*To:* Markus KARG ; Archie Cobbs
*Cc:* core-libs-dev
*Subject:* Re: Best Practice for Busy Waiting in Java
Not a concurrency professional, but my first impression is whether to
yield or spin depends on how costly the task you are waiting is - I
know yield involves a conte
6.2025 um 18:40 schrieb Archie Cobbs:
Just MHO...
This is kind of like asking "What's the best way to waste electricity?"
It's a nebulous question until you specify what "best" means in this
odd scenario
-Archie
On Sun, Jun 15, 2025 at 11:09 AM Markus KARG
wrot
Recently I was asked by a programmer, what to do if there simply is no
other way than actually busy-wait.
I see several options:
* Do nothing: Costs valuable CPU time and increases carbon footprint.
* Do a power-nap: Thread.sleep(1)
* Be fair: Thread.yield() gives other threads a chance to ex
Writer was retrofitted to implement Appendable in JDK 5 with the 3-arg
append documented to behave "in exactly the same as ..." the
write(String) method. That's 20 years of subclasses that might be
depending on this behavior. Also 20 years of subclasses that may
depend on the 3-arg append cal
d we shouldn't rush changes in order to
catch up with a release train.
Regards, Chen
*From:* core-libs-dev on behalf of
Markus KARG
*Sent:* Sunday, May 18, 2025 10:09 AM
*To:* core-libs-dev@openjdk.org
*Subject:* R
What is the benefit over the existing replacement methods? Is it easier
to use, uses less resources, runs quicker...?
Am 20.05.2025 um 19:04 schrieb kieran-farrell:
New API to the String.java class - replaceAllMapped(String, Function) that allows regex based replacement via a user defined funct
Paul,
thank you for picking up the topic JSON. I do like the simplicity of
your proposal, OTOH I have concerns:
* Will it it be sustaining?
We added a XML API when XML was "the" big thing, and now it is not a big
thing anymore and we can't get rid of the XML API without breaking
things. So
Sorry, the posting below was cross-posted by accident.
-Markus
Am 18.05.2025 um 17:09 schrieb Markus KARG:
Roger,
thank you for your comments.
Following your advice I have splitted the larger work of JDK-8356679
into sub tasks.
I would like to start with a first PR implementing the
25 6:48 AM, Markus KARG wrote:
Many of the modified classes derive from a common super class and
share one needed common change (which is one of the points which are
easy to see once you see all of those classes in a single PR, but
hard to explain in plaint-text pre-PR mailing list threads), so at
l
On Fri, 9 May 2025 16:41:39 GMT, Roger Riggs wrote:
>> Refactor AbstractStringBuilder to maintain consistency among count, coder,
>> and value buffers while the buffer capacity is being expanded and/or
>> inflated from Latin1 to UTF16 representations.
>> The refactoring pattern is to read and
14/25 6:48 AM, Markus KARG wrote:
Many of the modified classes derive from a common super class and
share one needed common change (which is one of the points which are
easy to see once you see all of those classes in a single PR, but
hard to explain in plaint-text pre-PR mailing list threa
On Fri, 2 May 2025 07:13:21 GMT, Shaojin Wen wrote:
>>> ```java
>>> > char[] ca = new char[end - off];
>>> ```
>>>
>>> Your code here has a memory allocation, which may cause slowdown
>>
>> This is exactly what I wanted to express with my posting.
>
>> > ```java
>> > > char[] ca
On Fri, 16 May 2025 20:00:53 GMT, Roger Riggs wrote:
>> This API is concerned with the "what" and not so much the "how."
>
> The purpose of Reader and subclasses is to normalize characters in various
> forms (char arrays, byte streams, char buffers, etc) into a coherent stream
> of characters a
As the API intentionally uses interfaces to open the ability to optimize
the implementation, it would be also just straightforward to not limit
the text source to the explicit class String. When instead allowing the
general interface CharSequence, *any* kind of text source can be parsed,
for ex
On Thu, 15 May 2025 22:07:05 GMT, Brian Burkhalter wrote:
>> It is **impossible** to "invest some lines" to solve this in JAX-RS, and
>> JAX-RS as a standard technology on tens of thousands of servers. Enforcing
>> `String` prevents these useful optimizations, but brings *no actual
>> benefit*
On Thu, 15 May 2025 10:53:27 GMT, Johannes Döbler wrote:
>> Also, in JAX-RS for example, you cannot make use of `transferTo` as what you
>> get is a heap object, and what you must forward also is a heap object.
>
> Thanks for the examples. Imho I think that performance sensitive, specialised
>
On Thu, 15 May 2025 10:21:26 GMT, Markus KARG wrote:
>>> > Maybe a good idea at this point if @mkarg could provide an example of
>>> > server code benefitting from returning a CharSequence...
>>>
>>> The most simple example is a file server. Incidentia
On Thu, 15 May 2025 06:27:36 GMT, Johannes Döbler wrote:
>> Granted in general, but again, it is not the job of *this particular API* to
>> forbid mutation *iff* the caller and / or producer of the object see a good
>> reason for that. This completely overdesigns the target of *this* API.
>> C
On Wed, 14 May 2025 22:31:46 GMT, Stuart Marks wrote:
>> I know that comment already, but IMHO we can simply use `@implSpec` to
>> unambiguously make clear that this method invokes `read(char[])` to allow
>> optimized implementations, and it *might* in turn invoke
>> `read(char[],int,int)`, bu
On Wed, 14 May 2025 22:19:39 GMT, Stuart Marks wrote:
>> I meant that the implementation of `subSequence` *might or might not*
>> perform copy (so we need to tell the javaDoc reader), while `getChar`
>> *clearly* performs a copy as part of it design. So `subSequence` can be
>> surprising as th
On Wed, 14 May 2025 20:58:47 GMT, Roger Riggs wrote:
>> BTW, paraphrasing Stuart here: "We want to reduce self-calls". `subSequence`
>> is a self-call, *as we do not know* how it behaves in the actual
>> implementation. For `getChars` we can be sure that it has no overridable
>> side effects.
On Wed, 14 May 2025 20:22:02 GMT, Roger Riggs wrote:
>>> Maybe a good idea at this point if @mkarg could provide an example of
>>> server code benefitting from returning a CharSequence...
>>
>> The most simple example is a file server. Incidential fact, just today I
>> wrote a function that si
On Wed, 14 May 2025 20:32:38 GMT, Markus KARG wrote:
>> I have no idea whether `subSequence` is more performant than `getChars` but
>> it seems cleaner. In any case, at this point we are concerned primarily with
>> the APIs getting into JDK 25. We can improve perf
On Wed, 14 May 2025 20:14:21 GMT, Brian Burkhalter wrote:
>> I think this may be a good way to reduce redundant allocation if the
>> CharSequence's subsequence is a simple view (frequently the case for user
>> ones) or a String (for StringBuilder, String)
>
> I have no idea whether `subSequence
On Wed, 14 May 2025 18:16:22 GMT, Brian Burkhalter wrote:
>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8354724: Replace getChars in previous commit with subS
On Wed, 14 May 2025 19:37:57 GMT, Markus KARG wrote:
>> The result should be immutable and CharSequence does not provide that.
>> The contents should not be modifiable after the method returns.
>
> A "pure" `CharSequence` *is* immutable, as it does not have mu
On Wed, 14 May 2025 18:16:08 GMT, Roger Riggs wrote:
>> Maybe a good idea at this point if @mkarg could provide an example of server
>> code benefitting from returning a CharSequence...
>
> The result should be immutable and CharSequence does not provide that.
> The contents should not be modif
On Wed, 14 May 2025 17:52:37 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/io/Reader.java line 500:
>>
>>> 498: * @since 25
>>> 499: */
>>> 500: public String readAllAsString() throws IOException {
>>
>> Still thinking that declaring `CharSequence` instead of `String`
On Wed, 14 May 2025 17:56:04 GMT, Markus KARG wrote:
>> I think this is just a convenience API. A CharSequence-returning API would
>> suit better if it supports arbitrarily long lengths (assuming such a length
>> is in the range of int), while String has implementation
On Wed, 14 May 2025 17:56:44 GMT, Markus KARG wrote:
>> As being a server developer for decades I need to say that I would love to
>> have this not for convenience but for the performance reasons explained
>> above, and that `int` length is perfect to speed up 99,9% of al
On Wed, 14 May 2025 17:42:33 GMT, Stuart Marks wrote:
>>> so that all concrete implementations in this class call only the abstract
>>> three-arg read() method
>>
>> Done in 3cbaede and also `str` -> `cbuf`.
>
> The code should use the three-arg read() call in order to limit self-calls,
> in o
On Tue, 13 May 2025 15:33:39 GMT, Brian Burkhalter wrote:
>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8354724: "stream" -> "reader"
src/java.base/share/cla
On Wed, 14 May 2025 17:01:30 GMT, Stuart Marks wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8354724: "stream" -> "reader"
>
> src/java.base/share/classes/java/io/Reader.java line 403:
>
>> 401: char
ce.
The PR comments become hard to follow and intermingled and it takes
longer to get agreement because of the thrash in the PR.
Roger
On 5/13/25 5:05 AM, Markus KARG wrote:
Thank you, Roger.
Actually the method helps in the "toString()" variants, too, as in
some places we could *g
ing a
(separated allocated) buffer.
Consider taking a few at a time before launching into the whole set.
$.02, Roger
On 5/11/25 2:45 AM, Markus KARG wrote:
Dear Core Libs Team,
I am hereby requesting comments on JDK-8356679.
I would like to invest some time and set up a PR implementing Chen
Dear Core Libs Team,
I am hereby requesting comments on JDK-8356679.
I would like to invest some time and set up a PR implementing Chen
Liangs's proposal laid out in
https://bugs.openjdk.org/browse/JDK-8356679. For your convenience, the
text of that JBS is copied below. According to the Devel
On Mon, 12 May 2025 01:17:15 GMT, Jaikiran Pai wrote:
>> src/java.base/share/classes/java/lang/CharSequence.java line 313:
>>
>>> 311: * at index {@code dstBegin} and ending at index:
>>> 312: * {@code
>>> 313: * dstbegin + (srcEnd-srcBegin) - 1
>>
>> Shouldn't it be dstBegin?
>>
On Sat, 26 Oct 2024 15:48:11 GMT, Markus KARG wrote:
> This Pull Request proposes an implementation for
> [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new
> method `public void getChars(int srcBegin, int srcEnd, char[] dst, int
> dstBegin)` to the `
On Wed, 7 May 2025 12:56:20 GMT, Chen Liang wrote:
> I guess a better approach may be to allow periodical reminders if a thread
> gets no reply - many of us gets quite a few hundred mails every day on
> workdays.
I think it is time to move this discussion into its own thread, but just a last
On Wed, 7 May 2025 10:53:09 GMT, Markus KARG wrote:
> Thank you, Jaikiran! Will this result convince everybody to actively mark
> this PR as officially reviewed, so I can finally integrate it? 😃
@liach For example, you could approve your outdated approval so this PR finally
has to *c
On Wed, 7 May 2025 10:05:12 GMT, Jaikiran Pai wrote:
> tier1 through tier3 testing of this PR passed without issues. The CSR has
> been approved and the changes in this PR look good to me.
Thank you, Jaikiran! Will this result convince everybody to actively mark this
PR as officially reviewed,
On Tue, 6 May 2025 20:52:34 GMT, Markus KARG wrote:
>> This Pull Request proposes an implementation for
>> [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new
>> method `public void getChars(int srcBegin, int srcEnd, char[] dst, int
>> dstBegi
On Tue, 6 May 2025 21:54:59 GMT, Jesper Wilhelmsson
wrote:
> We must remember that the OpenJDK community is built by individuals with
> different backgrounds and motivations to engaging. Some people get paid to
> work on OpenJDK development, others do it in their own time. It would be next
>
ethod signature and JavaDocs are adapted from
> `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as
> these provide sufficient coverage of all changes introduced by this PR.
Markus KARG has updated the pull request with a new tar
On Tue, 6 May 2025 11:23:01 GMT, Markus KARG wrote:
> Hello Markus, it's been a while since this PR was merged with latest master
> branch in mainline. Could you update the PR to do that?
Updated to current `master`. Builds fine locally. Pushed to Github. Github
Actions currently
On Sun, 4 May 2025 16:21:41 GMT, Markus KARG wrote:
>> This Pull Requests proposes an implementation for
>> [JDK-8353795](https://bugs.openjdk.org/browse/JDK-8353795): Adding the new
>> method `public static Writer Writer.of(StringBuilder)`, providing a
>>
On Thu, 1 May 2025 08:45:06 GMT, Markus KARG wrote:
>> This Pull Request proposes an implementation for
>> [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new
>> method `public void getChars(int srcBegin, int srcEnd, char[] dst, int
>> dstBegi
On Sun, 4 May 2025 05:08:46 GMT, Alan Bateman wrote:
>> Oh, and we should set `next` afterwards, so the `Reader` knows that the end
>> of the sequence is reached:
>>
>>
>> public String readAllChars() throws IOException {
>> ensureOpen();
>> var len = cs.length();
>> var remainder
On Tue, 6 May 2025 11:30:09 GMT, Jaikiran Pai wrote:
> > do you mean merging master branch into this branch?
>
> Yes, that's correct. That should then run the GitHub actions job against this
> PR against a more relevant state of this PR.
>
> Since things have settled and the CSR approved, I'll
On Tue, 6 May 2025 02:01:24 GMT, Jaikiran Pai wrote:
> Hello Markus, it's been a while since this PR was merged with latest master
> branch in mainline. Could you update the PR to do that?
As rebasing is not wanted in OpenJDK, do you mean merging `master` branch into
*this* branch?
--
On Tue, 6 May 2025 02:21:20 GMT, Joe Darcy wrote:
>> So it is actually *wanted* behavior that in one situation the text *is*
>> inherited, but at `String.java` no text is inherited at all? 🤔 Could not
>> find any hint about that in the JavaDoc manual.
>
>> So it is actually _wanted_ behavior th
On Sun, 4 May 2025 14:49:35 GMT, Chen Liang wrote:
> ...you can start drafting a CSR like that for `getChars` for `CharSequence`.
Done. Kindly asking your review for the CSR:
https://bugs.openjdk.org/browse/JDK-8356123.
> One concern is that (See `HashMap.newHashMap` vs `HashMap.of`)
> `XxxWr
uilder`.
>
> A basic test is provided to proof that the new `Writer` behaves as expected.
> For comparison, the same test is also run against `StringWriter`.
Markus KARG has updated the pull request incrementally with two additional
commits since the last revision:
- Undone copyr
On Sun, 4 May 2025 14:52:39 GMT, Chen Liang wrote:
>> Markus KARG has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Undone copyright update of otherwise unchanged file.
>> - Update Of.java
>>
On Sat, 5 Apr 2025 17:36:29 GMT, Markus KARG wrote:
> This Pull Requests proposes an implementation for
> [JDK-8353795](https://bugs.openjdk.org/browse/JDK-8353795): Adding the new
> method `public static Writer Writer.of(StringBuilder)`, providing a
> non-synchronized Writer im
On Fri, 2 May 2025 07:13:21 GMT, Shaojin Wen wrote:
> > > ```java
> > > > char[] ca = new char[end - off];
> > > ```
> > > Your code here has a memory allocation, which may cause slowdown
> >
> > This is exactly what I wanted to express with my posting.
>
> I agree with you that this PR
On Wed, 23 Apr 2025 22:04:25 GMT, Brian Burkhalter wrote:
>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8354724: Fix readAllChars gaffe in Reader returned by
On Sat, 3 May 2025 07:25:09 GMT, Markus KARG wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8354724: Fix readAllChars gaffe in Reader returned by Readed.of and
>> account fo
On Wed, 23 Apr 2025 22:04:25 GMT, Brian Burkhalter wrote:
>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8354724: Fix readAllChars gaffe in Reader returned by
On Wed, 23 Apr 2025 22:04:25 GMT, Brian Burkhalter wrote:
>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8354724: Fix readAllChars gaffe in Reader returned by
On Fri, 2 May 2025 03:49:39 GMT, Shaojin Wen wrote:
>> In BufferedReader.readLine and other similar scenarios, we need to use
>> StringBuilder.append(char[]) to build the string.
>>
>> For these scenarios, we can use the intrinsic method StringUTF16.compress
>> and Unsafe.copyMemory instead of
On Mon, 21 Apr 2025 15:19:40 GMT, Chen Liang wrote:
> This might be helpful combined with #21730.
That implies creating a copy of the chars:
private final void appendChars(CharSequence s, int off, int end) {
if (isLatin1()) {
byte[] val = this.value;
// - Begin of Expe
On Thu, 1 May 2025 16:23:13 GMT, Joe Darcy wrote:
>> I can open a bug report, but I think text parity makes no sense: There are
>> lots of other places in OpenJDK where the short form is used already, so
>> there will not be any benefit of text parity with just one other code
>> location, but
On Thu, 1 May 2025 12:56:42 GMT, Chen Liang wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Applied proposal by Daniel: If there's no change to this file the
>> copyright yea
ethod signature and JavaDocs are adapted from
> `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as
> these provide sufficient coverage of all changes introduced by this PR.
Markus KARG has updated the pull request incremental
On Mon, 28 Apr 2025 13:29:06 GMT, Daniel Fuchs wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Applied changes proposed in response to Joe's CSR comments: 'understood
>>
ethod signature and JavaDocs are adapted from
> `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as
> these provide sufficient coverage of all changes introduced by this PR.
Markus KARG has updated the pull request incremental
On Wed, 30 Apr 2025 21:57:07 GMT, Joe Darcy wrote:
>> Unfortunately the same happens. 🙁
>
> The following javadoc for String's getChars method has, I believe, the
> desired effect:
>
>
> /**
> * {@inheritDoc CharSequence}
> * @param srcBegin {@inheritDoc CharSequence}
> * @p
On Wed, 30 Apr 2025 15:47:32 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/String.java line 1739:
>>
>>> 1737:
>>> 1738: /**
>>> 1739: * {@inheritDoc CharSequence}
>>
>> @jaikiran @jddarcy Sorry for bothering, but I do need your kind help here to
>> get the code to
On Wed, 30 Apr 2025 15:33:37 GMT, Markus KARG wrote:
>> This Pull Request proposes an implementation for
>> [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new
>> method `public void getChars(int srcBegin, int srcEnd, char[] dst, int
>> dstBegi
ethod signature and JavaDocs are adapted from
> `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as
> these provide sufficient coverage of all changes introduced by this PR.
Markus KARG has updated the pull request incremental
ethod signature and JavaDocs are adapted from
> `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as
> these provide sufficient coverage of all changes introduced by this PR.
Markus KARG has updated the pull request incremental
On Sun, 23 Mar 2025 10:33:42 GMT, Markus KARG wrote:
>> src/java.base/share/classes/java/nio/X-Buffer.java.template line 2356:
>>
>>> 2354: #end[streamableType]
>>> 2355:
>>> 2356: #if[char]
>>
>> Can we merge this with `// -- Other char st
On Wed, 16 Apr 2025 15:00:20 GMT, Roger Riggs wrote:
>> Yeah, we already added this API to allow implementations to be more
>> consistent under race condition. So for changing char sequences, this
>> method's default implementation can throw IOOBE, but it is already specified
>> so it is well-
On Fri, 18 Apr 2025 06:03:36 GMT, Alan Bateman wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Applied changes requested by Chen and Jaikiran: Unit tests for default
>> implement
ethod signature and JavaDocs are adapted from
> `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as
> these provide sufficient coverage of all changes introduced by this PR.
Markus KARG has updated the pull request incremental
On Wed, 16 Apr 2025 17:04:07 GMT, Jaikiran Pai wrote:
> > IIUC then you will be fine with a test that solely tests the default
> > implementation of CharSequence.getChars()?
>
> Correct. And a similar separate test for `CharBuffer.getChars()` since that
> one too is a new default implementatio
ethod signature and JavaDocs are adapted from
> `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as
> these provide sufficient coverage of all changes introduced by this PR.
Markus KARG has updated the pull request incremental
On Wed, 16 Apr 2025 16:47:33 GMT, Jaikiran Pai wrote:
>It should be possible to just invoke `CharSequence.getChars()` on a
>`CharSequence` instance to verify that its default method does what it
>specifies. So these new tests won't be duplicating any existing test code.
IIUC then you will be f
On Wed, 16 Apr 2025 16:29:23 GMT, Jaikiran Pai wrote:
> > Nevertheless, the tests are there, so no _new_ ones are needed. We can
> > duplicate them, if a majority thinks it is beneficial.
>
> As noted in the contribution guide
> (https://openjdk.org/guide/#testing-the-jdk), regression tests ar
On Wed, 16 Apr 2025 16:08:21 GMT, Jaikiran Pai wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Applied changes requested by Chen: 'We might need to specify the IOOBE
>> behav
On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG wrote:
>> This Pull Request proposes an implementation for
>> [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new
>> method `public void getChars(int srcBegin, int srcEnd, char[] dst, int
>> dstBegi
On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG wrote:
>> This Pull Request proposes an implementation for
>> [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new
>> method `public void getChars(int srcBegin, int srcEnd, char[] dst, int
>> dstBegi
On Tue, 15 Apr 2025 20:46:52 GMT, Roger Riggs wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Applied changes requested by Chen: 'We might need to specify the IOOBE
>> behav
On Tue, 8 Apr 2025 18:12:03 GMT, Chen Liang wrote:
> Should we ask hotspot compiler engineers for inputs on how useful this API is
> for allowing batch/vectorized copy and eliminating overheads of defensive
> copy array allocation?
I have no strong feelings about that.
As it looks like we rea
On Tue, 8 Apr 2025 16:51:06 GMT, Alan Bateman wrote:
> I think the API docs in the latest draft looks okay. It mildly bothers me a
> bit is that getChars is JDK 1.0 API but the trade off with doing a new API is
> that it would need to be implemented by String and SB so I think the proposal
> o
On Sat, 5 Apr 2025 17:36:29 GMT, Markus KARG wrote:
> This Pull Requests proposes an implementation for
> [JDK-8353795](https://bugs.openjdk.org/browse/JDK-8353795): Adding the new
> method `public static Writer Writer.of(StringBuilder)`, providing a
> non-synchronized Writer im
ty is
needed). Also, we don't specify the toString behavior on the returned
Writer (unlike for StringWriter); I think users should just use the
toString on the StringBuilder.
Chen
*From:* core-libs-dev on behalf of
M
On Wed, 26 Mar 2025 11:34:34 GMT, Markus KARG wrote:
>> src/java.base/share/classes/java/lang/CharSequence.java line 307:
>>
>>> 305: /**
>>> 306: * Characters are copied from this sequence into the
>>> 307: * destination character ar
This Pull Requests proposes an implementation for
[JDK-8353795](https://bugs.openjdk.org/browse/JDK-8353795): Adding the new
method `public static Writer Writer.of(StringBuilder)`, providing a
non-synchronized Writer implementation optimized for writing into
`StringBuilder`.
A basic test is pr
On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG wrote:
>> This Pull Request proposes an implementation for
>> [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new
>> method `public void getChars(int srcBegin, int srcEnd, char[] dst, int
>> dstBegi
On Sat, 29 Mar 2025 23:53:36 GMT, Chen Liang wrote:
>> Markus KARG has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - Applied changes requested by Alan: This sentence doesn't make sense, did
>> s
ethod signature and JavaDocs are adapted from
> `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as
> these provide sufficient coverage of all changes introduced by this PR.
Markus KARG has updated the pull request incremental
ethod signature and JavaDocs are adapted from
> `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as
> these provide sufficient coverage of all changes introduced by this PR.
Markus KARG has updated the pull request incrementally
Supporting what Alan said. Would love to see a static factory for a
non-synchronized byte-array backed OutputStream, like
`OutputStream::newByteArrayOutputStream`. John, if you like we can team
up for authoring this, I have free capacity.
Am 29.03.2025 um 09:33 schrieb Alan Bateman:
On 28/03/
On Tue, 25 Mar 2025 13:06:07 GMT, Alan Bateman wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed apiNote and implNote from CharBuffer, as suggested by Chen
>
> src/java
1 - 100 of 411 matches
Mail list logo
