This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.

Message:

Hmm...

Posted by Bill Venners on 21 Dec 1998, 1:59 AM

> Boy was I surprised when I checked JavaWorld's frontpage the
> other day. I had just spent a couple of days fiddling with
> dynamic class loading and, more importantly, dynamic class
> *ditching*.

> I am programming a multi-user game server in Java. This is indeed
> one of those 24/7 applications your article mentioned -- in fact,
> after we've gone live, we don't intend to ever reboot.

> One of the instruments to achieve this goal is a modular design.
> We'll have a static kernel that does little more than module
> management, and every other functionality will be in the
> NetworkModule, the WorldModule, the CommandModule, the
> ParserModule, the DatabaseModule, etc -- all of which can be
> loaded and unloaded at runtime. Thus class loading and ditching.

> I wish the modules to reside in a base dir, let's call it
> 'modules/'. Each module would then have its own package under
> that dir. So the NetworkModule's fully qualified name would be
> 'network.NetworkModule' and the file would be in
> 'modules/network/NetworkModule.class'.

> When I load the modules from the server, I cast them all to their
> superclass 'Module', which defines the interface for basic
> operations such as loading/unloading/report status/etc. Here
> (finally) comes my problem:

> The file Module.class is in package 'core'. I need it when I
> compile my modules, since they all extend the abstract Module
> super class. My modules are of necessity moved out of my
> classpath (thus a custom class loader similar, but not identical
> (mine supports loading from a class from a DB too), to your
> 'holeloader') so I can't simply say
> 'class NetworkModule extends core.Module' or likewise.

> I also need it in my core package (the kernel) for obvious
> reasons. Any good solutions to this problem? There are ugly
> workarounds, like constructing a script that copies
> core/Module.java to modules/ and strips out the line
> 'package core;', but those are just that: ugly workarounds, and I'd
> rather avoid them.

> This message is probably a bit lengthier than most postings in
> these forums, and I apologize for that. There may be a simple
> solution to my problem (I haven't really looked at it since last
> night) but this also gives me a reason to flaunt my scheme in
> public for an experienced audience that may see flaws that I have
> overlooked.

I'm not sure I see a problem. Your network.NetworkModule
should just extend core.Module, seems to me. If Module is
the common supertype you are going to use to manipulate all
your modules, then it will probably be loaded by the
boot class loader (the class loader formerly known as
primordial) - i.e., core.Module will be in the class path.
All you need to do is make the class loader you load
network.NetworkModule with check with the boot class
loader first before looking in the "hole."

One pain I have had when testing class loader stuff
is that I have to compile on the class path, then move
.class files off the class path to test. Otherwise my
boot loader will find it and load it. I believe this should
be fixable by a command line parameter to javac, but as I
recall I wasn't able to get it to work on Windows with
JDK 1.1. If you have a make file, check the
documentation on javac (or whatever compiler you are using)
to see if you can't specify a class path for each compile.
That would save you from moving files.

You mustn't change the package of Module, by the way, or you
won't be able to manipulate your NetworkModule from your
kernel. It must stay core.Module and loaded by the boot
class loader.

bv

• Thank ya Emil Eifrem 21 Dec 1998, 3:32 PM (0)