Wildfly 10 erschienen

Kürzlich ist Wildfly in der Version 10 erschienen. Er wurde schon lange erwartet, da diese Version als Basis für die kommerzielle Variante JBoss EAP 7 vorgesehen ist. Die JBoss Enterprise Application Plattform wird damit erstmals auf dem 2014 von JBoss AS in Wildfly umbenannten Open Source Application Server basieren. Redhat/JBoss bietet dann auch endlich kommerziellen Support für einen Java EE 7 konformen Server an.

Wildfly 10 implementiert das Java EE 7 Full und Web Profile, baut direkt auf der Version 9 auf und enthält dementsprechend auch alle dort veröffentlichten Funktionen wie HTTP/2 oder den eingebauten Loadbalancer. Als Besonderheit wird nun mindestens Java 8 verlangt, da man von den Neuerungen bei der Integration in die Java Laufzeit Umgebung profitieren wollte. Die aktuellen Entwicklungs-Releases von Java 9 werden ebenfalls unterstützt.

Continue reading

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

Parallel stream processing in Java 8 – performance of sequential vs. parallel stream processing

Parallel processing is all around nowadays. Because of the increase of the number of cpu cores and the lower hardware cost which allows cheaper cluster-systems, parallel processing seems to be the next big thing.

Java 8 cares for this fact with the new stream API and the simplification of creating parallel processing on collections and arrays. Let’s have a look how this works.

Let’s say myList is a List of Integers, containing 500.000 Integer values. The way to sum-up this integer values in the pre-java 8 era was done using a for each loop.

for (int i :myList)

since java 8 we can do the same thing using streams


Parallelize this processing is very easy, we just use the keyword parallelStream() instead of stream or parallel() if we still have a stream.




will do the trick. So it’s easy to spread a calculation to threads and to the cpu cores available. But as we know the overhead of multithreading and parallel processing is expensive. The question is when to use parallel-streams and when a serial stream would be better related to performance.

First of all let’s have a look what happens behind the scene. The parallel stream uses the Fork/Join Framework for processing. This means that the stream-source is getting forked (splitted) and hands over to the fork/join-pool workers for execution.

But here we find the first point to think about, not all stream-sources are splittable as good as others. Think about a ArrayList which internal data representation based upon an array. Splitting such a source is pretty easy, because is possible to calculate the index of the middle element and split-up the array.

If we have a LinkedList it’s more complicated to split the data elements. The implementation has to go through all elements from the first entry to find the element where the split can be done. So LinkedLists for example performs badly for parallel streams.


This is the first fact on parallel stream performance we can retain.

S – source collection must be efficiently splittable

Splitting a collection, managing the fork and join tasks, object creation and garbage collecting is an algorithmic overhead as well. This is only worthwhile when the work that has to be done on the cpu cores is non-trivial and/or the collection is large enough. And of course we have a lot of cpu cores.

One bad example would be the calculation of the max value of 5 integer values.

IntStream.rangeClosed(1, 5).reduce( Math::max).getAsInt();

The overhead of prepare and process the data for fork/join is so huge that a serial stream is much faster here. The Math.max function is not very CPU cost intensive here and we have less data elements.

But it’s getting more and more worthwhile when the function which is executed per element is more complex – to be exact “is more cpu intensive”. Calculating the sinus of every element instead of the max value for example.

When programming a chess-game the evaluation of every chess-move is also such an example. Many evaluations can be done in parallel. And we have a large number of possible next moves.

This is perfect for parallel processing.

And this is the second fact on parallel stream performance we can retain:

N*Q – factor “number of elements * cost per element” should be large

But this also means in reverse that the collection can be smaller when the operation per element is costlier.
Or when then operation per element is not so cpu intensive than we need a very large collection with many elements so that the usage of parallel streams pays off.

This directly depends on the third fact we can retain

C – number of CPU Cores – more is better > 1 a must have

On a single core machine parallel streams always perform worse than serial streams in cause of the management overhead. The same as with companies with many project leads and one man doing the work.

More is better – unfortunately in real world this is not correct for all cases, for example when the collection is too small and the CPU cores starts up – maybe from energy safe mode – just to find out that there is nothing to do.

And to determine wether to use a parallel-stream or not there are requirements to the per-element function as well. This is not so much a matter of performance but If parallel streams work as expected.
The function have to be …

  • …independent which means that computation for each element must not rely on or impact that of any other element.
  • …non-interference which means that the function won’t modify the underlying datasource when processing.
  • …stateless.

Here we have an example of a stateful lambda function used in a parallel streams. This example is taken from the java JDK API and shows a simplified distinct() implementation.
Set seen = Collections.synchronizedSet(new HashSet());
stream.parallel().map(e -> { if (seen.add(e)) return 0; else return e; })...

