Serialization of lambda expressions – using Java 8 Lambdas in Hazelcast distributed Executor and Executor Services

Lambdas in Java 8 are a very powerful solution to ease the writing of code in many situations. One of the domains for lambdas is the programming of Callable or Runnable tasks in parallel thread execution environments.

Since Callables and Runnables themselves are functional interfaces, lambdas can easily be used for task execution within the Java executor framework. Have a look at this:

ExecutorService executorService=Executors.newFixedThreadPool(5);
executorService.submit( () -> {      
    System.out.println("the method is running on thread:"
        + Thread.currentThread().getName());
} );

When writing this we came up with the idea to also use this for Hazelcast distributed executor service which in fact is nothing else than an ExecutorService allowing us to process our function in a scalable big cluster of up to hundreds of nodes.

Continue reading

Posted in Java Basics, Java Runtimes - VM, Appserver & Cloud | Tagged , , , , , | Leave a comment

Add Support for Java 8 Date & Time API to Jackson Serialized REST Web Services

When you are building REST web services using the Java 8 JDK, you might want to use the new Date & Time API to define temporal fields in your entity classes. For example, you might define the following simple User entity with the three fields username, fullname, and dateOfBirth:

import java.time.LocalDate;

public class User {
    private String username;
    private String fullname;
    private LocalDate dateOfBirth;

    // getters + setters...
}

An instance of this entity could be serialized as a JSON string in your REST service as follows:

{
    username: "jane.doe",
    fullname: "Jane Doe",
    dateOfBirth: [
        1986,
        10,
        06
    ]
}

When you try to consume such a web service with the Jackson mapper, for instance using Spring’s RestTemplate classes, you will experience the following exception:

com.fasterxml.jackson.databind.JsonMappingException: No suitable constructor found for type [simple type, class java.time.LocalDate]: can not instantiate from JSON object (need to add/enable type information?)

The problem here is that Jackson does not support the Java 8 Date & Time API out of the box, so you have to add this support yourself. But rest assured, adding this support is simple, as there is already a support library available from FasterXML: jackson-datatype-jsr310. To enable support for these new data types, you simply have to add the jackson-datatype-jsr310 support library to your classpath, for example with Maven:

<dependency>
    <groupId>com.fasterxml.jackson.datatype</groupId>
    <artifactId>jackson-datatype-jsr310</artifactId>
    <version>2.4.0</version>
</dependency>

Update: As Khaled correctly points out in the comments, you also need to explicitly tell the Jackson ObjectMapper to include support for JSR 310. In a Spring environment this could be achieved by the following bean definition (example courtesy of Khaled):

@Bean(name = "OBJECT_MAPPER_BEAN")
public ObjectMapper jsonObjectMapper() {
    return Jackson2ObjectMapperBuilder.json()
            .serializationInclusion(JsonInclude.Include.NON_NULL) // Don’t include null values
            .featuresToDisable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS) //ISODate
            .modules(new JSR310Module())
            .build();
}

If you’re like me, working with Spring Boot, you don’t need any explicit configuration, since this registration is automatically done for you by Spring Boot. But of course in a different environment, the Jackson ObjectMapper needs to be specifically set up.

Posted in Did you know?, SOA / Webservices | Tagged , , , , | 2 Comments

Spring-Konfiguration mit Groovy Bean Configuration

Seit der letzten Version des Spring Frameworks gibt es nun eine vierte Art, die Laufzeitabhängigkeiten zu definieren. Konnte man zu Beginn den Spring Container nur über XML-Dateien konfigurieren, gab es ab Spring 2 auch die Möglichkeit, diese XML-Dateien durch Annotationen an den Klassen deutlich zu entschlacken, und mit Spring 3 kam der Java-basierte Ansatz hinzu. Mit Version 4 kann man jetzt mit der mächtigen Groovy Bean Configuration arbeiten, die die Vorteile beider Ansätze (XML + Java) kombiniert.

So geschieht die Konfiguration der Spring Beans in einem deklarativen Ansatz (wie XML), es handelt sich aber um Groovy-Code mit all seinen Möglichkeiten (Schleifen, Bedingungen, Instanziierung von Objekten, …). Diese neue Konfigurationsart kommt ursprünglich von Grails und wurde vor einiger Zeit nach Spring portiert.

