Java Generics

[Ben Woodcroft-2]

Hi all,

This is one for the Java coding folks. I'm just wondering what the opinions
are for implementing
generics<http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html>in
the ImageJ code are. Generics only work with Java
1.5+, but since 1.5 is already recommended that is ok?

I would personally find doing things like making an ImageStack a
collection/iterable of ImageProcessors useful, like this:


public class ImageStack<T extends ImageProcessor> implements List<T>{
  public T get(int sliceNum){..}
  ...
}




Then you could do stuff like:

ImageStack<ByteProcessor> stack = new ImageStack<ByteProcessor>();
for(ByteProcessor b : stack){
  //do something only ByteProcessors can do
}


Thanks,
ben

[Jeff Brandenburg]

On Jun 8, 2007, at 2:38 AM, Ben Woodcroft wrote:
> Hi all,
>
> This is one for the Java coding folks. I'm just wondering what the  
> opinions
> are for implementing
> generics<http://java.sun.com/j2se/1.5.0/docs/guide/language/ 
> generics.html>in
> the ImageJ code are. Generics only work with Java
> 1.5+, but since 1.5 is already recommended that is ok?

Well, 1.5 is recommended for Windows, but that's mainly because of a  
terrible Windows-JRE 1.4.2 crashing bug, if I'm not mistaken.

Wayne and the ImageJ community have sacrificed :-) for a number of  
years to maintain JDK 1.1 (!) compatibility, partly for the sake of Mac  
OS pre-X users who are unable to upgrade to JRE 1.2.  In our lab, many  
users are still at OS X 10.3.9, which does not and will never support  
JRE 1.5.

I'm not sure about actual statistics, but there are definitely ImageJ  
users who can't upgrade to JRE 1.5 without spending significant cash  
and/or effort.

People are already writing plugins that require more recent versions of  
Java, and that's fine, but I personally hope the ImageJ core continues  
to support the widest possible user base.
--
        -jeffB (Jeff Brandenburg, Duke Center for In-Vivo Microscopy)

[Ben Woodcroft-2]

Thanks Jeff for that informative answer.

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. But from what you are saying this is a necessary evil.
Sigh.


ben

On 6/8/07, Jeff Brandenburg <[hidden email]> wrote:

>
> On Jun 8, 2007, at 2:38 AM, Ben Woodcroft wrote:
> > Hi all,
> >
> > This is one for the Java coding folks. I'm just wondering what the
> > opinions
> > are for implementing
> > generics<http://java.sun.com/j2se/1.5.0/docs/guide/language/
> > generics.html>in
> > the ImageJ code are. Generics only work with Java
> > 1.5+, but since 1.5 is already recommended that is ok?
>
> Well, 1.5 is recommended for Windows, but that's mainly because of a
> terrible Windows-JRE 1.4.2 crashing bug, if I'm not mistaken.
>
> Wayne and the ImageJ community have sacrificed :-) for a number of
> years to maintain JDK 1.1 (!) compatibility, partly for the sake of Mac
> OS pre-X users who are unable to upgrade to JRE 1.2.  In our lab, many
> users are still at OS X 10.3.9, which does not and will never support
> JRE 1.5.
>
> I'm not sure about actual statistics, but there are definitely ImageJ
> users who can't upgrade to JRE 1.5 without spending significant cash
> and/or effort.
>
> People are already writing plugins that require more recent versions of
> Java, and that's fine, but I personally hope the ImageJ core continues
> to support the widest possible user base.
> --
>         -jeffB (Jeff Brandenburg, Duke Center for In-Vivo Microscopy)
>

[dscho]

Hi,

On Sat, 9 Jun 2007, Ben Woodcroft wrote:

> Thanks Jeff for that informative answer.
>
> 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.

If at all, it has resulted in slower development _only_ for ImageJ. The
plugins do not suffer from the constraints. In fact, I have used some
plugins which cannot run on anything older than 1.5.

So I do not really share your concern.

Ciao,
Dscho

[Dimiter Prodanov]

Hi,

this seems interesting but let's not make the things more complicated
than they should be.
Could you propose a good working example to justify?
My concern is that it will make the code slower and in image processing
speed counts a lot.
Cheers

Dimiter Prodanov

[Adrian Daerr]

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

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

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 ?

best regards,
Adrian

--
http://www.msc.univ-paris-diderot.fr/~daerr/

[dscho]

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

[Adrian Daerr]

> AFAIK Compile and Run works, if you use a newer JDK to run ImageJ.

I am afraid not. The question of how to compile >=1.5 code from within
ImageJ has surfaced several times, the last time it was because of me :-),
see the thread "compiling java 1.5 code" starting 2007-4-16; this thread
contains two nice suggestions by Albert Cardona on how to patch/plugin
ImageJ to replace "Compile and Run" transparently, but some work is
involved. My guess is that the depreciated sun.tools.javac.Main compiler
interface used by ImageJ refuses to compile code >=1.5 to force the
transition to the new interface.

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

That is a very good idea. Hoping that writing the wrapper is not
unreasonably longer that patching the source directly (just a remark,
haven't thought about it at all).

>[on prefering 'write("angle="+atan(sqrt(1+x*x)));' over
>'IJ.write("angle="+Math.atan(Math.sqrt(1+x*x)));']
>
> 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.

OK, it's a matter of taste. But consider this: at least in the early ages
of the macro language (I haven't looked at it for a long time) this was
about the only difference there was between macro-commands and
plugin-Java. Yet people have been pleading with Wayne to re-implement
NIHImage's macro language. I concluded (maybe I am wrong) that users not
comfortable with programming are very sensitive to this kind of scary
details, and readily sacrifice the greater power/flexibility of
Java-plugins.

> That is exactly the reason why I picked up ImageJA,

Thanks for the pointer, I will look at it.

Adrian