Oh My js! Server side javascript for java developers?

Javascript tooling set was enriched a lot these last years: npm, bower, gulp, grunt, … but most of them work on nodejs and need a certain amount of knowledge before being able to get anything from it.

For a Java developer it can be complicated and tempting to do a plain JSP instead of embrassing javascript.

Making javascript development easy can only be done in the case of a framework with a lot of defaults cause by nature you need to develop in an exploded fashion (by module) fr the maintenance and aggregate them at the end for performances reasons (HTTP 2.x will maybe make it smoother but will likely not replace it completely).

If your project is before all a frontend project you need to go on js side but if your project is simple and more centered on the data or the server side we can probably find a compromise.

This was the origin of “Oh My js!” which is a small library I created to integrate the pipeline I often use for frontend development with Maven and the Java stack I use (TomEE if you doubt of it ;)).

First of all what needs do I want to cover and which ones I’ll ignore:

• dependency management: ignored. I only want to handle runtime js dependencies and they are not that numerous in general so it can be done manually or worse case using webjars and a small groovy script for the optimization – will not be part of this post but can be another one if needed
• build: yes and no. There are multiple parts of a build in javascript: the “big final aggregation” which aims to put all resources we can in a single file to make client loading faster and (optional) each module transpilation/rendering/compilation/… This is this last part we will target
• test: java has a good tooling to do it but see next note for a more nuanced answer
• packaging: not sure javascript has a real packaging model yet but java has so all is fine and secured
• deployment: I build a war so maven/gradle are perfect

Of course I listed far more that what this post will cover but it was to show that the “blocking” part for a java developer is finally small enough to get some work to fill the gap.

Side note: frontend-maven-plugin is a great tool bringing to maven nodejs tooling (npm, bower, gulp, karma…). This however still needs to know these tools and just provide a “main-build” friendly solution so the initial cost can be important but it can worth it if you will need a lot of javascript.

The Promise of CompletableFuture? JAX-RS2 example!

CompletableFuture API introduced in Java 8 is different from previous Future in the way it is composable and usable as a promise. Let’s see how to integrate it with JAX-RS 2.

Add missing functions to HtmlUnit: Vue.js case

Depending the application you work on HtmlUnit can miss few functions. If you open the javascript engine you will quickly see it is quite complex to extend from your code and can be annoying when sometimes it just misses few methods!

Let see with the case of Vue.js how to fix it very easily.

Java 8 streams and JTA chunking?

Java 8 streams are very expressive – even if RxJava is even more 😉 – but sometimes EE integration is not that advanced. In case of a batch import of data it would be handy to use Stream API since we iterate over data to persist them but how to ensure we can use chunking – ie get a commit interval to not commit for each record?

CDI Context: it is possible without scope annotations in your API!

If you never implemented a CDI context/scope it is a simple as implementing this interface:

public interface Context {
   Class<? extends Annotation> getScope();
   <T> T get(Contextual<T> component, CreationalContext<T> creationalContext);
   <T> T get(Contextual<T> component);
   boolean isActive();
}

Note: in CDI 1.1 there is AlterableContext too which just adds a destroy(Contextual) method which is not important for this post so I will ignore it but I would recommand you to use it instead of Context if you can rely on CDI 1.1.

The Context implementation is quite simple:

• isActive() returns true if the context is usable by the CDI container
• getScope() returns the associated annotation (often @XXXScoped)
• get(Contextual) returns the instance of the Contextual (~= Bean) for “current” context
• get(Contextual, CreationalContext) creates or returns current instance

Creating a scope “annotation” is as easy as creating a runtime annotation:

// @NormalScope(passivating=false)
@Target({ METHOD, TYPE, FIELD })
@Retention(RUNTIME)
public @interface WrappingMethodScoped {
}

Note: the @NormalScope is optional since it can be done by an extension – this is what we’ll do.

Now we know what is a CDI scope let see how to activate it programmatically.

Embed Apache Johnzon in your library to not depend on a dependency

Sometimes you need to parse JSON files in a library. Then the question is pretty quickly: do I use a SPI (Service Provider Interface) to let the user choose the library he uses with my code or do I bind my library to one parser/writer?

Sometimes the answer is easy: when the need is basic (read/write) having a SPI and a default implementation is pretty good and let your users avoid to depend on one implementation. Said otherwise, you let your users reuse the implementation they probably already have in their application/classpath.

However sometimes you need a more advanced setup to get some customizations or features (like comments in JSON for instance which is very handy for configuration files) so either you bind your library to one implementation and your users end with N JSON implementations they don’t control and which potentially conflict together, or you enhance a lot your SPI risking to loose some features if your user chooses an implementation not supporting some of your needs, or you can also grab an implementation which work fine for you and just put it in your delivery. This last option is pretty nice cause then your code can use all the shortcuts an implementation can offer – like custom annotations.

Going further with this last option you can also potentially reuse some standard API like JSON-P or the coming JSON-B in your code and just hide it and not depend on the container for the runtime.

Of course there is no free lunch and it will make your delivery a bit more heavy but a good mapper is ~200k max so it is still a good option for JSON needs.

How to do it?

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!

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!

Json API (JavaEE 7) + Java 8: collection to JsonArray

JavaEE 7 brings an API for JSON arrays (the surprising JsonArray ;)), Java 8 brings a stream API and lambdas so now you can combine both to create a JsonArray from a Collection!

JCache: first overview

JCache is out since some months and we already have some implementations popping out (Hazelcast implemented the main part, Infinispan passes all TCKs, commons-jcs passes standalone TCKs – CDI implementation in progress, Spring just integrated it etc…).

This article is just here to present the basic API but some more will come with the features which can make it interesting compared to more simple APIs (like a Map).