Force loading of derived classes?

[A. W. Dunstan]

I'm developing an application where the user selects an algorithm named
in a drop-down list, optionally sets parameters, then presses "go". We
then do stuff with the results of running the algorithm, but that has
no bearing on my question.

Each algorithm is embodied in a class, where each of these classes is
derived from an abstract base class. At present, the GUI drop-down
list knows about all available algorithms at compile time, which seems
ugly.

I thought that if the base class could keep a static map of <algorithm
name, exemplar> then the GUI could iterate over the names to build the
drop-down. Hard-coding that information in the base class wouldn't be
much better than hard-coding it in the GUI, but if the map is static
and is built as the classes are loaded then I wouldn't have that
worry.

This would have worked, were it not for the fact that the GUI gets
constructed before the algorithm classes are even loaded, leaving me
with a null map. I've got a static getter method in the base class
where I can check for a null map, but until the derived classes are at
least loaded it does me no good.

Any suggestions on how to force class loading when you don't know in
advance what those classes are? I know they'll be public and derived
from my base class, but not much else.

Or is there a better way of solving this problem?

Thanks.

 

[AndrewMcDonagh]

I'm developing an application where the user selects an algorithm named
in a drop-down list, optionally sets parameters, then presses "go". We
then do stuff with the results of running the algorithm, but that has
no bearing on my question.

Each algorithm is embodied in a class, where each of these classes is
derived from an abstract base class. At present, the GUI drop-down
list knows about all available algorithms at compile time, which seems
ugly.

I thought that if the base class could keep a static map of <algorithm
name, exemplar> then the GUI could iterate over the names to build the
drop-down. Hard-coding that information in the base class wouldn't be
much better than hard-coding it in the GUI, but if the map is static
and is built as the classes are loaded then I wouldn't have that
worry.

This would have worked, were it not for the fact that the GUI gets
constructed before the algorithm classes are even loaded, leaving me
with a null map. I've got a static getter method in the base class
where I can check for a null map, but until the derived classes are at
least loaded it does me no good.

Any suggestions on how to force class loading when you don't know in
advance what those classes are? I know they'll be public and derived
from my base class, but not much else.

Or is there a better way of solving this problem?

Thanks.

Its not class loading you need, its Reflection.

With Reflection you can create an instance of a class using the String
name of the class.

e.g:

try {
Class cls = Class.forName("com.myorg.mypackage");

MyAbstractClass abc = cls.newInstance();

myDropDown.add(abc);

} catch (Throwable e) {
//...
}


The package and Class names can be loaded from a resource file at runtime.

This is essentially how those Inversion of Control frameworks work.
(Google 'java Spring').

 

[Chris Uppal]

Any suggestions on how to force class loading when you don't know in
advance what those classes are? I know they'll be public and derived
from my base class, but not much else.

Do it the other way around. /Start/ with a list of the classes; that list
could be hardcoded into your code (not a good long-term solution); explicitly
written out as a file somewhere; or implicit as in "all the files in <some
directory>" or "all the classes matching XXX in <some jar>". Then use
reflection to load the desired class(es).

-- chris

 

[A. W. Dunstan]

Its not class loading you need, its Reflection.

With Reflection you can create an instance of a class using the String
name of the class.

e.g:

try {
Class cls = Class.forName("com.myorg.mypackage");

MyAbstractClass abc = cls.newInstance();

myDropDown.add(abc);

} catch (Throwable e) {
//...
}


The package and Class names can be loaded from a resource file at runtime.

This is essentially how those Inversion of Control frameworks work.
(Google 'java Spring').

Both this and Chris Uppal's suggestion would work, but it seems to me that
they're both variations on what I've got now. Somewhere, there's still a
hardcoded list of which classes to use. Granted, using reflection and a
resource file means I don't have to recompile anything but I still have to
remember a) that I have to put an entry in a resource file, and b) where IS
that file, anyway? The way my memory works, anything that happened before
breakfast is ancient history :-}

If I knew that all classes would be loaded before any code was executed I'd
be all set, but the existence of the ability to do reflection makes that
impossible.

I tried forcing a load of the base class, but that does nothing to the
derived classes. I suppose if I put my class files into a jar file I could
do a wildcard search for com.myorg.mypackage.*, drop anything with a $ in
the name & force a load of what was left. I'd still have to get the name
& path to the jar file, but that might not be insurmountable. Hmmmm...

I guess I'm stuck with hardcoding something somewhere.

Thanks!

 

[Patricia Shanahan]

I'm developing an application where the user selects an algorithm named
in a drop-down list, optionally sets parameters, then presses "go". We
then do stuff with the results of running the algorithm, but that has
no bearing on my question.

Each algorithm is embodied in a class, where each of these classes is
derived from an abstract base class. At present, the GUI drop-down
list knows about all available algorithms at compile time, which seems
ugly.

In addition to whatever you decide to do about automatically discovering
classes, would it make sense to change the GUI to allow a typed-in
algorithm name? Do your users extend the program by adding algorithms,
or only choose from the ones you supply?

Patricia

 

[A. W. Dunstan]

In addition to whatever you decide to do about automatically discovering
classes, would it make sense to change the GUI to allow a typed-in
algorithm name? Do your users extend the program by adding algorithms,
or only choose from the ones you supply?

Patricia

Only ones we supply. Each algorithm will have it's own set of parameters
which they can fiddle with, tho'. I've currently got things set up so each
algorithm provides a JPanel with suitable editing fields; one algorithm has
no parameters, the rest have some parameters in common, but not all. When
you select the algorithm, the appropriate JPanel is displayed.

 

[Lasse Reichstein Nielsen]

Each algorithm is embodied in a class, where each of these classes is
derived from an abstract base class. At present, the GUI drop-down
list knows about all available algorithms at compile time, which seems
ugly. ....
Any suggestions on how to force class loading when you don't know in
advance what those classes are?

The only way to do that is to find the classes, which means traversing
the classpath yourself and loading everything on it (or at least looking
at each class file to see if it should be loaded).
That's probably not the best way to discover which classes exist.

I know they'll be public and derived from my base class, but not
much else.

I would probably make a utility (using xdoclet or perhaps an
annotation processor) that run through the java files and find the
appropriate classes and build a list. That list can then be included
with the program in some way and loaded at runtime, perhaps as a
property file.

If the user should be able to add his own algorithms, and perhaps even
if it shouldn't, then I would use the list to create a service
provider configuration file and add it to the jar file. That way, the
user can make his own jar files to provide his own service classes.
<URL:http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Service Provider>

Good luck
/L

 

[Patricia Shanahan]

Only ones we supply. Each algorithm will have it's own set of parameters
which they can fiddle with, tho'. I've currently got things set up so each
algorithm provides a JPanel with suitable editing fields; one algorithm has
no parameters, the rest have some parameters in common, but not all. When
you select the algorithm, the appropriate JPanel is displayed.

In that case, you have a lot of control. Put the key classes in a
package of their own, and as part of your "make" process search the
corresponding directory for .java files.

Patricia