Force loading of derived classes?

Thread view:

A. W. Dunstan - 26 Jul 2006 20:14 GMT

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.

Signature

Al Dunstan, Software Engineer
OptiMetrics, Inc.
3115 Professional Drive
Ann Arbor, MI 48104-5131

Reply to this Message

AndrewMcDonagh - 26 Jul 2006 20:56 GMT

> I'm developing an application where the user selects an algorithm named
> in a drop-down list, optionally sets parameters, then presses "go". We
[quoted text clipped - 26 lines]
>
> 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').

Reply to this Message

A. W. Dunstan - 27 Jul 2006 16:29 GMT

>> I'm developing an application where the user selects an algorithm named
>> in a drop-down list, optionally sets parameters, then presses "go". We
[quoted text clipped - 49 lines]
> 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!

Signature

Al Dunstan, Software Engineer
OptiMetrics, Inc.
3115 Professional Drive
Ann Arbor, MI 48104-5131

Reply to this Message

Chris Uppal - 27 Jul 2006 09:04 GMT

> 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

Reply to this Message

Patricia Shanahan - 27 Jul 2006 22:01 GMT

> I'm developing an application where the user selects an algorithm named
> in a drop-down list, optionally sets parameters, then presses "go". We
[quoted text clipped - 5 lines]
> 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

Reply to this Message

A. W. Dunstan - 27 Jul 2006 22:16 GMT

>> I'm developing an application where the user selects an algorithm named
>> in a drop-down list, optionally sets parameters, then presses "go". We
[quoted text clipped - 12 lines]
>
> 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.

Signature

Al Dunstan, Software Engineer
OptiMetrics, Inc.
3115 Professional Drive
Ann Arbor, MI 48104-5131

Reply to this Message

Patricia Shanahan - 27 Jul 2006 22:41 GMT

>>> I'm developing an application where the user selects an algorithm named
>>> in a drop-down list, optionally sets parameters, then presses "go". We
[quoted text clipped - 17 lines]
> 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

Reply to this Message

Lasse Reichstein Nielsen - 27 Jul 2006 22:31 GMT

> 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

Signature

Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Reply to this Message

Force loading of derived classes?

Free Magazines