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