So that’s lead us the to the fourth fact we can retain:

F – the per-element function has to be independent

to sum this up


Are there some other circumstances when we should not parallelize our streams? Yes, there are.

Always think about what your per element function is doing and if this suits in the world of parallel processing. When your function is calling some synchronized functionality, then you probably would have no benefit from parallelize your stream due that your parallel streams will often wait on this synchronization barrier.

The same problem occurs when you’re calling blocking i/o operations.


And for that matter using a I/O Based source as stream is also something known to not perform well because data is read sequential, so such a source is hardly splittable.

Posted in Did you know?, Java Basics | Tagged , , , , , , , , , , , , | 1 Comment

Gradle: Unternehmensweite Einstellungen und Buildskript-Erweiterungen zentral für alle Entwickler zur Verfügung stellen

Build-Tools wie Gradle und Maven ermöglichen in Verbindung mit unternehmensweiten Repositories (Nexus, Artifactory) die unternehmensweite Auslieferung von Build-Artefakten und zentralen Bibliotheken. Das manuelle Sicherstellen der korrekten Version entfällt somit für die Entwickler, und eine zentrale Pflege der Versionen tritt in den Vordergrund.

Aber was ist mit den Buildskripten? Gerade im Gradle-Umfeld wachsen die Skripte häufig schnell an. URLs für Repositories und zum Upload der Archive, Verwaltung von Versionsnummern, Custom Tasks und das Customizen der Buildskripte sind häufig notwendig und für alle Projekte gleichermaßen vorgegeben.

Continue reading

Posted in Build, config and deploy | Tagged , , , | Leave a comment

Handling money and currencies in Java with JSR 354

Back in May 2015, JSR 354 featuring an API for handling monetary values and currencies was finally released. The specification consists of the following things:

  • An API for handling e. g. monetary amounts and currencies
  • SPIs to support interchangeable implementations
  • Factories for creating instances of the implementation classes
  • Functionality for calculations, conversion and formatting of monetary amounts

The JSR 354 project is hosted at javamoney.org where you can also find the reference implementation.

Continue reading

Posted in Java Basics, Java EE | Tagged , | 1 Comment

Cross origin XMLHttpRequests with CORS

The communication of JavaScript applications with a backend system is in most cases based on XMLHttpRequests. This allows applications to load/save/… data without navigating to another page. As most developers know, this kind of communication has a big limitation caused by the so-called “same origin policy”.
Continue reading

Posted in Web as a Platform | Tagged , , , | Leave a comment

Java EE 7 App Server – current market overview

Two years after the final release of Java EE 7 (JSR 342), this blog post will give you a short overview of the certified application servers.

As of today, 6 certified application servers have been released that support the full profile and are listed officially at Oracle.

Oracle itself provides two implementations.  The first one is the open source Glassfish Server 4 that represents the reference implementation of Java EE 7. The second one is the Weblogic Server 12.2.1 that stands for the single strategic commercially supported application server from Oracle, after the announcement in 2013 that the commercial support for GlassFish will end with future releases. Despite of this announcement, GlassFish Server will remain the reference implementation for Java EE 8 (JSR 366) that will be finalized in 2017.

Red Hat’s WildFly, the successor of JBoss AS,  represents the other open source implementation of the Java EE 7 standard. For commercial support, we are still waiting  for JBoss EAP 7 which is currently in Alpha version and will integrate WildFly 10.

IBM provides the WebSphere Application Server 8.5 with its liberty profile that represents a commercial edition. Until Java EE 6, IBM also had a free version named WebSphere Application Server Community Edition (WASCE). IBM announced that marketing for the WASCE will end in 2013, and support will be withdrawn in 2016.

The last two fully certified application servers are the Hitachi Application Server 10.0 from Japan, and the TMAX JEUS 8 which is the largest provider of enterprise software systems in South Korea.


Posted in Java EE, Java Runtimes - VM, Appserver & Cloud | Tagged , | 1 Comment

Building reliable and effective functional tests for asynchronous/dynamic/single page web applications with Selenium and JUnit (1/2) – Basics

Selenium is a well established tool for browser automation and functional tests of web applications. The process to build reliable functional tests got harder since the advent of Web 2.0 applications that dynamically change the content of a page. Dima Kovalenko describes the main problem as follows.

Test automation was simpler in the good old days, before asynchronous page loading became mainstream. […] Now, an element might be missing for several seconds, and magically show up after an unspecifi ed delay. [1]

How can you build reliable and effective functional tests for this kind of applications?

Continue reading

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