Posted by
dscho on
Jun 13, 2007; 2:09pm
URL: http://imagej.273.s1.nabble.com/Java-Generics-tp3699132p3699134.html
Hi,
On Wed, 13 Jun 2007, Adrian Daerr wrote:
> > On Sat, 9 Jun 2007, Ben Woodcroft wrote:
> >> 1.1 compatibility is quite impressive I must say. I guess the price
> paid for backwards compatibility is a slower development time for
> plugin writers, especially new ones.
>
> Johannes Schindelin replied:
> > If at all, it has resulted in slower development _only_ for ImageJ. The
> plugins do not suffer from the constraints.
>
> Well, indirectly yes. The source code of plugins itself is indeed not
> restricted to old language versions (although you lose the possibility to
> "Compile and Run" from within ImageJ if you want newer language features);
AFAIK Compile and Run works, if you use a newer JDK to run ImageJ.
> but plugins are not self-contained, they rely heavily on ImageJ's objects
> and methods, and ImageJ's structures and interfaces could be much more
> intuitive to use (by plugin-writers) if they took advantage of newer Java
> features. That was actually the main point of Ben's initial posting.
Okay, that is a good point.
I'd suggest to start writing a wrapper using generics, if only to prove
that it really enhances plugin writing. This wrapper could live as a .jar
file first, and if it proves popular, could even be folded into a Java5
version of ImageJ.
> IMHO Ben is right when he says that plugin-writing could faster and more
> intuitive (especially for newcomers) with Generics, Enumerations, static
> includes (who would not favor
> write("angle="+atan(sqrt(1+x*x)));
> over
> IJ.write("angle="+Math.atan(Math.sqrt(1+x*x)));
> ) et caetera.
Sorry, I don't. There is a lot I really, really like about Java5. But it's
not these shortcuts which make it easy to get confused with methods of the
current class.
> And, to answer Dimiter Prodanov's concerns about code speed, these
> features, if the change anything at all, may even augment the execution
> speed (in Ben's example, the internal Iterable implementation can be more
> efficient than hand-made loops, and is in any case unlikely to be worse).
As far as I know, these Iterables are only checked at compile time.
> But as Ben says, the loss of elegance and simplicity is probably the price
> to pay for being able to run on old machines (which as Jeff argues, is an
> important objective).
It is. But then, ImageJ is moving on. For example, Java 1.4 is required
now, since we support the mouse wheel in image windows.
> This said, it might be worth considering the creation of a development
> branch of ImageJ. This could be used as playing ground by interested
> programmers, and be cannibalized by Wayne whenever interesting ideas are
> worth integrating into the original ImageJ. Personnally, I see a couple of
> small bugs I'd try to correct straight away if it were as easy as a call
> to bzr/darcs/svn/cvs/whatever, editing, and committing the patch.
> Does anybody care to share her/his opinion on this ?
That is exactly the reason why I picked up ImageJA, not as a way to fork
ImageJ, but to have a playground for wild ideas. It has a CVS repository,
and indeed a whole sourceforge project on
http://sourceforge.net/projects/imageja. It even acquired a fresh Git
repository on
http://repo.or.cz/w/imageja.git last week.
I cannot speak _for_ Wayne, but I spoke _to_ Wayne about feeding patches,
and I had the impression that small changes (probably best fed by
providing a complete source .zip file) are the most appreciated way for
such modifications.
Ciao,
Dscho