Re: JDK-8067661: transferTo proposal for Appendable

Just to see if I picked up the Discussion so far. The discussion is about that original sentence from: http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.03 "Depending on which class implements the appendable, there may be a limit of data that can written to which in turn could lead to a

Re: JDK-8067661: transferTo proposal for Appendable

On Nov 15, 2017, at 3:22 AM, Alan Bateman wrote: > "If the destination is capacity bounded and has insufficient capacity to > append all characters read from the source then the exception may be thrown > after transferring some characters to the destination". Could “is capacity-bounded and” be

Re: JDK-8067661: transferTo proposal for Appendable

On 14/11/2017 16:59, Patrick Reinhart wrote: : And what should it be then here? I’m a bit confused now… Sorry, there was a typo in my mail that Brian picked up on. I think we are converging on: "If the destination is capacity bounded and has insufficient capacity to append all characters

Re: JDK-8067661: transferTo proposal for Appendable

> Am 14.11.2017 um 16:33 schrieb Brian Burkhalter : > > > On Nov 14, 2017, at 3:45 AM, Alan Bateman > wrote: > >> - Readable "hence unspecified". In several other places, including >> InputStream.transferTo, we use "therefore unspecified" and it would be good

Re: JDK-8067661: transferTo proposal for Appendable

On Nov 14, 2017, at 3:45 AM, Alan Bateman wrote: > - Readable "hence unspecified". In several other places, including > InputStream.transferTo, we use "therefore unspecified" and it would be good > to keep that consistent. Mea culpa on the “hence.” > - Readable "Depending on which class impl

Re: JDK-8067661: transferTo proposal for Appendable

On 14/11/2017 07:51, Patrick Reinhart wrote: Hi Brian See latest changes here: http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.03 This version mostly looks quite good, a few comments: - Readable "hence unspecified". In several other places, including InputStream.transferTo, we u

Re: JDK-8067661: transferTo proposal for Appendable

Hi Brian See latest changes here: http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.03 -Patrick > Am 14.11.2017 um 01:34 schrieb Brian Burkhalter : > > Hi Patrick, > > More editorial comments ... ;-) > No problem :-) > In Readable.java these lines > > 73 * Depending on wh

Re: JDK-8067661: transferTo proposal for Appendable

Hi Patrick, More editorial comments ... ;-) In Readable.java these lines 73 * Depending on which class implements the appendable, there may be a limit 74 * of data that can written to which in turn could lead to an exception. are a bit unclear to me. Do you mean to say a limit o

Re: JDK-8067661: transferTo proposal for Appendable

Latest changes: http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.03 -Patrick > Am 13.11.2017 um 15:35 schrieb Roger Riggs : > > Hi Patrick, > > Comments on http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.02: > > Readable.java: > 74: „to an error" is a bit overloaded, p

Re: JDK-8067661: transferTo proposal for Appendable

Hi Patrick, Comments on http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.02: Readable.java: 74: "to an error" is a bit overloaded, perhaps "to an exception" X-Buffer.java.template: 1567: "this buffer":  do you mean the "out buffer" 1578:  "The out buffer is this buffer": will read

Re: JDK-8067661: transferTo proposal for Appendable

An updated webrev: http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.01 > A few comments: > > Readable.java: > 67: + it may be worth mentioning that the input might not fit in output (as > seen in the CharBuffer case) > Though I see we didn’t call that out in the other transferTo d

Re: JDK-8067661: transferTo proposal for Appendable

Hi Patrick, A few comments: Readable.java:  67: + it may be worth mentioning that the input might not fit in output (as seen in the CharBuffer case) Though I see we didn't call that out in the other transferTo description but here it is more likely that the output is bounded. 77: "The total

Re: JDK-8067661: transferTo proposal for Appendable

Finally did some review with Alan and integrated all into this webrev: http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.01 -Patrick > Am 08.11.2017 um 00:03 schrieb Brian Burkhalter : > > Hi Patrick, > > On Nov 7, 201

Re: JDK-8067661: transferTo proposal for Appendable

Hi Patrick, On Nov 7, 2017, at 3:01 PM, Patrick Reinhart wrote: > I integrated your changes into my current version which I will look into > tomorrow with Alan at Devoxx. I think adding some implementation note on the > default method implementation will be needed to review later on… I concur

Re: JDK-8067661: transferTo proposal for Appendable

Hi Brian, I integrated your changes into my current version which I will look into tomorrow with Alan at Devoxx. I think adding some implementation note on the default method implementation will be needed to review later on… I also made an override on the CharBuffer, where we need to add a enha

Re: JDK-8067661: transferTo proposal for Appendable

