Github user srowen commented on the pull request:
https://github.com/apache/spark/pull/397#issuecomment-40285054
Sure, I myself was not suggesting that we should make them throw
exceptions. If one really wanted to prohibit their use, that would be a way to
do so even when subclassing, but I don't suggest they must be prohibited.
To me, the methods aren't broken or anything, and the resulting class can
be reused for the purpose @rxin has in mind in this PR, if these methods are
available.
Agree that the max size of such a buffer could be configurable. However the
limit can't be more than `Integer.MAX_VALUE` just because this is the largest
an array can be . I was just pointing this out in regard to `var newCapacity:
Int = oldCapacity << 1` which will fail if `oldCapacity` is more than half of
`Integer.MAX_VALUE` already.
(There's another tangent here about whether the buffer class should even
enforce a limit -- what does it do, fail with `IOException`? -- because the
caller has to manage it either way.)
The gist of my strawman suggestion is: what if we had a simple subclass of
`ByteArrayOutputStream` that exposes a `ByteBuffer`? I argue that is a basis
for removing some long-standing array copies in various parts of the code,
which is @rxin's purpose. And then I think it suits your purpose too, excepting
the compaction logic, but I was wondering about whether it is needed. (Maybe I
should take this to the JIRA issue you opened about your work?)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
