Compile-time checking in Java

In a previous post I wrote about code quality: in a few words, I believe in static-checking. Static means without executing the program. In a software process point of view, this would imply before runtime, in other words at compile-time. For a developer, it can be very useful to have such a verification simply with a compilation, without executing a specific tool (by the way, some very interesting software of that kind are available, just Findbugs for example).

Here is the point: how would it be possible to proceed that kind of control without rewriting a compiler from scratch ?

The Java platform provides a very interesting feature to perform such operations: annotations (JSR 175). These are metadata defined as java types. Annotations have been introduced in the Java language starting with Java SE 5. Annotations can be processed at compile-time or runtime.

The Sun Java SE distribution provided from the starting point a facility for annotation processing at compile-time called APT (for Annotation Processing Tool). This was a vendor-specific feature (in Sun packages) executed in a specific and eponymous command line tool.

Since Java 6, that function is part of the platform with JSR 269 (javax.annotation.processing package, reference implementation part of the Java SE distribution). The contributed processing can be executed along compilation. With Java SE 8, the historical APT packaging and specific tool is removed (after deprecation in Java SE 7).

If the topic seems basic for the Java platform, there is a lack of exhaustive documentation for annotation processors development. I found some precious informations in Using Java 6 processors in Eclipse , a blog post by Carl-Petter Bertell . The Eclipse platform provide very precious functions with the JDT-APT project.

A very interesting presentation at EclipseCon 2007 by Walter Harley , Gary Horen and Jess Garms from BEA systems develops many important points about compile-time checking: what could be done with annotation processors and what requires more. For example, the processor does not provide the structure of the AST and thereby does not allow flow analysis.

A processor must implement the javax.annotation.processing.Processor interface. The implementation should be specified to the platform using the SPI system. An abstract class AbstractProcessor is provided to help implementations.

In a tutorial about annotation processing, Alex Collins details the implementation of a compile-time processor for the @Transactional annotation of the spring framework .

A Lucene-based map

Last year I needed to store strings in a Java Map using a limited memory.

The solution was rather simple: using a Lucene index to store the content on disk. This would provide interesting access performances. Here is the Gist:

Apache Solr: JVM memory management and mmap system calls

Unlike other indexing software like Elasticsearch, Solr can be deployed in any Java Servlet container. The documentation provides an example with Apache Tomcat: this is our target environment at the MNHN. Just like a standard Tomcat installation, here comes the question of memory allocation to the JVM. Reading the Solr section on the topic, it was chosen to allow a large part of the RAM to the JVM (5GB on a total of 6: one single spared for the system).

We identified quickly a main problem: while indexing, the Solr engine issued timeout errors on select queries. A stackoverflow exchange describes a similar behavior. We noticed on the server side an important usage of virtual memory.

As I answered in the exchange, we solved this problem a few months ago after reading a blog post by Uwe Schindler (a Solr committer). With Solr 4 and several Solr 3 versions, you have to let an important share of your RAM free so that the system can use properly the mmap system call. This is due to the introduction in Solr of a new Lucene component: the MMapDirectory. The blog post gives a plenty of informations on the system configuration. In our case, this solved the problem: we could finally index without any more timeout issue.

SysML Callout and UML

Recently, I participated in a Stackoverflow exchange about the SysML Callout concept. The exchange was started in a wrong direction: the initial question was only about the UML language. This was a misconception as the Callout node is a SysML concept and that led to an inappropriate accepted answer which was in fact a non answer.

I write this blog post because I think the topic is an important element in modeling. SysML is a UML profile defined in the frame of the OMG. The SysML 1.3 formal specification poorly defines the term as the effective conceptual definition appears in Annex A, p. 168:

The callout notation provides a mechanism for representing relationships between model elements that appear on different diagram kinds.

Things become more complex to find the proper way to render a Callout. More indications are available in the Allocation section (p. 129):

The allocation relationship can provide an effective means for navigating the model by establishing cross relationships, and ensuring the various parts of the model are properly integrated.

Later (p. 131):

An «allocate» property callout uses the same shorthand notation as the «allocate» property compartment. This notation is also shown in Table 15.1.

Here is the table explaining the notation of allocations:

In some way, the SysML Callout overlaps the CallBehaviorAction action defined in the UML Superstructure 2.4.1 formal specification, section 1.3.9 on p. 251. This is probably because SysML, as an UML profile, relies on the UML infrastructure.

To be synthetic, relationships between model elements that appear on different diagrams are an important part of modeling. But the representation of a Callout is, in my opinion, not very simple and clear.

Polymeria pages and Material Jekyll

I recently set up the GitHub pages of the Polymeria project. This was done easily starting with the Material Jekyll project by Charbel Rami.

Material Jekyll is a set of Polymer components helping to set up a Jekyll template. Few modifications where needed, one was pushed to the initial repository as it could be useful to other users: colors customization with a single Jekyll data file.