Posted by
Joris FA Meys on
Mar 10, 2009; 4:40pm
URL: http://imagej.273.s1.nabble.com/Some-thoughts-about-ImageJ-tp3693353p3693362.html
Hi all,
I'm fairly new to programming in Java and in the world of ImageJ, so please
keep that in mind while reading my comments.
On Tue, Mar 10, 2009 at 3:35 PM, Johannes Schindelin <
[hidden email]> wrote:
> Hi,
>
> On Tue, 10 Mar 2009, Joachim Wesner wrote:
>
> > One thing that should/could be adressed when "refactoring" ImageJ
> > would/could/SHOULD be the way the FFT or FHT routines are integrated
> > into the "kernel".
>
> This is getting too detailed for me. We are losing focus.
I agree on that one. As I understood, the point was to restructure ImageJ to
the latest insights and possibilities in programming in general, and Java
programming specifically. Which is an effort I personally encourage. It
would also enhance the applicability of ij classes and methods in other
applications. It is definitely possible now, and the documentation on the
use is very good as far as I'm concerned, but standardization would always
be nice.
>
>
> The real issue is, after all: due to historical reasons, ImageJ uses
> neither Java5 niceties, nor does it have a completely orthogonal API
> (meaning that GUI, data structures and algorithms are not separated from
> each other).
I would like to remark that quite some plugins drive on Java5 niceties like
object arrays and stuff. But then again, quite some of these more advanced
data structures slow down the calculations quite a bit. I have more
experience with this in Perl (e.g. nested hashes are a killer for your
runtime) , but in Java, it's as important, if not more as far as I know.
>
>
> The question is: how can we keep the convenience for existing users, as
> well as get the changes in that are needed to move ImageJ forward from the
> technical side?
This might be a pragmatic point of view, but it's impossible to do these
changes without breaking any code. Heck, my little plugin behaved already
drastically different depending on which version of the ij.jar I use in
Eclipse. But nothing keeps people from using a working version of the old
ImageJ to run the old plugins.
Popular plugins will only have to be updated where they use the classes from
the ij.jar. If they're built in a convenient way, much of the original code
will work anyway. If the rewriting of ImageJ does not alter the Plugin,
PluginFilter and PluginFrame interface, there's a good chance that quite
some plugins will still work.
>
>
> Oh, and FWIW I think it would be wrong to move the discussion away from
> the ImageJ list, unless you absolutely want to lose contact with the
> users...
That's a good point. But for carrying out the project, the users wouldn't
mind missing all the technical details. So those groups can definitely be
very useful.
Well, I'm not a great programmer, but I do know my way around Java by now
and I would be happy to contribute to this great idea.
And in the meantime, I would like to thank Wayne again for all the
marvellous work he did already, and the enormous help he is for the user
community. ImageJ as it is now, is an enormously great achievement.
Kind regards
Joris