How to ignore Maven build erros due to JavaDoc with Java 8

Java 8 is a bit more strict in JavaDoc parsing. This can lead to build failures in Maven when building the repo with warnings like:

Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.7:jar (attach-javadocs) on project [projectname]: MavenReportException: Error while creating archive:
Exit code: 1 - [path-to-file]:[linenumber]: warning: no description for @param

Sure, the good solution would be to fix the JavaDocs. But in cases where you just clone a foreign repo, you probably just want to get it run and not start fixing it.

To ignore the erros, just turn off doclint by adding the following <configuration> tag to your pom.xml:

            <configuration> <!-- add this to disable checking -->

Some more solutions can be found in this StackOverflow thread.

How to get List of Objects from deeper level in Json via GSON

Sometimes you get a quite nested Json response but the only thing you need is a list of classes in a certain branch of the Json document (like a response of Yahoo’s YQL query).

Assume just the following json document:

"fieldA": {
    "fieldB": {
        "fields": [
            { "foo": "test1", "bar": "test2"},
            { "foo": "test11", "bar": "test22"}

And the only thing you need is the fields array.
A Java8 way to get the fields as a list would be:

List<FooBar> quotes2 = Stream.of(gson.fromJson(json, JsonObject.class)
	.flatMap(e -> Stream.of(gson.fromJson(e, FooBar[].class)))

But that’s quite some code. Okay if you only need it once, but as soon as you need this several times it clearly violates the DRY principle. Gson (which I am using a lot) doesn’t seem to provide a simple way for doing this. Except creating the whole hierarchy as Java Classes, which might just be overkill.

Solving the problem in a more generic way is the way to go – but it als requires creating generic arrays:

class Gsons{
    public static <T> List<T> asList(String json, String path, Class<T> clazz) {
        Gson gson = new Gson();
        String[] paths = path.split("\\.");
        JsonObject o = gson.fromJson(json, JsonObject.class);
        for (int i = 0; i < paths.length - 1; i++) {
            o = o.getAsJsonObject(paths[i]);
        JsonArray jsonArray = o.getAsJsonArray(paths[paths.length - 1]);
        Class<T[]> clazzArray = (Class<T[]>) ((T[]) Array.newInstance(clazz, 0)).getClass();
        T[] objectArray = gson.fromJson(jsonArray, clazzArray);
        return Arrays.asList(objectArray);

The only things to do are creating a class for the entities and calling the method:

List<FooBar> fooBars = Gsons.asList(json, "fieldA.fieldB.fields", FooBar.class);

How to do automatic tagging of articles using Feedly

In this post I will describe a first proof of concept approach about how to implement a supervised learning system to automatically tag RSS posts in Feedly.


Everyone using an RSS reader to read daily news surely knows the situation that certain topics keep (re)occuring in the news. Yet most people have topics that they are simply not interested in. Just think about certain sports, political topics or world events. But of course they keep showing up in the daily news stream.

Therefore a system is needed that automatically assigns predefined tags to the corresponding news entities and (maybe) also marks them as read.

A critical point is that the system must integrate into an RSS reader application. A system not being able to attach to an existing system would not be applicable as one still wants to use a mobile / desktop app to read the news and also to (un)tag articles. Implementing the complete value chain comprising fetching RSS, parsing, classifying, providing an aggregated stream AND an application for reading the news is definitely out of scope for a proof of concept.

I wanted to write such a classifier for quite some time but didn’t find a system that provided a convenient API to plug in  a tool for reading, classifying and pushing back the results. Unless I discovered the Feedly API. Unfortunately the Feedly API is not (yet) fully open, so that one has to obtain a time limited API token by hand. Yet, for a proof-of-concept, this is totally acceptable.

The Learning System

So much for the introduction. Let us go in medias res:

The first thought was to start with some clustering using Elasticsearch (for similarity search). But let’s recall the base facts and requirements:

  • Only a hand full of tags are needed
  • start with the simplest approach first
  • it should be able to run either on OpenShift or on my Raspberry Pi

So the choice was to start with a simple Naive Bayes Classifier. Instead of doing an in depth explanation of the Bayes classifier (I recommend Paul Graham’s A Plan for Spam and the page about combined probability), just recall: a Bayes Classifier is just a 0-1 classifier. So a single classifier is required for each tag. This makes it of course unusable for a very large amount of tags! But the big advantage is that the Bayes classifier is just dead easy. Just count how often a word occurs in the desired in class A (the Tag) and class B.

How to train / apply the classifier(s)

The classifier should be trained perdiodically and the user must have the opportunity to correct classification errors. Before dealing with synchronizing & updating entries, the classification workflow for each tag is:

  1. get all entities for the tag and use them as positive samples
  2. get all read and untagged entities and use them as negative samples
  3. get all unread and untagged entries and compute P(tag)
  4. if P(tag) > 0.95, mark the entity with the tag and probably also mark it as read

As input, the all kinds of properties are used that could distinguish between tags. Including the source URL, site keywords, categories etc. Then the content is tokenized / split by all non word characters. Graham writes about some optimizations for spam detection – yet results were pretty convincing without further optimization.

in order to have some positive samples, this of course requires the presence of some entities being tagged already. In this case I started tagging already quite some time ago as I already assumed that I needed some ground truth.

Raspberry PI: Boon and Bane

Raspberry PIs are great as little home servers. The drawback is that the RaspPi has just a single core, 700 MHz ARM CPU and 512 Mb ram which is shared between GPU and system. So, it is a bit slow and is a bit low on resources. Especially if the RasPi is also used for other purposes at the same time that also consume some RAM. In case of very large RSS streams, this could indeed raise a  problem: Running low on CPU is unconvenient (=slow), but running low on RAM is deadly (OOME). Therefore it might be required to replace the HashMap in the Bayes class with a DB layer like MapDB.

Status Quo

The quick test with the Bayes classifier showed already some really fine results! On the RasPi, each Tag is classified within 200 – 230s (14 – 18s on my notebook). The mission “Reduce the amount of information that I am not interested in” can thus be regarded as “successfully tested“!

Also there have hardly been any misclassifications. And the ones I experienced were quite understandable. In contrast to scientific publications I didn’t do extensive accuracy tests – the first attempts were so promising that I simply saved the time and thought about what to try out next that could make my life easier.

If this approach should be followed any further there are of course (as always) some open issues: Besides code cleaning, one could try to filter by TF-IDF, filter certain tokens, adjusting thresholds, etc. But I doupt that the results would get much better.

And of course, the complete code is available at GitHub. Feel free to fork it and play around with it! Beware: The code can change dramatically from one commit to another. For example if I just want to test a new idea.

Java 8 Streams: Collecting items into a Map of (Key, Item)

Once in a while I come across the task where I have a list of Items that I want to filter and afterwards store in a map. Usually the key is a property of the Item: -> anItem

In the usual Java way this looked like the following:

Map<String, Stuff> map = new HashMap<>();
for (Stuff s : list) {
    if (!"a")){
        map.put(, s);

Nothing really special, but it somehow doesn’t look too nice. Yesterday I thought: in Scala I would emit tuples and call .toMap. Isn’t that also possible with Java 8 Streams? And indeed it is:

Map<String, Item> map =
    .filter(s -> !"a"))
    .collect(toMap(s ->, s -> s)); // toMap is a static import of Collectors.toMap(...)

This looks compact and readable!

If you don’t like s -> s, just use identity() function of the Function class. Actually I do not like static imports very much as as they make the code less readable, but in this case I would decide for static imports.

Map<String, Item> map =
    .filter(s -> !"a"))
    .collect(toMap(s ->, identity())); // toMap and identity are imported statically

Check internet connectivity in Android

When programming an Android App you sometimes want to check, if you are connected to the Internet.
The first thing that comes to mind is using the ConenctivityManager. Yet this solution has the problem that it only tells you that you are connected to .. something. With a WiFi connection this can mean, that you are connected to an access point. But it does not tell you that the access point is connected to something else!

Continue reading Check internet connectivity in Android

RaspberryPi Weatherstation – The TV Station (Part III)

The third and last post of this series describes the RasperryPi that is connected to the TV and displays the sensor data in a visually appealing way.

Part 1Part 2Part 3

In the past blog post, the first Raspberry Pi was connected to several sensors. Tiny Python scripts poll the data from the sensors regularly and save them to simple text files that can be copied via SSH/SCP. Current data can be obtained from the sensors by directly connecting to the Brick Daemon which runs on this RasPi.

The main focus of this post is the visualization of the data via a JavaFX application and how to control the FX application by using the regular remote control of the TV. But – before we’re divig into the details, I want to teas you with a screen shot of the final result 😉

Wetterstation blue edition

Nice isn’t it? So let’s get started

Things to discuss

The most important question first: What do I want to see and do?
I had a pretty clear intention already: I want to see the current values of all sensors in a small overview and I want to be able to toggle through time series of the past days.

Toggling should be done by the TV’s remote control as I would have the remote at hand already when I switch to the Weather data display. I’ve seen several guides where an IR-receiver and an additional remote were used to control the RasPi. Yet I simply do not like the idea of having another remote control on the table – right next to the other ones. Also controlling the app via mobile phone wasn’t what I wanted as we usually still simply use the TV’s own remote to control the TV. – Also I know from Raspbmc that it is possible to accomplish this by using libCEC – somehow.

Next question to clarify: How should the data be visualized on the TV. This was easy: JavaFX.
Colleagues asked me why I chose FX instead of HTML5. Well mainly there were three reasons:

  • I simply wanted to do something in JavaFX
  • I’m not a fan of fizzling around with JavaScript and CSS. And the standard way to displaying webapps on the RasPi seems to be using Midori. A browser I never worked with before – and even thinking about possible CSS/JS incompatibilities totally turned me off.
  • I wanted to control the UI with the TV’s remote control. That has to be done somehow using the CEC-commands that are sent through HDMI. I’ve never done that before and anticipated my chances to accomplish this in pure Java ways higher than somehow creating input events that I had to redirect to the browser.

Checking the Hardware

Prior to coding, I did some research if and how the CEC commands are sent through HDMI. And – unfortunately – besides all software problems, a lot of people reported problems to even get the signal to the RasPi! Possible problems mentioned throughout several posts included the TV software having disabled the CEC functionality or HDMI cables that were blocking / not forwarding the CEC signals.

What I found the easiest way to test the CEC compatibility of the setup was Raspbmc. Raspbmc is a mediacenter for Raspberry Pis, which is easy to install and supports CEC. So: download the image, flash it to an SD card, connect the Pi to your TV with the HDMI cable that you want to use later as well and start the Pi. If you see your TV’s remote working: Great! Otherwise: you have my sympathy. Good luck in finding out what is wrong with your technical setup.

Install libCEC

So the CEC signals are technically consumable by the Pi. Let’s istall libCEC.
DO NOT install the packages from the pulse-eight website. And also DO NOT simply recompile and install libCEC following the guide on the GitHub page. It’s important to compile the lib for the Pi! Just follow one of the step by step guides to compile and install:

$ cd /tmp
$ sudo apt-get install build-essential autoconf liblockdev1-dev libudev-dev git  libtool pkg-config
$ git clone git://
$ cd libcec
$ sudo ./bootstrap
$ sudo ./configure --with-rpi-include-path=/opt/vc/include --with-rpi-lib-path=/opt/vc/lib --enable-rpi
$ sudo make
$ sudo make install
$ sudo ldconfig
$ cec-client -l

LibCEC is now installed including cec-client (seen in the last call). Play around a bit with cec-client. Up to now everything was fine on our Samsung TV. But beware, I’ve seen posts where people with TVs from other vendors faced serious problems … If you want to play around with cec-client, CEC-O-MATIC might also be a reference you should have a look at.

Install Java 8

At the time of writing, Java 8 is already released. At the time I was writing the code, it was still an EA release (Early Access). I read several posts that recommended installing the ARM version of Java 8. So I simply followed the OpenJDK guide to install OpenJDK 8:

  1. download Java 8 ARM from Oracle
  2. unpack the file: sudo tar zxvf jdk-8-linux-arm-vfp-hflt.gz -C /opt
  3. and check if Java 8 got installed: /opt/jdk1.8.0/bin/java -version
  4. Set default java and javac to JDK 8:
    $ sudo update-alternatives --install /usr/bin/javac javac /opt/jdk1.8.0/bin/javac 1
    $ sudo update-alternatives --install /usr/bin/java java /opt/jdk1.8.0/bin/java 1
    $ sudo update-alternatives --config javac
    $ sudo update-alternatives --config java
    $ java -version
    $ javac -version

    java and javac should link to 1.8.0 now.

Next adjust the memory split option as also mentioned on the page to 256mb (gpu_mem=256 in /boot/config.txt). It’s useful to read the page. The page also gives a note which is pretty important to avoid frustration:

Note that the default configuration of JavaFX on the Raspberry Pi does not use X11. Instead JavaFX works directly with the display framebuffer and input devices. So you should not have the X11 desktop running when starting JavaFX.

JDK 8 EA builds for the Raspberry Pi include full support for hardware accelerated graphics, with everything from the base, graphics, controls and FXML modules. Media and Web modules are not included.

So configure the Pi to boot just to the shell (via sudo raspi-config) and do not try to see the JavaFX output via VNC!

Building the GUI

Designing the UI (or: how I started to love JavaFX)

Before I even started to code, I wanted to set up the layout. Coming from a Java-Swing background I was really excited to try this JavaFX thingy that was said to be so much cooler than Swing.

After setting up the project in NetBeans and installing JavaFX Scene Builder I was very positively surprised! By the way, I was only working with Scene Builder 1.1, the current Version 2 is said to be even better. After initializing the project, my focus quickly went into the src/main/resources folder. At this location you can find fxml/FXMLDocument.fxml and styles/base.css (later renamed to metro.fxml/.css). Designing the Gui was about 90% done just in Scene Builder (for the .fxml) and Netbeans (for the.css). The really really nice thing is that it is a true WYSIWYG editor. Also whenever the css file is being edited, the effect is immediately visible in Scene Builder. Simply great compared to what I was used to from my Swing experience.

After the main layouting was done, I started to write some Java code in Accessing UI components is simply done by annotating the according fields. The fields themselves are injected automatically. A nice decoupling of view and controller. Also I was able to compare two very different layouts by just switching one single line (the one referencing the fxml file) without further refactoring.

Time for some user tests! Honestly, I was a bit afraid what others would say. But I wanted to make a NICE UI, so I asked my wife and friends on Facebook and Google+ for feedback. And this decision turned out to be damn right! I got very valuable feedback about colors and layout. I definately recommend asking users – and value their feedback!

Afterwards I implemented the logic for reading the CSV files including filling the model classes. These model classes were then rendered into the graphs. So I also had some test data and continued styling the graph lines via CSS. At this stage I remembered the talks of Gerrit Grunwald. Gerrit is pretty experienced in JavaFX on the Pi and mentioned in some talks that animations on the Pi can be really really slow in the beginning until everything gets hot spot compiled. – I can definitely confirm this! The trick was to simply set animated="false" on the line chart that would only be animated at the beginning (which I didn’t really need or want anyways).

Show the UI on the TV

Time for a first test on the TV! At this point, remember the last part from “Install Java8” above: We do not need an X-server as JavaFX on the Pi paints directly to the framebuffer! So just compile and build the Jar, copy it over to the Pi and start it with java -jar ./ Weatherstation-1.0-SNAPSHOT.jar.

I made the experience that my regular monitor is not the same as the display of the TV. So I spent some time with adjusting css font sizes until I was content with the way everything was displayed on the TV. It feels a bit like webdesign and testing with different browsers – just a bit less painful.

Connecting the sensors

With the gui being done so far, the next step had to be done. When the program is started, archived data is read from files. Current data should be fetched directly from the remote sensors. This was actually plain easy. With the API provided by tinkerforge, everything I had to do was starting a thread off the Event dispatching thread that polled new sensor values periodically and pushed the data to the models. the models then simply updated their UI elements.

Remote control Java

The key strokes should be used to toggle through the values of humidity, temperature, ambient light and air pressure.

Everything that was left now was the remote control part. Unfortunately, libcec is a C-binary only. So I had the choices to try some JNI and talk to the lib directly or to start a Java Thread wrapping a process that just called the cec-client program:
/usr/local/bin/cec-client -d 8 -t prta -o Wetter. The d parameter defines the verbosity of the output, t defines the type of device the cec-client simulates (recorder, …), and o finally defines the string that is shown in the On Screen Display of the TV when brwosing through the HDMI input devices. When a cec-client listens with this command, just switch the TV to the according “device” and press some buttons on the remote control. The key presses are shown on the console.

The console output again is parsed directly from the Java process and calls the appropriate methods in the controller. This works brilliant in my case. Yet PulseEight do not recommend using cec-client in a production environment as it is intended for tests only. But well – I didn’t want to invest even more time into coding a perfect cec-java-bridge. Especially as my C-knowledge is very basic. So chances are high that my implementation would be far from “production ready”, too.


That’s it! And of course, you can fork the complete project on GitHub!

Part 1Part 2Part 3

Take care when logging Exceptions!

Today I was facing some weird nullpointer exceptions (NPEs) in my Android App (Beta phase, luckily). Usually I catch exceptions like

try{ .. }catch(SomeException e){"A SomeException occured, but i got it.", e) 

Well in this part of the code I broke with my habit and wrote:

try{ .. }catch(SomeException e){"A SomeException occured, but i got it: "+e.getMessage(), e) 

And guess what. I experienced the expected exception, caught it (great) – and got a NPE somewhere in the Loggin framework. WTF?
After having a quick look at the Throwable API, I realized that getMessage() can indeed return null. And String+null produces null. So I nulled my logging message and passed this null reference right into the logging call – which produced the NPE in there. This was very annoying as I successfully caught the first exception – just to produce a susbsequent error during handling the first one.

Well, I immediately grepped my whole project for any strings like .getMessage() and checked for any other NPE traps.
Lesson learned today: carefully check the Api docs and be even more paranoid for NPEs.
Yet one question remains unanswered: Why on earth would one like to return null references in exceptions instead of empty strings?!

IllegalStateException: Content has been consumed

When working with Android or (to be more general) Apache HttpComponents, one should keep in mind that it depends on the HttpResponses (Api: Apache, Android) if they can be consumed multiple times or not. And if the response is not, then better triple check your code, what you’re doing.

I experiences the (very ugly) issue during the apparently simple task of reading the content of the response. )For ease of simplicity, I also use Apache commons-io, to read buffers etc.)

HttpResponse response = ...;
String content = IOUtils.toString(response.getEntity().entity.getContent());

Okay, how many possible Nullpointer Exceptions do you see? I didn’t care until I experienced the first one, so I made the code NPE safe:

HttpEntity entity = response.getEntity();
// entity can be null according to the docs!
if (entity != null) { 
    // The interface doesn't say that getContent() MUST return non-null
    InputStream stream = entity.getContent(); 
        if (stream != null) {
            tempContent = IOUtils.toString(entity.getContent());

And suddenly I was faced with IllegalStateException: Content has been consumed. As I also did changes somewhere else, I assumed the error in some toString()-Methods that would read the content of the response during debugging. But as the error also showed up without debugging, I had a closer look to my “improvement”.

Well, the error was the call IOUtils.toString(entity.getContent()); which tried to re-aquire the Input Stream. But as I just aquired it two lines above for the null check, the content was already marked as consumed. So the (now hopefully) correct and robust code is:

HttpEntity entity = response.getEntity();
// entity can be null according to the docs!
if (entity != null) { 
    // The interface doesn't say that getContent() MUST return non-null
    InputStream stream = entity.getContent(); 
        if (stream != null) {
            tempContent = IOUtils.toString(<strong>stream</strong>);

And the moral of the story

Be very carefull when reading HttpResponses! Also avoid pretty-printing the content in toString() – this might suddenly also consume your content. And good luck finding the point where you consume the content in such cases.

But .. why?! Please avoid returning null!

Yet I still wonder, why so many methods are allowed to return null instead of just an empty stream or something. All the Null-checks don’t make the code more readable. Some programmers might even be tempted to simply put an catch(NullPointerException e) around the part of


. Nothing I’d really recommend but I could also understand if I’d see something in other code.

An introduction to the Logging framework (a.k.a. System.out.println is evil)


One of the first lines a programmer will write in a new language is surely “Hello World”. In Java you can write to the console or to the error stream quite easy with a simple System.out.println("Hello World") or System.err.println("Hello Error"). Great! When the code grows, bugs creep into the code and make live a bit harder. At this point programmers should definately start a deep and loving relationship with the debugger that is delivered with the IDE instead of using System.out/err.println() as debug method. Nevertheless – there are at cases, where a Debugger cannot (or hardly) be applied:

  1. The code runs in the IDE but not if startet directly. – What the hell’s going wrong?
  2. Handling of exceptions. An exception indicates a state that should not have happened and therefore it might be considered to be logged.
  3. The code is deployed to someone else and you cannot attach the debugger to his/her machine.

At either point, beginners tend to use System.out/err.println() to trace the execution path. While this might be okay if the onlyone that is using the code is the programmer alone, this can be very annoying if you are working in a team: If you forget to remove the debug messages, you’re polluting someone elses console output. Even worse: if the code is deployed to a client which reports an error, you cannot raise/lower debug levels or just enable/disable debugging. Do you really want to send a “debug version”? (No you wouldn’t.)

Continue reading An introduction to the Logging framework (a.k.a. System.out.println is evil)

Knowing: A Generic Data Analysis Application

We got another demo accepted:

Knowing: A Generic Data Analysis Application

Thomas Bernecker, Franz Graf, Hans-Peter Kriegel, Nepomuk Seiler, Christoph Türmer, Dieter Dill
To appear at 15th International Conference on Extending Database Technology (2012)
March 27-30, 2012, Berlin, Germany


Extracting knowledge from data is, in most cases, not restricted to the analysis itself but accompanied by preparation and post-processing steps. Handling data coming directly from the source, e.g. a sensor, often requires preconditioning like parsing and removing irrelevant information before data mining algorithms can be applied to analyze the data. Stand-alone data mining frameworks in general do not provide such components since they require a specified input data format. Furthermore, they are often restricted to the available algorithms or a rapid integration of new algorithms for the purpose of quick testing is not possible. To address this shortcoming, we present the data analysis framework Knowing, which is easily extendible with additional algorithms by using an OSGi compliant architecture. In this demonstration, we apply the Knowing framework to a medical monitoring system recording physical activity. We use the data of 3D accelerometers to detect activities and perform data mining techniques and motion detection to classify and evaluate the quality and amount of physical activities. In the presented use case, patients and physicians can analyze the daily activity processes and perform long term data analysis by using an aggregated view of the results of the data mining process. Developers can integrate and evaluate newly developed algorithms and methods for data mining on the recorded database.


  AUTHOR     = {T. Bernecker and F. Graf and H.-P. Kriegel and N. Seiler and C. Tuermer and D. Dill},
  TITLE      = {Knowing: A Generic Data Analysis Application},
  BOOKTITLE  = {Proceedings of the 15th International Conference on Extending Database Technology (EDBT), Berlin, Germany},
  YEAR       = {2012}

More informations will be published at the official publication site at the LMU.