Previous Message | Next Message Previous in Topic | Next in Topic Previous by Same Author | Next by Same Author Previous Page (September 2000) | Back to Main IMAGEJ Page
	Reply | Post a New Message | Join or Leave IMAGEJ, or Change Options | Search
	Chronologically | Most Recent First | Wrap Text (Proportional Font) | Don't Wrap Text (Non-proportional Font)

Content-Type: text/plain; charset="us-ascii"
Message-ID:  <v04011701b5f000c73f76@[137.187.230.154]>
Date:         Thu, 21 Sep 2000 12:29:06 -0700
Reply-To:     ImageJ Interest Group <[log in to unmask]>
Sender:       ImageJ Interest Group <[log in to unmask]>
From:         Wayne Rasband <[log in to unmask]>
Subject:      Re: Interface,parameters...
In-Reply-To:  <[log in to unmask]>

>Dear Wayne,
>   I am a new user of ImageJ, and I am trying to understand your program's
>structure and logic before I can utilize your wonderful program. I have some
>questions to ask, please help me if you have time.
>
>   In method runUserPlugin(), there are some code like the following:
>
>      thePlugin = (loader.loadClass(className)).newInstance();
>      if(thePlugin instance of Plugin)
>         ((Plugin)thePlugin).run(arg);
>          ..................
>
>   1). According to the source code of class PluginClassLoad (I downloaded
>       your v.118), there should be 2 parameters instead of just one in the
>              loadClass(Sting name, boolean resolve)
>       method, and you don't have any override method for this one. One
>       parameter is missing, how does it work?

I don't claim to understand how ImageJ's custom class loader works but it
appears that runUserPlugin is calling the one parameter version of
loadClass in the superclass and that method is calling the two parameter
version in PluginClassLoader. ImageJ's PluginClassLoader is a slightly
modified version of the FileClassLoader from "The Java Class Libraries:
Second Edition, Vol. 1". ImageJ uses a custom class loader so the "Compile
and Run" command can replace previously loaded classes and to eliminate the
need to have the plugins folder to the class path.

>   2). Plugin is defined as an interface, it  has one abstract method run().
>       Many classes implements this Plugin interface, such as class DICOM.
>       As a class, DICOM extends from ImagePlus and implements Plugin,
>       (loader.loadClass(className)) will return a class c, if the className
>       is "ij.plugin.DICOM", the returned c should be DICOM.class, when it is
>       new by newInstance() we will have an instance of class DICOM,then how
>       does the JVM knows that it should be a subclass of ImagePlus or an
>       implementor of Plugin (maybe both) when your call
>                 if(thePlugin instance of Plugin)?

A plugin that extends ImagePlus is both a PlugIn and an ImagePlus. ImageJ
can determine what a plugin extends or implements by using the instanceof
operator.

>   3). Another question related with 2) is (sorry I am new for Java also):
>       when you call loadit(calssname) in PluginClassLoader, the very last
>       statement is :
>          return defineClass(classname, buf, buf.length);
>       here the classname is something like "ij.plugin.DICOM", how does the
>       compiler match it with "DICOM"? In other words, statement
>          loader.loadClass(className)
>       will return ij.plugin.DICOM or DICOM?

It returns a Class object. ImageJ then calls that object's newInstance()
method to create an instance of of that class (an object) and use the
instanceof operator to verify that the object is a plugin.

-wayne

Center for Information Technology National Institutes of Health Bethesda, Maryland 20892 301 594 6248 (v) 301 496 8294 (TDD) Comments and Assistance Accessibility