Recent changes introduced to avoid the eager loading of classes have lead to 
Functions not getting registered correctly if the class hierarchy leading up to 
Function (or FunctionAdapter) is split up across multiple jar files.  We 
propose to introduce a new annotation to identify functions in such a case.
Consider the following scenario: 
> Abstract.jar - public abstract class AbstractFunction implements Function 
> {...} 
> Concrete.jar - public class ConcreteFunction extends AbstractFunction {...}
When Concrete.jar is deployed, we only scan the classes inside Concrete.jar.  
This means that we have no way of knowing that AbstractFunction eventually 
leads up to Function.  (We could load ConcreteFunction to see if it implements 
Function via reflection or Function.class.isAssignableFrom(), but then we would 
be back to eagerly loading all of the classes to see whether or not they 
implement Function.) 
We propose a new annotation (perhaps @RegisterFunction, suggestions are 
welcome) to designate a class as a Function in such a case.  Since we are able 
to scan classes for annotations without loading them, this will allow us to 
identify ConcreteFunction as a Function without eagerly loading all of the 
classes in Concrete.jar.  
I should emphasize that ConcreteFunction already is registered as expected if 
it resides in the same jar file as AbstractFunction.  This annotation would 
only be relevant when the class hierarchy leading up to Function is spread 
across multiple jar files.
- Jared

Reply via email to