[armedbear-devel] expecting to find integer on stack

[Alessio Stalla]

On Mon, May 10, 2010 at 2:05 AM, Alan Ruttenberg
<alanruttenberg at gmail.com> wrote:
> I've used the ability to add resources to the classpath explicitly.
> Via use of ClassManager I may have used the other inadvertently. I've
> never looked deeply at what happens behind the scenes. What I can say
> is that I've rarely had any issue with jss over the years I've used it
> within ABCL.

>From a quick read of ClassManager, it seems to me it's mostly a thin
layer over a classloader, which can optionally swap another
classloader in to "reload" classes at will (as well as doing other
stuff to support BeanShell itself). I think it can be a useful
addition, but I'd keep the two things conceptually separate if
possible: have a generic classloader with dynamic classpath and
another, "greedy" classloader that will always load resources from its
own jars first, which can be used to "reload" (or better, load
different versions of) classes in a jar or set of jars. The two might
actually be a single class with a boolean switch: my point is that
they should be clearly distinguishable so the user can ultimately
decide what to do.

> If you think you can preserve the desired add-to-classpath behavior
> with less mechanism, then I'm game to give it a try.

It's possible, with the caveat that adding a new jar which contains a
class that has already been loaded from somewhere else (in the same
classloader chain) won't make the classloader use the new class. In
other words, the classpath is only partially dynamic (a given class
will see a static snapshot the time it is loaded). That's true for the
bsh classloader as well, as far as I understand, except the bsh one
will always ignore classes in the system classpath (the one specified
at startup) and always load them from the jars it knows.
Using "greedy" classloaders and layering them will enable to load
multiple versions of a class. But as I said, I'd keep the two things
separate. It would also be nice to have the "greedy" classloader
optionally use a Lisp function predicate to decide whether to be
greedy or not on a per-class basis.

Hope this makes sense,
Alessio