Last day of Devoxx conference in Antwerp Belgium is scheduled. We have had many awesome talks in the past 4 days and the conference closes with more talks to fit in this category. So before we ship home to our beloved ones let’s have a look at these last-minute impressions.

Search, the Final Frontier by Shay Banon (roland)

Elastich search is a solution for clustered full text search. It
supports sharding and replication for individual indexes. It is
basically a cluster of nodes taking index and query request via a JSON
REST API.

Quite somme web based tool has been developed for elastic
search. E.g. elastic search head is some sort of management
application for elastich search. elastic search paramedic is a
graphical monitoring tool using cubism.js and d3.js for
visualizations.

Node can join seamlessly an existing cluster. Shards are distributed
over the nodes in the cluster. A master is automatically
selected. Number of replicas can be changed dynamically. Elastic
search as multitenancy support which supports searches across multiple
indexes.

Mappings of JSON fields to index fields can be controlled fine
granurily. The analyzed can be queried, tested and tuned via the REST
API. For querying elasstic search, a sort of JSON DSL is available
with all sort of operators supported by lucene.

Facets are aggreations of data, so queries for statistical
data or histograms can be done easily. This is a real powerful
feature.

Elastic search nodes can be even embedded from within a JVM ! That’s
freaking interesting, since it now can supposedly run within an JEE
environment, which is often a constraint to met for production system.

The whole presentation was done without slides but only with live
demos. It was a nice introduction into elastic search, but not much
more than an introduction. I would have loved to hear a bit more about
performance characteristics especially when it comes to indexing large
documents. Nevertheless a good talk.

Annotation Features in JDK 8 by Joel Borggren-Franck (olaf)

Day five at Devoxx 2012 started, among other presentations, with Joel Borggren-Franck talking about the upcoming annotation features in JDK 8. Joel works in the Oracle Java Platform Group.

Currentlty, Java only allows annotations on declarations, as for example in:

*@Deprecated*
class SomeClass { ... }

@Annotated
public void aMethod (*@Positive* in aParam) {
    *@Negative* long aVariable;
}

With JDK 8, annotations will also be possible on the use of a type (as specified in JSR 308), for example:

new *@Interned* MyObject();
myString = (*@Printable* String) myObject;

class UnmodifiableList\<T\> implements *@Readonly* List\<*@Readonly* T\> { ... }
void monitorTemp() throws *@Critical* TempException { ...}

According to Joel, the reason for implementing this feature was mainly to enable the use of the Checker framework which performs more sophisticated code verification during compilation. For example, a “Nullness” checker might prove the absence of null pointer exceptions with code like the following:

class BusinessLogic {
Entity e = (*@NonNull* Entity) Factory.getEntity();
  // ...
  return e;
}

Other examples are a “Lockchecker” that proves field access is guarded by a lock or a “Regex” checker that proves the validity of regular expressions and the existence of capture groups within the expression. The Checker framework uses a pluggable type system, so users can develop new type checkers. The most useful checkers may become part of Java. The Checker framework is developed outside of Oracle.

However, as Joel pointed out, everything can be overdone, so he hopes developers will not go overboard when is comes to annotating their code, for the sake of code readability.

Another improvement in JDK 8 will be repeated annotations: currently, annotations may not be repeated, like in the following:

@EJB(Calculator)
@EJB(ShoppingCart) // not allowed
public class ShoppingCartServlet { ... }

This has lead to container workarounds like the following:

@EJBs({ @EJB(Calculator), @EJB(ShoppingCart) }) public class ShoppingCartServlet { ... }</pre>

JSR 120 will resolve the need for such workarounds by allowing repeated annotations: first, you will have to annotate your annotation type (“EJB” in this example) with a container (“EJBs”):

@ContainedBy(EJBs.class)
public @interface EJB { ... }

Then, you need to create the “container”:

@ContainerFor(EJB.class)
public @interface EJBs {
    EJB[] value;
}

If you do this, javac will automatically synthesize the container for you, so:

// *Example 1*:
@EJB(Calculator)
@EJB(ShoppingCart) // allowed in JDK 8!
public class ShoppingCartServlet { ... }

will effectively become:

@EJBs(value = {
    @EJB(Calculator),
    @EJB(ShoppingCart)
})
public class ShoppingCartServlet { ... }

This, however leads to some inconsistencies within the reflection API:

For example, considering example 1, the following surprisingly would return null:

ShoppingCartServlet.class.getAnnotation(EJB.class)
// => null

This is because both @EJB annotations have internally been wrapped into a single @EJBs container annotation. To fix this, getAnnotation(Class<T>) will be modified to unpack a container when necessary and return a matching annotation contained therein. A new method getAnnotations(Class<T>) will return an array of annotations, again unpacking the container when necessary. The same applies to getDeclaredAnnotation and getDeclaredAnnotations.

Joel also explained how Oracle would like to make the javax.lang.model.* APIs (offering a source file view) available at run time. While javax.lang.model.* allows more sophisticated insight into code than java.lang.reflect.*, it is currently only available at compile time. Oracle does not yet exactly know how to deliver this, but a feature complete first draft is done, so: “stay tuned!”.

Bye Bye Devoxx 2012!