[
https://issues.apache.org/jira/browse/IMAGING-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17289604#comment-17289604
]
Garret Wilson commented on IMAGING-280:
---------------------------------------
{quote}Taking a very quick look through the commons imaging source code, I
didn't find anyplace obvious where the alternate constructor could be
applied.{quote}
Your library doesn't necessarily have cases where it needs that constructor to
provide a {{ByteSource}}, because it's the developer who will normally be
supplying the bytes.
{quote}Are you thinking of using this in applications outside the Commons
Imaging package itself?{quote}
Exactly. Your library _requests_ a {{ByteSource}}; that is, you request the
_caller_ to provide one when they process images (e.g.
{{ExifRewriter.updateExifMetadataLossy(byteSource, outputStream,
tiffOutputSet)}}). You want to make it flexible for the developer to supply
the bytes in whatever form they have them. You don't want to force the
developer to copy huge arrays just to because your {{ByteSourceArray}} doesn't
provide a way to specify a portion of an existing buffer.
See the internal {{BufByteSource}} class inside
[{{BaseImageMummifier}}|https://bitbucket.org/globalmentor/guise/src/master/mummy/src/main/java/io/guise/mummy/mummify/image/BaseImageMummifier.java]
as an example. Note the class API comment referring to this ticket.
> 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)
