I agree. I would opt for (A) and be done with it. On May 8, 2017, at 6:38 PM, Brian Goetz <[email protected]> wrote:
> Given that this went unnoticed for 18 years, the urgency seems low. Either > (a) or (b) sound fine to me. (c) sounds like a recipe for spending more time > talking about the bug than actually fixing it. > > > >> On May 8, 2017, at 5:24 PM, Brian Burkhalter <[email protected]> >> wrote: >> >> This issue [1] does in fact appear to be a bug. It could be fixed in one of >> three ways: >> >> A) Remove the fallacious sentence "The size of this buffer may be specified, >> but by default it is large enough for most purposes.” from the second >> paragraph of the class documentation. This would at least make the >> specification consistent with the behavior without removing any >> functionality and could be done for JDK 9. >> >> B) Add constructors (and the supporting methods in sun.nio.cs.CtreamEncoder) >> which would permit specifying the buffer size. This would make the behavior >> consistent with the specification but would have to be targeted to JDK 10. >> >> C) Do option A for JDK 9 and (possibly) file an enhancement issue for option >> B for JDK 10. >> >> Any opinions as to which option would be preferable? >> >> Another possibility would be to have some kind of “setBufferSize()” >> capability which I think would add less API but ultimately more code. >> >> Thanks, >> >> Brian >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8179662 >
