[
https://issues.apache.org/jira/browse/IMAGING-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17289156#comment-17289156
]
Gary Lucas commented on IMAGING-280:
------------------------------------
This is an interesting idea.
Taking a very quick look through the commons imaging source code, I didn't find
anyplace obvious where the alternate constructor could be applied. Do you have
a specific area in mind? Are you thinking of using this in applications
outside the Commons Imaging package itself?
I agree that this would be fairly easy to implement... I think it would
probably take more effort to write the JUnit tests than the code itself.
> Length specifier for ByteSourceArray.
> -------------------------------------
>
> Key: IMAGING-280
> URL: https://issues.apache.org/jira/browse/IMAGING-280
> Project: Commons Imaging
> Issue Type: Improvement
> Reporter: Garret Wilson
> Priority: Major
>
> Many of the library processing methods take a {{ByteSource}}. The
> {{ByteSourceArray}} allows a byte source from an array of bytes, but
> unfortunately it does not allow specification of the number of bytes,
> assuming that the entire byte array is used; e.g.:
> {code:java}
> public ByteSourceArray(final byte[] bytes) {
> this(null, bytes);
> }
> {code}
> This severely impedes the use of the class if the code using
> {{ByteSourceArray}} has a byte array partially filled. The obvious case is
> processing data in a pipeline, when the producer has written to a
> {{ByteArrayOutputStream}}. Although {{ByteArrayOutputStream.toByteArray()}}
> provides a copy of the internal data, it is possible to subclass
> {{ByteArrayOutputStream}} to get access to the underlying bytes to prevent
> copying. Because {{ByteArrayOutputStream}} grows dynamically, the internal
> byte array may not be full.
> Thus {{ByteSourceArray}} needs a separate constructor to indicate the length
> (and even the offset), just like {{ByteArrayInputStream}} does:
> {code:java}
> public ByteArrayInputStream(byte buf[], int offset, int length) {…}
> {code}
> Moreover this is extremely trivial to add. Without it, however, the developer
> is forced to basically reimplement the entire class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
