http://confer09.condor-edv.com/nice@freenode/2005-04-06.html
When there is a Nice library (in a separate library.jar
that can't be modified), and the program defines a
multi-method on a class from that library, then it
depends on ClassLoader whether the modified library
class will be seen or not. If ClassLoader checks
library.jar first, then the original class, without new
multi-method, is loaded, and NoSuchMethodError
exception is thrown at runtime. This problem is even
worse for dynamically-compiled Nice packages, where
application build process can't be modified, class
loading order is predefined and more: the modified
class is already loaded and used by the JVM.
This problem is currently actual for package-visible
multi-methods also...
Logged In: YES
user_id=289741
The current CVS HEAD mitigates this problem to a tolerable
extent
by generating (if i understand correctly) non-package
methods into
the package dispatch.
Thus i will lover the priority of this bug.
The bug should be still present for overriden non-package
methods.
Logged In: YES
user_id=289741
See also
http://cvs.sourceforge.net/viewcvs.py/nice/Nice/testsuite/compiler/overloading/dynamic.nice?view=auto