sorry for beeing a little bit confusing:
The two issues Classloader and Functions extensibility don't really have something to do, they are mostly separate. With the current code and private ctors and static functions, there is indeed no need for a custom classloader. This is why I argued to remove it.
The classloader also does not have anything to do with Bindings. The bindings was just an idea how to make it "easy" for the user to register own functions in a non-static way. I was under the impression, that the bindings are availabe while compiling. I don't want it "dynamic" - I wanted it still statically compiled. The idea was to add the reflected Method to the bindings, so when compiling the bytecode the method can be used (not per call). After reviewing the code again, I can see that the bindings are not available at the time of compiling - that was the misunderstanding, sorry (but it could still be fixed to support this). It just looked elegant to treat a function like a binding.
The classloader problem is something that comes into the game when users are able to register own functions. The problem here is that the classloader used to load the ASM-generated class has the one of lucene-core as parent (because we use the compiler's own classloader: this.getClass().getClassloader()). This classloader does not necessarily have access to anything in a different classloader (e.g. a plugin in ElasticSearch or Solr).
Finally its simple: Once we allow foreign, user-defined functions, we must add the Classloader argument to the compiler again, otherwise you cannot register methods from classes of foreign classloaders. An alternative would be to let the compiler figure out himself by passing a list of java.lang.reflect.Method and it chooses the correct classloader automatically.