On 22/08/2022 10:20, Romain Manni-Bucau wrote:
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,
Do we need to worry about proxies for this use case?
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)
See TesterImportHandlerPerformance. Previous results were 2 orders of
magnitude the other way.
3. Why would getResource fail but loadClass succeed - I ignore any
configuration error which is "fixable"?
From memory this trick failed when used under a SecurityManager with
classes that had circular dependencies. I might not have the details
quite right but there wasn't anything wrong with the classes or the
application.
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).
A quick test with TesterImportHandlerPerformance and Java 11 suggests
there performance benefits are a lot smaller.
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?
We need to test with various JDKs but if the results are comparable to
those for Java 11, I'd have no objection to simplifying the code.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
