[rules-dev] Rules compilation and unnecessary attempts to getResourceAsStream()

Hi Guys, First of all, congrats for the 5.3 release! I was having a look at the recent improvements done to rules compilation, mentioned here<http://docs.jboss.org/drools/release/5.3.0.Final/droolsjbpm-intro...;, and I unfortunately couldn't really realize a 3 times faster compilation :( After some profiling, my problem seems to come from some unsuccessful attempts to getResourceAsStream done at org.drools.commons.jci.compilers.EclipseJavaCompiler. Basically on line 218, to be able to know if something is a type or not, it will get a supposedly class name and try to load it, if it cannot be loaded then it will infer that what it thought was a class was actually a package. Here goes a call stack, to give some context. In this particular case, the string parameter was "com.sample.org", thus not a type. EclipseJavaCompiler$2.findType(String) line: 220 On the same lines, method isPackage on line 285, will try to load a "class name" and if it can't be found it will assume it was actually a package name and return true. Again, an illustrative call stack: Turns out that getting a resource when it does not exist can be pretty expensive if you're compiling rules inside a big application with a lot of stuff on your classpath, and this approach ends up tying the compilation time of rules to the classloaders' search space. I was wondering if we could have a better way to distinguish types and packages or at least a configurable way. The first things that come to my mind would be caching, in the lines of what is done for class loading in the org.drools.util.CompositeClassLoader. Or have two different strategies/implementations for the findType and isPackage methods, one that would assume that you respect java conventions and parse the string to say if it's a package or a type and another that wouldn't assume anything and use the getResourceAsStream as it's done today. Then, we could choose via configuration which strategy to use. Any other ideas? Any work already being done in this area? Cheers, Leo.