[Platemail-developer] Re: java and dynamic class loading

[David S. <dg...@ya...>]

--- Neil Campbell <neneilhthebatcaverg.ukukwrote:

> On Tuesday 27 September 2005 01:08, you wrote:
> > Neil,
> >
> > I've been looking at dynamic class loading, and done a little reading.  The
> > mechanics of how to load something by name (ieie> >
> > Class mymyClass Class.foforNamecom.ststoxymyclass;
> >
> > ), however most of these beasts really require the name to be specified.
> > Which, as far as I can see, is really just shuffling deck chairs on the
> > Titanic.  You still need to have a list of class names that you want to
> > load.
> >
> > What I'd ideally like is to find all classes which implement a specific
> > interface.  For example, if there was an interface coconsoleUIthen I'd want
> > to load all of the classes which implement it.  Does this sound possible?
> >
> > Even if that's not possible, it might perhaps be possible to have all of
> > these modules as part of a package:
> >
> > package ukukrg.ththebatcavelplatemailiuionsole.commands;
> >
> > and have it load each class inside this package.  I think that's a pretty
> > shitty idea though.
> >
> > Thoughts?
> 
> Broadly speaking, yes, you can do this sort of thing, however as always it's 
> not quite that simple.  The plan with PlPlatemails, as you suggest, to have 
> all the console commands dynamically loaded, and then essentially have only 
> the very core of PlPlatemails a straightforward app, and the rest of it 
> loaded as various types of plplugin
> 
> The reason you can't just ask which classes implement an interface is that 
> usually the classes won't have been loaded unless you've used them for 
> something else, so you have to load them explicitly.  The way I think this is
> 
> usually done (at least, the way I was planning on doing it) is to have them 
> all in a directory together.  You can then walk this directory and find out 
> the class names and package names and load them that way; to extend it you 
> just need to add more files to the directory.
> 
> You could also have them as jars in the directory, there are some classes for
> 
> dealing with Jar files and you can then bundle some additional classes 
> together easily, and specify a few properties in the Jar's manifest.  
> Essentially though, it's the same idea.
> 
> If you want to get more advanced, you can do things like extending
> ClClassLoader
> and making it do things differently, like by looking in particular places 
> rather than the clclasspathand that sort of thing; and potentially I suppose 
> you could force it to load every class it finds straight away rather than 
> on-demand, and then you could presumably interrogate it, but I don't know too
> 
> much about the ClClassLoadernterface.
> 
> I think it's fairly straightforward to set something up which will go through
> 
> a specified directory and load any 'plpluginclasses that it finds and do 
> something with them though.
> 
> Neil
> 

Having all these files in a ~/.plplatemaillpluginsirectory was where my thought
were heading to, however I have reservations:

1) how does this fit within the package structure?  It seems that moving them
outside of the main source body would require having them as stand-alone units,
rather than being part of a normal java package.

2) are these really modular?  Are there hahardcodedeferences which would
require access to the class files/srsrcn order to statically check+compile
other units?

3) Does this create class veversioningssues?  Could we end up having and older
version of the command used with a newer version of plplatemail

A lot of this depends on really how modular the commands are.  And making them
properly modular means removing *any* non-generic calls to them.  It should be
the case that the module is started by plplatemailhrough a well defined entry
point, and then has the ability to drive the main application.  Something like
this:

1) plplatemailtarts
2) plplatemailcans $PLPLATEMAILRClpluginsloading each class encountered
3) for each class
3.1) call Class.foforNameukukrg...adaddpopaccount.register()
3.2) this will call uiuionsole.adaddCommand, or some other published entry
point into the specific command
4) the console uiuiow has an extra command, which is really just a
hahashmapetween the command name and it's invoke method.  Thus the user types

> adaddpopaccount
which sends a message to the corresponding class's "run" method:

((Command)mymyCommandListind("adaddpopaccount).run();

this method can access (drive) plplatemail This "driving" will include access
calls to whatever I/O is available.

As a side point, I think that each command is really split in two parts; the
conceptual "what it does" and the UIUIhow it talks to the user".  This would
make it easier have differing I/O layers placed on the underlying functionality
available to plplatemail You may already to this actually, I haven't looked.

Now, in essence, I don't think this any of is a good idea.

I don't believe that separating the core ("conceptual") functionality out into
modules is a good idea.  Doing so really limits the interaction between the two
-- this would mean building a rich functionality/APAPIhat the modules could
drive, which I don't believe exists.  It could potentially create a dependency
hell -- if it's possible for one module to rely on another then we instantly
need some type of dependency tracking mechanism to guarantee that modules are
loaded in the correct order and then everything gets complicated.

I think what we really need is what we already have; an answer to the question:
"how to I add an extra command?"

As above, this is really two questions,
1) "how do I add extra functionality (conceptual command)?"
2) "how do I hook this extra functionality into the X uiui (where X:=
{guguionsole})

Now my thinking is that we want to have one specific registration point for the
each place (1 the core functionality, 2 the guguilatform, 3 the console
platform).

What'd you think?

dgs.


		
___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com