[ImageJ-devel] ThreadContextClassLoader Article

[Curtis Rueden]

Hi Dscho,

Why not use the URLClassLoader directly? You might want to subclass it to
> access the addURL() method, but it should be plenty enough.
>

Right, I was thinking about that. The cool thing about JCL is that
supposedly it can unload classes without needing to create a new class
loader every time. Maybe it's not such a big deal, though.

BTW what is the status on sezpos? Is there a compelling example yet,
> showing that it can be integrated into the compilation easily, and that
> the annotations can be read without hassle (and without actually loading
> the class)?
>

Soon! Yesterday and today we rearranged the ImageJ2 project modules in the
SVN repository. The new layout is:

1) ij1-bridge: Code containing "compatibility layer" between IJ2 and IJ1.
This project contains the ImgLibProcessor extension of ImageProcessor, for
example, that allows us to wrap an imglib Image as an ImagePlus. Classes in
this project start with package prefix "imagej.ij1."

2) ij1-patches: Code overriding vanilla IJ1 classes. This project is
intended to be a temporary place where we put changes to the ImageJ1 core
classes (i.e., classes of package "ij."). We had made quite a few changes to
the core ImageJ classes before when we were pursuing the "delegation"
development plan, and we are now going through and backing them out whenever
possible. However, sometimes changes to core ImageJ1 will be needed. The
idea is to absolutely minimize them, and when we need a change, to place it
in ij1-patches.jar on the classpath before the stock ij.jar. That way our
modified classes take precedence. Then we can discuss why we needed each
change with Wayne and others, and work together to integrate the changes
into the main IJ1 codebase as needed.

3) imagej2: Code defining the new ImageJ2 architecture and user interface.
After feedback from the conference, it seems clear that people (particularly
Wayne) want an alpha release as soon as possible. Hence, we are creating a
minimal ImageJ2 project that replicates the existing IJ1 user interface and
functionality, according to the adaptation development plan I outlined in my
talk. I am referring to this as the "bootstrapping" phase of the project.
Once we have the minimal IJ2 alpha in place, we can begin to make iterative
changes. Also, this project will be renamed back to "imagej" from "imagej2"
once the bootstrapping is complete.

4) imagej: This project contains the previous ImageJ2 code, with many
changes to the ij.* packages, and is what was demoed at the conference. It
is now obsolete, as we migrate various portions of the code into the other
projects mentioned above.

So, regarding SezPoz, as part of #3, we need to have an updated plugin
loading mechanism. Step 1 is to lift ImageJ1's mechanism wholesale. Step 2
is to add SezPoz and/or NetBeans Lookup to show how they would benefit the
plugin discovery process. I will send another update once that is working
(hopefully within 1-3 weeks).

Please let us know if anything described above is unclear, and I can
clarify.

-Curtis

On Wed, Nov 10, 2010 at 3:37 PM, Johannes Schindelin <
Johannes.Schindelin at gmx.de> wrote:

> Hi,
>
> On Wed, 10 Nov 2010, Curtis Rueden wrote:
>
> > Out of curiosity, does anyone here have experience using JarClassLoader
> > (JCL)? On first glance it looks like it might be able to solve the class
> > reloading issue.
> >   http://jcloader.sourceforge.net/index.html
>
> Why not use the URLClassLoader directly? You might want to subclass it to
> access the addURL() method, but it should be plenty enough.
>
> BTW what is the status on sezpos? Is there a compelling example yet,
> showing that it can be integrated into the compilation easily, and that
> the annotations can be read without hassle (and without actually loading
> the class)?
>
> Ciao,
> Johannes
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20101110/afcc44f5/attachment.html>