Re: Antwort: Re: Some thoughts about ImageJ ...

Posted by Burger Wilhelm on Mar 10, 2009; 5:43pm
URL: http://imagej.273.s1.nabble.com/Some-thoughts-about-ImageJ-tp3693353p3693363.html

To be clear (before switching to the other list), the issue goes far
beyond the goal of using recent Java features. While these make some
things easier, safer and more elegant, the real task is to build on
proven general architectural models that existed long before Java 5.
This is not just for fun or because computing people want to
re-implement tools all the time using the current language of fashion -
in the contrary. I am very pragmatic about this (no mad computing freak)
and I would not have raised the issue if I did not experience that the
current deficits really are a limiting factor to ImageJ's future
development. I also have seen a lot of inefficient and fragile code in
contributed plugins and I believe this is partly due to the current API.

Also, I definitely have no objection against scripting languages (being
an ex-LISP person myself) - they are great for quick prototyping but
they do not lend themselves to building large, complex systems that are
modular and safe. I would even argue that the multitude of available
scripting options - though very convenient for the individual scipter -
is not supportive of code sharing in general.

Off now to the other list...

Wilhelm

> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On
> Behalf Of joris meys
> Sent: Tuesday, March 10, 2009 5:40 PM
> To: [hidden email]
> Subject: Re: Antwort: Re: Some thoughts about ImageJ ...
>
> 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
>