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 11:01:36 GMT, Markus KARG wrote:
>> Thanks for the examples. Imho I think that performance sensitive,
>> specialised code can invest some lines to put together the best solution for
>> the context whereas the majority of code can simply use a convenient
>> `reader.readAllAs
On Thu, 15 May 2025 10:22:51 GMT, Markus KARG wrote:
>> If the source is a `Reader` **and** target is a `Writer`, yes. But what if
>> it is a native piece of hardware, like an IoT device, which produces /
>> consumes `CharSequence`?
>
> Also, in JAX-RS for example, you cannot make use of `trans
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. Incidential fact, just today I
>>> wrote a function
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 20:52:00 GMT, Markus KARG wrote:
>> There's nothing in the CharSequence interface that requires or indicates
>> that the implementation is or is not immutable. Interfaces only have loosely
>> defined contracts, only the signature of the methods, the caller can not
>> hold a
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 17:53:48 GMT, Markus KARG wrote:
>> The code should use the three-arg read() call in order to limit self-calls,
>> in order to avoid the fragile base class problem. At some point we might
>> want to add implSpec tags to specify this. See my previous comments relate
>> to th
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 19:41:30 GMT, Markus KARG wrote:
>> A "pure" `CharSequence` *is* immutable, as it does not have mutation
>> methods. Also, why *should* the result be immutable? If someone wants to
>> return a `StringBuilder` for example (for whatever intent), why shouldn't he
>> allowed to
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 mutation methods.
> Also, why *should
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 limits on lengths
>> and
On Wed, 14 May 2025 18:09:26 GMT, Johannes Döbler wrote:
>> BTW, it will *already* throw OOME as-is, *because* it returns a `String`
>> even if the Reader is attached to an infinite source.
>
> Maybe a good idea at this point if @mkarg could provide an example of server
> code benefitting from
On Wed, 14 May 2025 17:32:50 GMT, Markus KARG 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 205:
>
>> 203: p
On Wed, 14 May 2025 17:57:36 GMT, Markus KARG wrote:
>> BTW, it will not fail with OOME, but it should throw IOE in that case.
>
> BTW, it will *already* throw OOME as-is, *because* it returns a `String` even
> if the Reader is attached to an infinite source.
Maybe a good idea at this point if
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 all cases. So
>> we shou
On Wed, 14 May 2025 17:41:12 GMT, Markus KARG 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 500:
>
>> 498: * @since
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 Wed, 14 May 2025 17:40:53 GMT, Brian Burkhalter wrote:
>> All other self-calls to a `read` method are to the three-arg abstract method:
>>
>> $ grep read( src/java.base/share/classes/java/io/Reader.java | grep -v
>> public | grep -v *
>> nread = this.read(cbuf, off, rem);
>>
On Wed, 14 May 2025 17:25:00 GMT, Markus KARG wrote:
>> src/java.base/share/classes/java/io/Reader.java line 403:
>>
>>> 401: char[] str = new char[TRANSFER_BUFFER_SIZE];
>>> 402: int n;
>>> 403: while ((n = read(str)) != -1) {
>>
>> I'd suggest changing this call to `th
On Wed, 14 May 2025 17:39:05 GMT, Brian Burkhalter wrote:
>> I think `read(str)` is to be preferred over `read(str, 0, str.length()` as
>> it allows implementations to provide optimized implementations. What the
>> caller of the new methods wants to achieve is getting everything in the best
>>
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
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
> 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"
-
Changes:
- all: https://git.openjdk.org/jdk/pull/24728/files
- new: https:
28 matches
Mail list logo