I am a little late to this thread, but some alternative verbiage to consider is included below. This wording however diverges from that of [1] so if we want them to remain similar then it’s probably not worth it to change from what has been agreed upon already. Thanks, Brian [1] https://docs

Re: JDK-8067661: transferTo proposal for Appendable

Hi Alan, I will have a version ready at Devoxx next week ;-) -Patrick > Am 03.11.2017 um 13:49 schrieb Alan Bateman : > > On 02/11/2017 19:55, Patrick Reinhart wrote: >> : >> If we are all happy with the API so far, I could start adding an initial >> implementation and test… >> > I think the

Re: JDK-8067661: transferTo proposal for Appendable

On 02/11/2017 19:55, Patrick Reinhart wrote: : If we are all happy with the API so far, I could start adding an initial implementation and test… I think the API looks fine so go ahead. -Alan

Re: JDK-8067661: transferTo proposal for Appendable

Hi Alan, > Am 02.11.2017 um 20:34 schrieb Alan Bateman : > > On 02/11/2017 18:36, Patrick Reinhart wrote: >> : >> That would read then something like this: >> >> * Reads all characters from this readable and writes the characters to >> * the given appendable in the order that they are read. On

Re: JDK-8067661: transferTo proposal for Appendable

On 02/11/2017 18:36, Patrick Reinhart wrote: : That would read then something like this: * Reads all characters from this readable and writes the characters to * the given appendable in the order that they are read. On return, the * source of characters will be at its end. Yes, or even "R

Re: JDK-8067661: transferTo proposal for Appendable

Hi Alan, The latest version is here: http://cr.openjdk.java.net/~reinhapa/reviews/8067661/signature > Am 02.11.2017 um 14:52 schrieb Alan Bateman : > > On 01/11/2017 14:57, Patrick Reinhart wrote: >> I tried to put that in my latest proposal: >> >> /** >> * Reads all characters from this rea

Re: JDK-8067661: transferTo proposal for Appendable

On 01/11/2017 14:57, Patrick Reinhart wrote: I tried to put that in my latest proposal: /**  * Reads all characters from this readable and writes the characters to  * the given appendable in the order that they are read. On return, this  * readable will be at end its data. You might want to t

Re: JDK-8067661: transferTo proposal for Appendable

I tried to put that in my latest proposal: /**  * Reads all characters from this readable and writes the characters to  * the given appendable in the order that they are read. On return, this  * readable will be at end its data.  *  * This method may block indefinitely reading from the readable,

Re: JDK-8067661: transferTo proposal for Appendable

On 16/12/2014 22:54, Pavel Rappo wrote: Hi Patrick, nice to hear from you again! I agree we should consider adding this method. Unfortunately, from the spec point of view I suppose this one will require a lot more chewing. For instance there's nothing that can be closed either in Readable or Appe

Re: JDK-8067661: transferTo proposal for Appendable

I found around 30 usages of copy all data from a reader to an appendable or writer like this within the jdk itself:   StringBuilder sb = new StringBuilder(); // appendable   char[] buf = new char[1024];   int n;   while ((n = reader.read(buf)) >= 0) {   sb.append(buf, 0, n);   } or   Writer

Re: JDK-8067661: transferTo proposal for Appendable

Hi Patrick, Sounds like a good idea to me. Do you have any suggestions for concrete implementations that may benefit from specialized implementations? As a 'push' API, an implementation will necessarily have to allocate a buffer and read characters and then append them to the appendable.  I

JDK-8067661: transferTo proposal for Appendable

Hi There, Based on the *transferTo* Method on the InputStream I would propose to introduce a default method on the Readable interface. In that way the method can be used for all existing implementations of Readable and still be implemented in a special way by a individual implementer.    /**   

Re: JDK-8067661: transferTo proposal for Appendable

Hi Pavel, > Hi Patrick, nice to hear from you again! I agree we should consider adding > this > method. Unfortunately, from the spec point of view I suppose this one will > require a lot more chewing. For instance there's nothing that can be closed > either in Readable or Appendable (in general c

Re: JDK-8067661: transferTo proposal for Appendable

Hi Patrick, nice to hear from you again! I agree we should consider adding this method. Unfortunately, from the spec point of view I suppose this one will require a lot more chewing. For instance there's nothing that can be closed either in Readable or Appendable (in general case), since neither of

JDK-8067661: transferTo proposal for Appendable

Hi Chris & Pavel, Based on the transferTo Method on the InputStream I would propose to introduce a default method on the Readable interface. In that way the method can be used for all existing implementations of Readable and still be implemented in a special way by a individual implementer.