[ImageJ-devel] [fiji-devel] Imglib2: using threadpools in core algorithms

[Johannes Schindelin]

Hi Tobi,

On Fri, 6 Dec 2013, Tobias Pietzsch wrote:

> As far as I see it, a big part of scijava-common is to be a dependency
> injection framework.

That is just part of it, but yes, it is a part.

> It can provide an application context, it can harvest annotations from
> my classes, it can even modify my eclipse projects.

It can add a file to your Eclipse project that works around an incorrect
interpretation of the Java specification, yes: annotation processing is
only performed correctly by Eclipse if you add that file.

> This is exactly the right thing to use if you are building an
> application.

And if you are building extensible frameworks with extension points, such
as: segmentation and tracking plugins for TrackMate, feature plugins for
the Trainable Segmentation, generic extensions for TrakEM2, commands for
the 3D Viewer, and yes, also operations for scijava-ops.

Extensibility is something that a lot of projects related to Fiji had to
reinvent due to lack of a base library providing a common extensibility
framework.

With scijava-common, there is no more need to do so.

I have to admit that it gets hard for me to accept that we are contesting
about reusability here. Reusable classes in a library that weighs in with
a whopping two hundred kilobytes.

If you insist on not having such a dependency in imglib2-core, fine, I
cannot change your mind, I can only point out that imglib2-core will have
to reinvent at least a large part of scijava-common's functionality, one
by one, and as ImgLib2 will be used for the most part in projects that
already rely at least transitively on scijava-common (including your own
big data viewer), that will be a true duplication.

I rest my case because there is nothing else I can do, really.
Dscho