On Sun, May 9, 2010 at 6:58 PM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
On Sun, May 9, 2010 at 11:45 AM, Alessio Stalla alessiostalla@gmail.com wrote:
On Tue, Apr 27, 2010 at 8:54 AM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
On Tue, Apr 27, 2010 at 2:48 AM, Alessio Stalla alessiostalla@gmail.com wrote:
IIRC, I should have a local patch to make JCLASS use another classloader if you pass it to it, including in CLOS method specializers, as in (defmethod foo ((x (jclass "foo" *my-classloader*))) ...)
If that sounds sensible to you, I can adapt it to the current version of abcl and commit it, so it can be tested.
Let's give it a shot.
I finally committed the patch on trunk.
Tested, works. Thanks.
So what do you think about actually integrating the bean shell class loader into ABCL. Source is at
http://ikayzo.org/svn/beanshell (root) http://ikayzo.org/svn/beanshell/BeanShell/src/bsh/classpath (classloader) http://ikayzo.org/svn/beanshell/BeanShell/src/bsh/BshClassManager.java (classmanager)
I've been using it for about 5 years and it's pretty useful, allowing dynamic modifications to the classpath, including jars as part of asdf systems, etc.
The addUrl method to dynamically add new resources to the classpath is very nice and easy to add. I'm less convinced by the other stuff, which subverts the normal classloading semantics: the bsh classloader reloads all classes from the classpath, except the core BeanShell classes, instead of delegating to the parent classloader first. I fear this may cause bugs and/or inefficiencies in the context of ABCL, and even without those concerns I see little value in adding it. Do you actually use this feature? And if yes, what for?
Also, if we expose the classloader to the user and allow him to modify the classpath, we must make sure that said classloader is used in all the relevant places. I'd prefer to postpone that to after version 0.20 is released, to avoid the risk of inadvertently introducing subtle bugs in 0.20.
Just my .02, Alessio