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