Lambda: the new generation!


Java 8 brings lambdas. If you missed it here few samples:

// a method taking an interface with a single method
public void doRun(Runnable run) {
  // ....do something with run
}

// somewhere in code
doRun(() -> {
    // some java code
});
// or
doRun(this::methodWithNoParameter);

Of course you can also use parameters while they match. In 1 sentence we could say lambda are functions you can handle in java directly like class instances.

The most known use case for lambda is the new Java 8 stream integration:

List<String> list = asList("search string", "searched string", "searched string 2");
List<String result = list.stream()
  .filter(s -> s.contains("searched string")) // lambda to filter the stream
  .map(s -> new StringBuilder(s).reverse().toString()) // lambda to work on each item
  .collect(Collectors.toList());
// here result = ["gnirts dehcraes", "2 gnirts dehcraes"]

However lambda enables you to go further in term of API!

Continue reading

Lambda-CDI in Alpha!


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:

  1. extract the types from the lambda class metadata.
  2. convert it in java qualified name thanks to the shaded version of asm included in the JVM
  3. 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!

JAX-RS 2: ensure your server providers are not used on client side!


Since JAX-RS 1 and moreover with JAX-RS 2 developpers create JAX-RS providers.

The most common ones are to (de)serialize the request/response payloads but you can do much more now like switching the input stream, updating the output stream, filtering the request/response etc…

Going further in this API you’ll realize you can filter input/output on server side and client side (for instance you can write a ClientRequestFilter and a ContainerRequestFilter). Generally client and server API are close but adapted to the “side” where the provider is working.

However can we ensure we didn’t mess things configuring a client provider on a server?

Continue reading

TomEE Maven Plugin: finally server.xml in your pom!


Until 1.x releases to configure the server.xml related to tomee maven plugin (embedded or not) you needed to configure either its direct location through “serverXml” parameter or a “conf” folder containing a server.xml. This is working fine but it was often forcing you to create a folder containing the server.xml only.

Note: if you are not used to tomee maven plugins, you can configure almost all the container through properties in the pom.

To avoid it both plugins now got a new variable to let you provide your server.xml inline!

Continue reading

JSON and WebSocket: Johnzon to the rescue


When writing a WebSocket endpoint the first thing you do is to create the endpoint (connection point) then you have to define the protocol to use. Because of what is modern IT world it is quite common to use JSon as payload format for WebSocket messages. Of course you can use any JSon mapper you want or JSON-P directly but you can actually go a bit further and that is what does Johnzon in its coming 0.8-incubating release.

Continue reading