Lambda + CDI in Alpha!
Lambda are nice new features of Java 8 and I’m sure we’re still missing
a lot of their uses to get nicer API in all domains where Java can be used (i.e all domains ;)).
However, it is often limited to JavaSE only. Typically, you can desire to get “injected” as method
parameter(s) some CDI beans – this would be the same for Spring beans or any IoC, but if you browsed this blog
you’ll understand that I’ll deal with CDI.
Now, the question is : how to link both worlds and get the best of them?
An example
Here is a simple sample showing you how mixing CDI and lambda can look like:
public class MyRuntimeBuilder {
public void doSomething() {
onEvent((MyEvent e, MyCdiEventProcessor processor) -> {
processor.process(e);
}).then((MyCdiWebSocket w) -> {
w.send("Got it!");
});
}
}
Then, why do we need Lambda? There are several cases:
- Laziness: if you need to “lookup” the instances after having called the builder (CDI not yet fully started for instance).
- Contextuality: if you build a DSL, you would want to get “method scoped” instances, and not to rely on DSL “builder” injected instances
- Closeness: make the “injections” closer to their use. In several cases it makes the code more readable.
- Reusability: this way your lambdas can be reused (keep in mind a lambda can also be a method with “::” syntax)
- Because it is fun 😉
- And much more…
To make the contextuality point more obvious, think of JBatch: you define a set of steps and we advise you to use @Dependent instances
for JBatch components. If you add a DSL and a BatchBuilder API, you can not count on injected components in your builder. If you have
N times the same component (N > 1), here is what you get:
public class MyBatchBuilder {
public void define() {
job().id("my-batch")
.step().id("download-csv")
.batchlet((HttpConnection connection) -> {
connection.configureProxy("myproxy", "8080");
connection.download("http://csvbase.com/mycsv.csv");
})
.step().id("download-xml")
.batchlet((HttpConnection connection) -> {
connection.configureTimeout(5, TimeUnit.MINUTE);
connection.download("http://xmlbase.com/myxml.xml");
})
}
}
In the sample below, we can suppose HttpConnection Instance must be used only once. If we use it twice, its configuration would leak
between steps.
CDI: from reflection to parameter instances
In this part, we’ll suppose that we have a java.lang.reflect.Method. The question is: how to get CDI parameters to call the method instance? Here, the solution is not provided by CDI but it is not that far.
You can get the parameter types and their annotations from the method (here, I’ll simplify a bit and skip annotations since a lambda doesn’t have parameter annotations). You just need to lookup the associated instance from the bean type.
To do so, we’ll use the BeanManager “getInjectableReference” method and we’ll need an InjectionPoint and a CreationalContext.
To get the BeanManager, we’ll use new CDI 1.1 “CDI” utility class. If you are on a CDI 1.0 server you can use DeltaSpike BeanManagerProvider:
BeanManager bm = CDI.current().getBeanManager();
Then we’ll implement an InjectionPoint. In CDI 1.1 you can create it from an “AnnotatedParameter”. I’ll enlarge that solution later, but for CDi 1.0 you can implement a custom injection point to get the same result. The easiest way is to create an implementation of “AnnotatedMethod” and “AnnotatedParameter”. Both are linked as expected.
Here is a proposal for their implementation – note that you can enhance it to support more metadata for qualifiers for instance:
// AnnotatedMethodImpl
public class AnnotatedMethodImpl<T> implements AnnotatedMethod<T> {
private final AnnotatedType<T> annotatedType;
private final Method method;
private final Set<Annotation> annotations;
private final List<AnnotatedParameter<T>> parameters;
public AnnotatedMethodImpl(AnnotatedType<T> annotatedType, Method method, int paramCount, Type[] paramTypes) {
this.annotatedType = annotatedType;
this.method = method;
this.annotations = new HashSet<>(asList(method.getAnnotations()));
this.parameters = new LinkedList<>();
for (int i = 0; i < paramCount; i++) {
this.parameters.add(new AnnotatedParameterImpl<>(this, i, paramTypes[i], new HashSet<>(asList(method.getParameterAnnotations()[i]))));
}
}
@Override
public List<AnnotatedParameter<T>> getParameters() {
return parameters;
}
@Override
public Method getJavaMember() {
return method;
}
@Override
public boolean isStatic() {
return Modifier.isStatic(method.getModifiers());
}
@Override
public AnnotatedType<T> getDeclaringType() {
return annotatedType;
}
@Override
public Type getBaseType() {
return method.getDeclaringClass();
}
@Override
public Set<Type> getTypeClosure() {
return Collections.singleton(getBaseType());
}
@Override
public Set<Annotation> getAnnotations() {
return annotations;
}
@Override
public <T extends Annotation> T getAnnotation(Class<T> annotationType) {
return (T) annotations.stream().filter(a -> a.annotationType() == annotationType).findFirst().orElse(null);
}
@Override
public boolean isAnnotationPresent(Class<? extends Annotation> annotationType) {
return annotations.stream().filter(a -> a.annotationType() == annotationType).findFirst().isPresent();
}
}
// AnnotatedParameterImpl
public class AnnotatedParameterImpl<T> implements AnnotatedParameter<T> {
private final AnnotatedMethod<T> method;
private final int position;
private final Set<Type> types = new HashSet<>();
private final Set<Annotation> annotations;
private final Type baseType;
public AnnotatedParameterImpl(AnnotatedMethod<T> method, int position, Type baseType, Set<Annotation> annotations) {
this.method = method;
this.baseType = baseType;
this.position = position;
this.types.add(baseType);
this.types.add(Object.class);
this.annotations = new HashSet<>(annotations);
}
@Override
public int getPosition() {
return position;
}
@Override
public AnnotatedCallable<T> getDeclaringCallable() {
return method;
}
@Override
public Type getBaseType() {
return baseType;
}
@Override
public Set<Type> getTypeClosure() {
return types;
}
@Override
public <T extends Annotation> T getAnnotation(Class<T> annotationType) {
for (Annotation a : annotations) {
if (a.annotationType().getName().equals(annotationType.getName())) {
return (T) a;
}
}
return null;
}
@Override
public Set<Annotation> getAnnotations() {
return annotations;
}
@Override
public boolean isAnnotationPresent(Class<? extends Annotation> annotationType) {
return getAnnotation(annotationType) != null;
}
}
NB: you surely noticed that I didn’t use “method.getParameterTypes()” (or generic version) to get parameter types. In fact, I used a provided array of “Type” because lambda will not fill it properly (see next part).
Now, we have all we need to create an injection point and then make a lookup on a parameter.
Let’s do it:
Type[] types = ...;
Method method = ...;
BeanManager bm = CDI.current().getBeanManager();
// create our Annotated*
AnnotatedMethod annotatedMethod = new AnnotatedMethodImpl<>(bm.createAnnotatedType(method.getDeclaringClass()), method, cdiBeanParameterNumber, types);
List<AnnotatedParameter<?>> annotatedMethodParameters = annotatedMethod.getParameters();
// for all parameters, get the parameter instance
Parameters parameters = new Parameters(); // just a small wrapper to keep tracking of CreationalContexts
for (int i = 0; i < cdiBeanNumber; i++) {
CreationalContext<?> creational = bm.createCreationalContext(null);
Object instance = bm.getInjectableReference(bm.createInjectionPoint(annotatedMethodParameters.get(i)), creational);
parameters.addInstance(instance, creational);
}
Note: cdiBeanNumber is optional and we can use method.getParameterCount(). But in my implementation I’ll support CDI (and non-CDI) parameters, so I need a limit.
Now that we have all our parameters, we just need to call the method with it!
But wait, how do I get the Method? Are the method types right? Let’s dig into it!
Lambda: from instance to Method
Finding a lambda method it is not that hard. You simply iterate over the lambda methods and remove all Object methods and default methods:
public static void invokeLambda(Object lambda, Object...args) {
Class<?> lambdaClass = lambda.getClass();
for (Method method : lambdaClass.getMethods()) {
Class<?> declaringClass = method.getDeclaringClass();
if (declaringClass == Object.class) {
continue;
}
if (declaringClass == Serializable.class) {
continue;
}
if (method.isDefault()) {
continue;
}
// TODO: invoke it!
return;
}
throw new IllegalArgumentException(lambda + " not a lambda");
}
Now that you identified the “lambda method”, remember that it can be a lambda or a normal (java 7 like) implementation of the functional interface. To check it, an easy way is to check instance class name. If it contains “$$Lambda” then it is a generated class by the JVM to implement the lambda. If it is not the case then you can use “method.getGenericParameterTypes()” to get method parameter types. If it is the case you need few more code.
You have two cases to find the lambda parameter types:
- Your functional interface is Serializable. In this case, serialize the lambda calling writeReplace method and cast it to SerializedLambda. You can get the signature of a SerializedLambda (“getImplMethodSignature()”). From this signature, you can build a “MethodType” with “MethodType.fromMethodDescriptorString” which will allow you to access parameter types.
- If you don’t want to make your functional interface serializable to keep your API clean, you can get the “ConstantPool” from the lambda class, and the types from this instance. This is the job of the next snippet.
Note: in next snippet there is few reflection for sun.* invocations. This is not mandatory and a strong cast would have worked but allows to keep the build failing on sun.* imports – important for other parts of the code to avoid wrong imports not noticed.
private static java.lang.reflect.Type[] methodTypeParameters(Object lambdaInstance) {
try {
ConstantPool pool = ConstantPool.class.cast(GET_CONSTANT_POOL.invoke(lambdaInstance.getClass()));
String[] methodRef = pool.getMemberRefInfoAt(pool.getSize() - 2);
// Type[] types = jdk.internal.org.objectweb.asm.Type.getArgumentTypes(methodRef[2]);
Object[] argTypes = (Object[]) GET_ARGUMENTS_TYPE.invoke(null, methodRef[2]);
Collection<java.lang.reflect.Type> types = new ArrayList<>(argTypes.length);
ClassLoader loader = Thread.currentThread().getContextClassLoader();
for (Object argType : argTypes) {
Class<?> clazz = loader.loadClass(String.valueOf(GET_CLASS_NAME.invoke(argType)));
types.add(clazz);
}
return types.toArray(new java.lang.reflect.Type[types.size()]);
} catch (Exception e) {
throw new IllegalStateException(e);
}
}
This code is low level but the overall idea is:
- extract the types from the lambda class metadata.
- convert it in java qualified name thanks to the shaded version of asm included in the JVM
- load the associated class.
Put it all together
So now we are able to find lambda parameter types, and to lookup CDI beans by type. It is time to put it all together!
Click here to see the utility class with all that code: https://github.com/rmannibucau/lambda-cdi/blob/master/src/main/java/com/github/rmannibucau/blog/lambda/cdi/Lambdas.java
Lambdas utility use
Now we are able to call lambdas with CDI injections. Let’s see how to use our utility class.
First, define few functional interfaces:
@FunctionalInterface
public interface TaskWithCdiParameter<T> {
void work(T cdiBean);
}
@FunctionalInterface
public interface TaskWithCdiParameterAndArgument<T, A> {
void work(T cdiBean, A arg);
}
Then define a class based on these interfaces:
// this class stack tasks then execute them sequentially
public abstract class MyFlowBuilder implements Runnable {
private final Collection<Runnable> tasks = new LinkedList<>();
// cdi parameter(s)
protected <T> void work(final TaskWithCdiParameter<T> task) {
tasks.add(() -> Lambdas.invokeLambda(task));
}
// cdi params + args
protected <T, A> void work(final TaskWithCdiParameterAndArgument<T, A> task, A arg) {
tasks.add(() -> Lambdas.invokeLambda(task, arg));
}
public abstract void defineFlow();
@Override
public void run() {
tasks.stream().forEach(Runnable::run);
}
}
Finally define your own builder:
MyFlowBuilder builder = new MyFlowBuilder() {
@Override
public void defineFlow() {
work((ABean1 bean) -> bean.call());
work((ABean1 bean1, ABean2 bean2) -> {
bean1.call();
bean2.call();
});
work((ABean3 bean, String arg) -> bean.call(arg), "param");
work(new TaskWithCdiParameter<ABean1>() { // java 7 style
@Override
public void work(ABean1 cdiBean) {
cdiBean.call();
}
});
}
};
builder.defineFlow();
builder.run();
This example is effortless but already shows you how to use CDI lambda injections of course. It also shows you how to mix them with parameters. This last case can easily be extended to support CDI qualifiers on lambda 🙂
Conclusion
Creating an API with lambda is not that obvious because you often need to:
- Create several interfaces with N parameters (personally I use N in [0, 10] because I think N > 10
makes API too complicated and doesn’t bring anything more – you can still create another type to aggregate several injections)
- Duplicate this API with parameters or not (same rule – already makes 10*10 functional interfaces)
- Potentially add some more behavior in the functional interfaces (small tip here is to create other
instances of your functional interfaces from the current one)
- If type is not enough (you can use qualifiers) then you can duplicate it again with
qualifiers (10*10*2 interfaces)
To make it easy to maintain, you can generate them from templates (cucumber does it). I don’t get
into details here, because I’ll try to write another post about it soon.
However keep it in mind this has impacts on your API. You need to carefully think about it because skipping this generation step will make your life easier… but can make your API less user-friendly.
Finally, linking your lambda API with any other library is not that hard since you can get almost
all metadata you need (I would still love to see annotations in these metadatas but you can fix it with a custom signature enriching lambda with metadatas).
Don’t be afraid of the lambdas and enter the game, a lot of new API style are next our doors!
New posts here >>> rmannibucau.metawerx.net 