It looks as though the byte[] arrays are often converted into a ByteArrayInputStream. If not, then the other common use-case is an indexed read.
Encapsulating the byte[] data in a class that gives access to these might be a solution. Likewise for int[] and other data. On 6 September 2016 at 07:47, Amedee Van Gasse <amedee.vanga...@itextpdf.com> wrote: > Op 03-09-16 om 15:29 schreef sebb: >> >> On 3 September 2016 at 13:14, Benedikt Ritter <brit...@apache.org> wrote: >>> >>> Hi Damjan, >>> >>> nice you're back. I think there is only one thing left before 1.0 can ne >>> released and that is the findbugs violations. They are mainly about >>> exposure of internal state because the public API accepts byte arrays as >>> input parameter. An easy way to fix this would be to copy the arrays. But >>> I >>> think that would be very bad for Performance... >> >> >> On the other hand, if the existing API is kept, it's not going to be >> possible to easily change the design without breaking compatibility. >> >> The more internal state is exposed, the harder it is to change code in >> the future. >> And the harder it is to fully test the code. >> >> I've not looked at the code recently, but would it be possible to wrap >> the byte array in an object, and only provide access via methods? >> >> It would be fairly easy to replace individual entry reads and writes >> with getters and setters, but that might be too expensive for some >> operations. >> Depending on how many other such operations there are it might be >> possible to provide other methods for them. >> >>> Regards, >>> Benedikt > > > As an actual user of Commons Imaging, I'd like to chime in and say: make > those changes and break compatibility now. > > -- > Amedee Van Gasse > QA Engineer | iText Software BVBA > amedee.vanga...@itextpdf.com > http://itextpdf.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
