Hi all, I just spotted that in jakarta.el.ImportHandler#findClass there is a cl.getResource(path) == null (similar code exists when there is a security manager). One line later there is a clazz = cl.loadClass(name);.
I assume the intent is to check the class is physically accessible but I have a few questions about that: 1. It seems it does not respect the classloader API since this one enables by contract to define a class (loadclass) without having a resource - it is often used by proxies for ex, 2. getResource is insanely slow (dropping it by using a subclass which overrides ImportHandler by reflection I got a x10 ops/s on a 4 lines template with one import) 3. Why would getResource fail but loadClass succeed - I ignore any configuration error which is "fixable"? >From the comment on top of the getResource check it seems it is for performances (getresource being cheaper than loadClass) but I wonder if it is still accurate (from my window it depends on the classpath size plus loadClass will mainly go through getResource). So overall I wonder if this check can be dropped now we have concurrent classloaders and cache almost everywhere. If not, should the missed items be cached in some (webapp) classloader to help to exit faster? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance>