Wenn man Groovy bisher nicht kennt, muss man keine Berührungsängste haben. Das Build-Management-Tool Gradle macht es mit seiner Groovy-DSL vor und ist mittlerweile zu einer ersthaften Konkurrenz für die XML-basierten Platzhirsche Ant und Maven herangewachsen. Als Java-Entwickler fällt ein Umstieg auf Groovy zudem leicht, da die Syntax sehr ähnlich ist.

Ab Spring 4 kann man jetzt also mit der Groovy DSL ganz einfach eine Datasource konfigurieren:

beans {
    dataSource(BasicDataSource) {
        driverClassName = "org.h2.Driver"
        url = "jdbc:h2:mem:myDb"
        username = "sa"
        password = ""
    }
}

In Java-Konfiguration (ab Spring 3) würde das gleiche Beispiel schon aufwendiger sein und deutlich mehr Redundanzen enthalten:

@Configuration
public class DataConfig {
    @Bean
    public DataSource dataSource(){
        BasicDataSource dataSource = new BasicDataSource();
        dataSource.setDriverClassName("org.h2.Driver");
        dataSource.setUrl("jdbc:h2:mem:myDb");
        dataSource.setUsername("sa");
        dataSource.setPassword("");
        return dataSource;
    }
}

Auch der klassische XML-basierte Konfigurationsansatz ist nicht deutlich schlanker und strotzt nur so vor Redundanzen. Außerdem entfallen hier programmatische Eingriffe, die mehr Macht und Flexibilität bei der Konfiguration ermöglichen:

<beans>
  <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource">
    <property name="driverClassName" value="org.h2.Driver" />
    <property name="url" value="jdbc:h2:mem:myDb" />
    <property name="username" value="sa" />
    <property name="password" value="" />
  </bean>
</beans>

Nicht-Groovy-Kenner können schon an diesem einfachen Beispiel die Vorzüge des deklarativen DSL-Ansatzes erkennen. Was man aber nicht sehen kann, sind die vielen weiteren Möglichkeiten, welche die JVM-Allzweckwaffe Groovy theoretisch noch zu bieten hat. Aber darauf werfen wir in einem anderen Blogpost einen Blick.

Interessant ist noch die Frage, ob Spring die Groovy-DSL in späteren Versionen weiter anbieten wird. Anfang des Jahres hatte schließlich die gemeinsame Mutterfirma Pivotal die Unterstützung für das Groovy-Projekt beendet. Da Groovy aber auch noch in anderen Pivotal Projekten zum Einsatz kommt und außerdem ein Open Source-Projekt (mittlerweile bei Apache) ist, brauchen wir da erstmal keine allzu großen Bedenken haben.

Posted in Groovy and Grails, Spring Universe | Tagged , , , | Leave a comment

Redhat goes Microservice: Wildfly Swarm

Microservices sind im Moment in aller Munde und bei einigen Global Playern auch schon längst in Produktion (z. B. Netflix). Eine der Grundideen ist, eine Anwendung in kleine, in sich abgeschlossene fachliche Einheiten zu unterteilen, die jeweils eigenständig lauffähig sind (ohne Application Container) und untereinander über leichtgewichtige Protokolle kommunizieren (z. B. REST über HTTP). Die bisherigen Microservice-Frameworks verpacken in das WAR/JAR “nur” Webcontainer (Tomcat bei Spring Boot, Jetty bei Dropwizard). Von den klassischen Anbietern der Java EE Application Servern gab es bisher noch nicht viel, um self-contained Microservices zu erzeugen.

Das bisherige Programmiermodell von Java EE Anwendungen bestand eher darin, ein schlankes JAR/WAR mit dem Anwendungscode zu erstellen und dieses in einen Application Server zu deployen, welcher alle Java EE Implementierungen enthält. Der Microservice-Trend erklärt nun dieses klassische Deployment-Modell für tot, da in den meisten Fällen immer genau eine Anwendung in einem extra zu Verfügung gestellten Application Container installiert wurde.

Redhat hat nun mit Wildfly Swarm erste Alpha-Versionen zur Verfügung gestellt, um sogenannte Fat Jars zu bauen, in die neben der eigentlichen Anwendung auch der Wildfly Application Server integriert wird. Dabei sollen nur so viele Komponenten von WildFly zum Einsatz kommen, wie tatsächlich nötig sind, damit die Anwendung ihre Aufgabe erfüllen kann.

Herunterladen kann man Wildfly Swarm nirgends, es ist direkt über Maven Central verfügbar. Zum Aktivieren muss man in der pom.xml ein Plugin einbinden:

