commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruno P. Kinoshita" <>
Subject Re: [imaging] IMAGING-154 remove Debug class
Date Tue, 06 Feb 2018 09:52:16 GMT
Hi Jorg,

I'd be fine with that solution too. I think this one would cause the smaller change to the
code as is.

I believe my preference is still to remove the Debug class. But between logging and making
Debug internal only, I'd choose making it internal.

Looking forward to hearing what others think about these options.


From: Jörg Schaible <>
Sent: Tuesday, 6 February 2018 9:24 PM
Subject: Re: [imaging] IMAGING-154 remove Debug class

Hi Bruno,

if it might also be helpful to our users, why not keep and provide it. As 

I understand it, the Debug class is a tool helping in development to 

analyze some behavior.

Nothing stops us from declaring this class internal (we might even put it 

into a package "internal" or "debug") that might be changed without 

further comment. Nobody may rely on it in production code, but during 

development it might be helpful. With such an approach we might not have 

a need to find a better interface to provide this functionality.

Just my 2¢,


Am Mon, 05 Feb 2018 12:20:58 +0000 schrieb Bruno P. Kinoshita:

> Hello,


> If memory serves me well, some time ago we had a discussion around

> sanselan & commons-imaging 1.0. One of the issues with commons-imaging

> 1.0 was the Debug class.




> I finished the pull request, but Gilles raised an important point, about

> discussing other alternatives first.


> Initially I am against logging in low level libraries, especially

> commons components. But some time ago I had to debug TIFF issues in

> commons-imaging, and having the dump methods was a tremendous help.



> The issue is that some imaging algorithms/processing have a lot of

> variables that can be altered. And keeping an eye on all of them in the

> debugger can be quite hard - though not impossible.


> So all in all, now I am more confident to proceed without the Debug

> class. But some users could have a hard time investigating possible

> issues in the library without seeing what's going on within the library.


> IMO, that could be solved with the logging/dump features... or through a

> better design, especially around exception handling/throwing. The latter

> is my preferred approach. Instead of logging, I prefer - whenever

> possible - that low level libraries throw exceptions and let me handle

> the logging.



> So, any thoughts? :) I'm +1 to remove the Debug class, and +0 to a

> logging added to commons-imaging.


> Bruno


To unsubscribe, e-mail:

For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message