Looking at the latest patch, I now see the restriction that the cache is only used if the packages being searched are the default list. I also see the new addition that only stores in the cache if the classloader used is the same as that of the SolrResourceLoader (to prevent bleed over from one core to another).
But honestly: the whole idea of tricks like this seems overly risky to me considering how easy it is to get into "classloader hell" with java.
Does anyone have any profiling info they can share showing that this patch actually improves performance in any particular usecases? (without adversely affecting it in the common use cases)
Even if the package searching behavior of SolrResourceLoader really is that expensive, then I'd rather encourage people to stop using the solr.* aliasing and start explicitly using FQN for classes. I can't imagine Class.findClass on an already initialized classname is measurably slower then pulling a class instance out of this cache.
(The short names were designed just to make the example configs easier to read, but if people in high load environments where cores are added/removed all the time find the package alias resolution to be prohibitively expensive on core initialization, then just don't use that that syntactic feature)
If someone has numbers showing that the cache really is faster even when specifying FQNs in the configs, then I'd be convinced, but otherwise ..... ugh, ... it just seems like a bad idea to go down this road.