http://imagej.273.s1.nabble.com/parallel-iterative-deconvolution-tp5004620p5004750.html
> Hi Aryeh,
>
> On Sat, 7 Sep 2013, Aryeh Weiss wrote:
>
>> On 9/4/13 9:17 PM, Johannes Schindelin wrote:
>> >
>> > On Sun, 1 Sep 2013, Aryeh Weiss wrote:
>> >
>> > > java.lang.NoSuchMethodError:
>> > > cern.colt.Sorting.parallelQuickSort([IIILcern/colt/function/tint/IntComparator;)V
>> > > at cern.colt.matrix.tfloat.algo.FloatSorting.runSort(Unknown Source)
>> > > at cern.colt.matrix.tfloat.algo.FloatSorting.sortIndex(Unknown Source)
>> > > at ... [more stuff that I will send if needed]
>> > >
>> > > This type of error was discussed in the past, most recently (which I
>> > > found):
>> > >
https://list.nih.gov/cgi-bin/wa.exe?A2=ind1105&L=IMAGEJ&P=R35667&1=IMAGEJ&9=A&J=on&d=No+Match%3BMatch%3BMatches&z=4>> > >
>> > > The problem then was outdated parallelcolt in the load path. So I
>> > > purged my system of all of the old parallelcolt jars, and made sure
>> > > I have only parallelcolt-0.9.4, which I believe is the latest.
>> >
>> > The problem is that parallelcolt is developed in a slightly
>> > backwards-incompatible manner. That, combined with the fact that
>> > parallel iterative convolution dependended on a different (and
>> > incompatible) version of parallelcolt than superresolution prevented
>> > the inclusion of those otherwise very interesting plugins into Fiji.
>> >
>> > In your case, it might also be one of those creative .jar files that
>> > bundle other projects which leads to all kinds of unpleasant
>> > surprises.
>> >
>> > To find out what .jar file contains the offending Sorting class, use
>> > Fiji's 'Find Jar For Class' script via the command launcher and
>> > provide the full class name: cern.colt.Sorting
>> >
>>
>> I found the class in colocalization-pipeline and in colt-1.2.0.jar
>>
>> I uninstalled colocalization-pipeline and disabled (for now)
>> colt-1.2.0.jar (I renamed it to colt-1.2.0.jar-dist).
>>
>> This allows parallel iterative deconvolution to run, but I do not think
>> that it is a good long term solution, because the updater "wants" to
>> restore colt, and I prefer to keep the standard distribution of
>> automatically updated files.
>
> I agree, but I can only repeat my suggestion to Piotr to make sure that
> parallelcolt stays backwards-compatible and if that is not possible, at
> least to make all of the plugins depending on parallelcolt compatible with
> the newest version of the latter.
>
> Theoretically, colt should be completely superseded by parallelcolt. But
> colt, too. Piotr is really the best person to ask: Piotr, any insights?