Bugfix for dynamic class loading with custom ClassLoaders (#94).
Uses the discovered ClassLoaders rather than just defaulting to the system ClassLoader when calling Class.forName(). If you have overridden the system ClassLoader in your application, this will enable FastClasspathScanner to work with your MatchProcessors.
Also, switches class initialization to be lazy by default. From the documentation:
Class loading and initialization: By default, classes are loaded but not initialized before references to the loaded classes are passed to a MatchProcessor. This means that class initialization is performed lazily, i.e. class initialization is deferred until the first time the class is used. Therefore, you should not make the assumption that when FastClasspathScanner gives a MatchProcessor a reference to a matching class, it indicates that the class' static initializers have already been run (they haven't, by default). Lazy class initialization generally leads to faster scanning and can give rise to fewer surprises overall than immediately running the static initializers for every class as it is loaded, since not all matched classes may be used by a MatchProcessor, and class initialization has side effects. To force FastClasspathScanner to initialize each class as it is loaded, call FastClasspathScanner#initializeLoadedClasses(true) before calling FastClasspathScanner#scan().