+1
On 5/8/2017 9:54 PM, Brian Burkhalter wrote:
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