<plugin>
  <groupId>org.wildfly.swarm</groupId>
  <artifactId>wildfly-swarm-plugin</artifactId>
  <version>${version.wildfly-swarm}</version>
  <executions>
    <execution>
      <phase>package</phase>
      <goals>
        <goal>create</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Die für die Ausführung des Fat Jars notwendigen Teile des Wildflys gibt man dann als Dependencies an:

<dependency>
    <groupId>org.wildfly.swarm</groupId>
    <artifactId>wildfly-swarm-jaxrs</artifactId>
    <version>${version.wildfly-swarm}</version>
    <scope>provided</scope>
</dependency>

Das ausführbare JAR kann ganz einfach mit “mvn package” gebaut und anschließend ausgeführt werden. Der eingepackte Wildfly wird entsprechend hochgefahren, um die Java EE Anwendung zu starten.

mvn package
java -jar ./target/myproject-1.0-swarm.jar

Aktivierbare Subsysteme sind zum Beispiel Undertow für Servlets, JAX-RS, JNDI, Transactions, Messaging, Weld (CDI) u. a. Diese Subsysteme kann man auch programmatisch aktivieren und hat so die volle Kontrolle über die Server-Konfiguration (ähnlich wie bei Spring Boot). Dazu muss man eine Klasse mit einer main-Methode erstellen und diese in der MANIFEST.MF eintragen:

public class Main {

    public static void main(String[] args) throws Exception {
        new Container()
            .subsystem(new LoggingFraction()...)
            .subsystem(new UndertowFraction()...)
            .socketBindingGroup(new SocketBindingGroup()...)
            .start();
    }
}

Bob McWhirter (Leiter Forschungs- und Prototyp-Abteilung bei Redhat) empfiehlt Swarm im Moment noch nicht für den produktiven Einsatz. Er ist aber optimistisch, mit Hilfe der Community aktuelle Fehler zu beheben und bald ein stabiles Release anbieten zu können.

Posted in Build, config and deploy, Java EE, Java Runtimes - VM, Appserver & Cloud, Uncategorized | Tagged , , , | Leave a comment

Memory Probleme in Java – Fehleranalyse Chart

memory-analyse-methodic

Der Fehleranalyse Chart, den wir im Rahmen der Blog Post Reihe zum Thema Memory Leaks erstellt haben, zeigt typische Symptome und mögliche Ursachen im Umfeld von Speicherproblemen in der “Hotspot” Java VM an und kann zur schnelleren Fehlereingrenzung bei Speicherproblemen verwendet werden.

Die obere Hälfte zeigt typische Symptome. Zur Fehlereingrenzung sind die Symptome systematisch mit den betroffenen Speicherbereichen und möglichen Fehlerquellen und Ursachen in der unteren Hälfte verknüpft. Desweiteren sind mögliche Tools, welche zur weiteren Eingrenzung Verwendung finden können, aufgelistet (grüne Elemente).

Praktisch zur schnellen Fehleranalyse. Es sind sicherlich nicht alle typischen Probleme abgedeckt … ich freue mich auf Kommentare zu diesem Blog-Post über weitere Probleme und deren Fehlereingrenzung in der Praxis. Diese werden von mir dann natürlich gerne auch in den Chart aufgenommen. So “Leave a Reply”

Posted in Java Basics, Java Runtimes - VM, Appserver & Cloud | Tagged , , , , | Leave a comment

Schichtenarchitektur überwachen mit Spring und JUnit

Die Schichtenarchitektur einer Anwendung kann über die Projektstruktur in der IDE überwacht werden. Dies hat allerdings den Nachteil, dass unter Umständen eine Vielzahl von IDE-Projekten verwaltet werden müssen. Da dies nicht immer gewünscht ist, möchte ich eine Alternative zu diesem Vorgehen vorstellen.
Continue reading

Posted in Build, config and deploy, Java and Quality, Spring Universe | Tagged , , , , , | Leave a comment

Balsamiq Mockups 3.1

Just a few weeks after the big 3.0 release, Balsamiq published the next update: Balsamiq Mockups 3.1

This version includes a new feature called Alternates, providing a kind of branching mechanism for a single mockup. This can be useful to visualize slightly varying versions, improvement ideas or feedback without changing the original mockup. See the Working with Alternates documentation for details.

In addition, all the features that came with v3 can now be used in the Balsamiq’s Google Drive plugin.

The new release also contains built-in background music (optional), as well as several improvements and bug fixes.

Posted in Agile Methods and development | Tagged , | Leave a comment