JavOSize – an early first look at it – a new rising star of Java profilers and performance tools?

JavOSize is a young company bringing a new performance tool to the Java world. The command line interface version is absolutely free of cost, a commercial graphical user interface version will be available soon. And JavOSize thinks about putting the source code of the core system under an open-source license in the future.

A look at the feature list reveals two interesting features: First of all, hot replacement of code changes after a bug is found is supported. Plus you can record and save the steps for finding common performance issues to recipes which can be replayed later.

Continue reading

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

Erstes Groovy-Release unter der Schirmherrschaft der Apache Foundation

Gerade ist die Version 2.4.4 von Groovy erschienen. Dieses Wartungs-Release bringt zwar keine nennenswerten Neuerungen mit, es ist aber das erste Release unter der Schirmherrschaft der Apache Foundation und damit ein neuer Meilenstein in der Post-Pivotal-Ära. Im März diesen Jahres war Groovy im Inkubator der Apache Software Foundation akzeptiert worden, nachdem Pivotal die Unterstützung für Groovy und Grails überraschend aufgekündigt hatte. Zudem hat auch noch Groovys bisherige Hosting-Plattform Codehaus ihren Dienst eingestellt. Der Entscheidung für die Apache Foundation war eine längere Diskussion über die Wahl des neuen Zuhauses vorausgegangen. Ursprünglich waren noch die Eclipse Foundation und die Software Freedom Conservancy im Gespräch gewesen.

Obwohl 2.4.4 nur ein Bugfix-Release ist, sollte man dringend auf diese neue Version aktualisieren, insbesondere wenn man in seinem Projekt mit den Java Serialisierungsmechanismen arbeitet. Es wurde nämlich die 0-Tage-Schwachstelle behoben, die im ungünstigen Fall das Einschleusen von Schadcode ermöglicht.

Weitere Informationen kann man der Ankündigung auf der Mailingliste und den Release Notes entnehmen.

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

Optional in Java 8

Das Behandeln von Null-Werten kann in Java sehr lästig sein. Zu leichtsinniger Einsatz der Null-Referenz hat unangenehme Laufzeitfehler zur Folge. Aber es ist Besserung in Sicht: mit Java 8 hielt nun endlich die Klasse Optional Einzug in die Klassenbibliothek. Bisher konnte man nur durch das Einbinden von externen Bibliotheken (z. B. Guava) mit Optional-Typen arbeiten.
Continue reading

Posted in Java and Quality, Java Basics | Tagged , , | Leave a comment

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