Bugs item #993090, was opened at 2004-07-18 10:45 Message generated for change (Comment added) made by brett_s_r You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=993090&group_id=22866
Category: Javassist Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Brett Randall (brett_s_r) Assigned to: Shigeru Chiba (chiba) Summary: Loader#findClass should throw ClassNotFoundException Initial Comment: A normal part of the contract of ClassLoader#findClass is that it should throw ClassNotFoundException if there is a problem locating the Class to be loaded. javassist.Loader#findClass does not throw this Exception, which prevents subclasses from throwing it. It also silently catches all Exception-s rather than throwing ClassNotFoundException. Proposed patch attached. ---------------------------------------------------------------------- >Comment By: Brett Randall (brett_s_r) Date: 2004-07-21 20:01 Message: Logged In: YES user_id=561698 I had overlooked that findClass was silently catching NotFoundException and returning null for delegation to the parent ClassLoader. This should definitely continue. The way I came across this issue is that I needed to subclass javassist.reflect.Loader in a way that instruments classes very late, with the class modification taking place entirely within the ClassLoader. This makes it more likely that Exceptions such as CannotCompileException will be thrown within the ClassLoader. The current behaviour of Loader is to silently catch cases of failed class instrumentation, and return a class loaded from the parent ClassLoader. I think I would prefer a ClassNotFoundException to be thrown if either of the other two checked Exceptions (IOException or CannotCompileException) are thrown. I am submitting a new patch that silently catches NotFoundException, but wraps the other Exceptions in a ClassNotFoundException. Also attached is a demonstrating jUnit test (see last test). ---------------------------------------------------------------------- Comment By: Brett Randall (brett_s_r) Date: 2004-07-20 08:35 Message: Logged In: YES user_id=561698 I have just revisited the code and I think I may have a more appropriate change, which I will write-up and post this evening. Thanks. ---------------------------------------------------------------------- Comment By: Shigeru Chiba (chiba) Date: 2004-07-19 23:55 Message: Logged In: YES user_id=388745 Yes, the normal contract of ClassLoader#findClass requires a subclass to throw a ClassNotFoundException. However, Javassist has already broken the contract of ClassLoader#loadClass on purpose! That is, javassist.Loader overrides loadClass although it is not recommended by the contract of ClassLoader. So, in javassist.Loader, it is not an exception or a problem that the loader cannot find a class. This is why it returns null in that case. Yes, I can modify the findClass as you recommend. However, that would be a (very small) performance penalty since loadClass will frequently catch an exception thrown by findClass. Maybe, javassist.Loader#findClass should return null if it cannot find a class but throw an exception if it gets some problem (i.e. I/O error). What do you think of this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=993090&group_id=22866 ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
