Back to contributing to Commons Imaging

[Damjan Jovanovic <da...@apache.org>]

Hi

I am back to contributing to Commons Imaging.

Will start with some cleanups, like try-with-resources instead of
IoUtils.closeQuietly().

Java and Maven are a heaven send after working in C++ and make with Apache
OpenOffice.

Regards
Damjan

Re: Back to contributing to Commons Imaging

[sebb <se...@gmail.com>]

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
<am...@itextpdf.com> wrote:
> Op 03-09-16 om 15:29 schreef sebb:
>>
>> On 3 September 2016 at 13:14, Benedikt Ritter <br...@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.vangasse@itextpdf.com
> http://itextpdf.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Back to contributing to Commons Imaging

[Amedee Van Gasse <am...@itextpdf.com>]

Op 03-09-16 om 15:29 schreef sebb:
> On 3 September 2016 at 13:14, Benedikt Ritter <br...@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.vangasse@itextpdf.com
http://itextpdf.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Back to contributing to Commons Imaging

[sebb <se...@gmail.com>]

On 3 September 2016 at 17:38, Benedikt Ritter <be...@gmail.com> wrote:
> sebb <se...@gmail.com> schrieb am Sa., 3. Sep. 2016 um 15:29 Uhr:
>
>> On 3 September 2016 at 13:14, Benedikt Ritter <br...@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?
>>
>
> Could you elaborate some more how that would like? If users have to create
> the wrapper object they would still have the reference to the byte array
> passed to the wrapper.

Yes, they would have the reference to the byte array, unless it was
copied by the wrapper.

But even if it was not copied, at least the array would not be exposed
elsewhere in the code.

This makes it much easier to debug.

>
>>
>> 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
>> >
>> > Damjan Jovanovic <da...@apache.org> schrieb am Sa., 3. Sep. 2016 um
>> 11:42:
>> >
>> >> Hi
>> >>
>> >> I am back to contributing to Commons Imaging.
>> >>
>> >> Will start with some cleanups, like try-with-resources instead of
>> >> IoUtils.closeQuietly().
>> >>
>> >> Java and Maven are a heaven send after working in C++ and make with
>> Apache
>> >> OpenOffice.
>> >>
>> >> Regards
>> >> Damjan
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Back to contributing to Commons Imaging

[Vikrant Nimbalkar <vi...@gmail.com>]

Can anyone pls tell me what to work on. I am new to this and started with
programming in java..there are just so many things to pick.help would be
appreciated..

Thanks and Regards
Vikrantraje

On Sep 3, 2016 22:08, "Benedikt Ritter" <be...@gmail.com> wrote:

sebb <se...@gmail.com> schrieb am Sa., 3. Sep. 2016 um 15:29 Uhr:

> On 3 September 2016 at 13:14, Benedikt Ritter <br...@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?
>

Could you elaborate some more how that would like? If users have to create
the wrapper object they would still have the reference to the byte array
passed to the wrapper.


>
> 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
> >
> > Damjan Jovanovic <da...@apache.org> schrieb am Sa., 3. Sep. 2016 um
> 11:42:
> >
> >> Hi
> >>
> >> I am back to contributing to Commons Imaging.
> >>
> >> Will start with some cleanups, like try-with-resources instead of
> >> IoUtils.closeQuietly().
> >>
> >> Java and Maven are a heaven send after working in C++ and make with
> Apache
> >> OpenOffice.
> >>
> >> Regards
> >> Damjan
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: Back to contributing to Commons Imaging

[Benedikt Ritter <be...@gmail.com>]

sebb <se...@gmail.com> schrieb am Sa., 3. Sep. 2016 um 15:29 Uhr:

> On 3 September 2016 at 13:14, Benedikt Ritter <br...@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?
>

Could you elaborate some more how that would like? If users have to create
the wrapper object they would still have the reference to the byte array
passed to the wrapper.


>
> 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
> >
> > Damjan Jovanovic <da...@apache.org> schrieb am Sa., 3. Sep. 2016 um
> 11:42:
> >
> >> Hi
> >>
> >> I am back to contributing to Commons Imaging.
> >>
> >> Will start with some cleanups, like try-with-resources instead of
> >> IoUtils.closeQuietly().
> >>
> >> Java and Maven are a heaven send after working in C++ and make with
> Apache
> >> OpenOffice.
> >>
> >> Regards
> >> Damjan
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: Back to contributing to Commons Imaging

[sebb <se...@gmail.com>]

On 3 September 2016 at 13:14, Benedikt Ritter <br...@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
>
> Damjan Jovanovic <da...@apache.org> schrieb am Sa., 3. Sep. 2016 um 11:42:
>
>> Hi
>>
>> I am back to contributing to Commons Imaging.
>>
>> Will start with some cleanups, like try-with-resources instead of
>> IoUtils.closeQuietly().
>>
>> Java and Maven are a heaven send after working in C++ and make with Apache
>> OpenOffice.
>>
>> Regards
>> Damjan
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Back to contributing to Commons Imaging

[Benedikt Ritter <br...@apache.org>]

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...

Regards,
Benedikt

Damjan Jovanovic <da...@apache.org> schrieb am Sa., 3. Sep. 2016 um 11:42:

> Hi
>
> I am back to contributing to Commons Imaging.
>
> Will start with some cleanups, like try-with-resources instead of
> IoUtils.closeQuietly().
>
> Java and Maven are a heaven send after working in C++ and make with Apache
> OpenOffice.
>
> Regards
> Damjan
>