Jigsaw – Java 9

As previously mentioned here, Java 9 is coming soon, and with it comes an interesting approach called Jigsaw. It was first announced to release with Java 7, but was delayed to Java 8 and will now release with Java 9. What is Jigsaw, you think, and is it as horrific as it sounds like? Well, probably not, but it has the potential to improve the development-process of Java-Applications and Libraries a lot.

Why would I need it?

Ok let us assume, you have a big project where you develop a browser-based enterprise application. Let us say, you create two top-level-packages in this example: front-end and back-end. You want to interact between front-end and back-end only over a fixed set of well-defined interfaces, you created only for that purpose. All other classes should not be visible outside of their base package.
Currently, there is no real way to achieve that.
I mean, you could put all your classes directly in the two top-level-packages, without any sub-packages and set their visibility to package. But be honest, that would be a mess if you have thousands of classes in there without sub-packages. But as soon, as you introduce some sub-packages, you are forced to set the visibility of the interacting classes to ‘public’.
Continue reading

Posted in Did you know?, Java Basics, Java modularization | Tagged , , , | Leave a comment


After Python, Ruby, JavaScript and everyone else, Java will finally get its official Java Shell with Java 9. One of the main reason for the developers to finally introduce the Java Shell, is to lower the learning curve for initial learning. They state, that the primary reason why some schools move away from Java is the missing shell.
But the Java Shell could also be interesting for more experienced developers.

How does it work?

The Java Shell (JShell) is a REPL (Read-Eval-Print-Loop). That means, you are able to enter your code, press enter and see the result instantly. You do not need to go through the usual process where you edit the code, save the file, compile, launch and then see the result. Everything you enter will be interpreted as pure Java, except you start with a slash to enter a command.
Continue reading

Posted in Did you know?, Java Basics | Tagged , , | Leave a comment

HTTP/2 Client – Java 9

The web has changed a lot since the 90’s, so in May 2015, a new version of the HTTP-Protocol was presented by the Internet Engineering Task Force (IETF). With Java 9, the developers also updated the HTTP-API in the JDK and came up with an entirely new API for HTTP/2 and Websocket. This new API will replace the old HTTPURLConnection API, which is as old as HTTP/1.1 itself.

Problems with HTTP/1.1

With HTTP/1.1, you had many Request-Response cycles which increased the latency and loading times of webpages. Additionally, you had the problem of head-line-blocking, which means that the line of packets is held up by the first packet. Because of that, an often used approach on optimizing was to open several TCP-Connections to the server and request the elements equally distributed over the connections and use workarounds like image sprites. But these multiple TCP-Connections put some additional load on the web servers and are pretty inefficient, because TCP-Connections are expensive. The goal of HTTP/2 is, to lower latency, loading times and server load, but still being backwards compatible to HTTP/1.1.

Continue reading

Posted in Did you know?, Java Basics, Java Web Frameworks | Tagged , , | Leave a comment

Modern Web Dev Build: Entwicklung moderner Webapplikationen mit TypeScript

Mit eines der größten Diskussionsthemen im Bereich der Webentwicklung ist der Einsatz unterschiedlicher Frameworks und Tools. Die enorme Auswahl erschwert die Entscheidung für eine Technologie deutlich. Um Neueinsteigern diese Wahl abzunehmen, hat Sébastien Dubois ein Tool entwickelt, mit dem eine komplexe Technologiearchitektur innerhalb weniger Minuten aufgesetzt werden kann. Die erzeugte Infrastruktur deckt Themen wie Dependency Management, Buildautomatisierung, Testen, Codequalität, Minifizierung und Packen von Haus aus ab und ist dabei problemlos erweiter- und konfigurierbar.

Folgender Post basiert auf dem Modern Web Dev Build von Sébastien Dubois, welches unter GitHub dokumentiert ist.

Continue reading

Posted in Web as a Platform | Tagged , , , , | 1 Comment

Java 9 Top Features

Java 9 will be released in March 2017, there will be a LOT of new features and small updates. Well, here are some major features that will come with it.
Continue reading

Posted in Did you know?, Java Basics | Tagged , , | 2 Comments

SpringMVC vs. Vert.x

What is Vert.x?

Vert.x is an event-driven, non-blocking reactive application framework running on the JVM. Vert.x is polyglot, which means that it supports many different programming languages. Currently are supported: Java, JavaScript, Ruby, Python, Groovy, Scala and more. Vert.x is known for its easy scalability and lightweight architecture which results in very good performance. Vert.x uses Netty for all IO-related processes.

What is special about Vert.x?

When you deal with web applications, you usually handle every single request in its own thread. This results in a lot of threads, most of them blocked, which can create much overhead. Vert.x approaches this problem by creating a fixed number of threads (event loops, mostly equivalent to the number of available CPU cores) which handle the requests using an event-based system. This means, everything works with event handlers and callbacks and you are not supposed to do any thread-blocking work directly in those threads. Instead you register a callback to be called after the task has finished.

How does it work?

You can create so-called „verticles“ which contain your application’s main entry point. Your application can consist of multiple verticles. These verticles are executed within a Vert.x instance and managed by an event loop. The Vert.x instance is running directly on the JVM. Now let us assume that the verticle registered a listener to wait for requests.


At every loop the event loop checks if there are requests available for the verticle. If so, the event loop calls the verticle’s event handler synchronously. The event loops are managed by the Vert.x instance. Usually, you have one event loop running for each processor core with one verticle running on each event loop. But you are free to start more event loops or assign more verticles to one loop. The verticles are connected by an event bus, which they use to send and receive their data. The bus also provides an interface to communicate with each other, even across multiple Vert.x instances or in a cluster. For most usually blocking tasks you can install special busmods (e.g. a MongoDB Persistor) instead of using the usual (blocking) database connectors. If there is no busmod available, you can start worker threads which work asynchronously to the event loops. But if you have to start a worker thread for every request, you should probably use a different framework. You are not supposed to run blocking tasks synchronously, because they would slow down or even block the entire event loop.

How does it look like?

This is how Vert.x looks like with Java:

public class Demo {
  public static void main(String... args) {
    Vertx vertx = Vertx.vertx();
    vertx.createHttpServer().requestHandler(req -> {
      if (req.method() == HttpMethod.GET) {
        if (req.path().equals("/hello")) {
          req.response().end("Hello world.");

As you can see, you add a request handler to your verticle. Then this handler will be invoked by the event loop for every request. After that you filter the requests (e.g. by HttpMethod and path) and respond. You also have to start your HTTP server.

This is how Spring MVC and Spring Boot looks like:

public class Demo {
  public static void main(String... args) {
    SpringApplication.run(Demo.class, args);

  @RequestMapping(value = "/hello", method = RequestMethod.GET)
  public String helloworld() {
    return "Hello world.";

With Spring, you register your request handler by creating a method and annotate it the way you want it to work. The requests are automatically filtered for you. Spring Boot also does the server setup per default on port 8080 for you. Of course you can customize this behavior.

The difference is here that Spring Boot provides defaults which allow you an easy start and get fast results. Spring MVC combined with Spring Boot has a higher usability and an easier readability in general. Also, you do not have to understand all that is going on in the background to create your Hello World application.

What should I use?

That depends on your use case and your personal preferences. If you like annotations and are familiar with Spring, you might not need to learn Vert.x. If you need some exorbitant performance, you should consider Vert.x. Spring Boot handles every request in its own thread which might be appropriate, if you have to handle complex business logic at many requests. In Vert.x you would have to start worker threads for all this which would nullify the performance benefit. But if most of your requests are just requesting semi-dynamic or static web pages anyway, you might be better off with Vert.x performancewise. On the other hand, if you have many shared resources, you could have a very bad time synchronizing them across all your parallel processes in Spring, while Vert.x makes them easier to manage.

SpringMVC is focused on enterprise processes and enterprise applications with lower user counts. Vert.x on the other hand is designed to build your large-scale, super-scalable and distributable web applications which might have less complex business logic in them, but need to perform reliably under massive load. In Vert.x you can deploy or remove verticles dynamically at runtime from your own code to easily adjust your capacity.

If you absolutely want to use Vert.x but do not want to give up on Spring in general, there is always the possibility to integrate Vert.x with your Spring stack, so you can use all the other modules Spring provides.

Posted in Java Web Frameworks, Spring Universe | Tagged , , , , , | 1 Comment

Custom Annotation bei Spring AOP Pointcut-Definition

AOP (Aspektorientierte Programmierung) ist ein Programmierparadigma, das die objektorientierte Programmierung erweitert. Es werden Querschnittsbelange wie z. B. Caching, Security, Transaktionen und Auditierung gekapselt, die das System an mehreren Stellen benötigt. Diese Funktionalitäten werden nicht an mehreren Stellen (Klassen, Methoden) wiederholt implementiert, sondern an eine zentrale Stelle ausgelagert. Die ausgelagerte Funktionalität wird zur Compile- oder Laufzeit an den Stellen hinzugefügt, an denen sie gebraucht wird. Die Menge dieser Stellen nennt man Pointcut.

Bei der Entwicklung von Spring AOP wird folgendes Pattern für die Pointcut-Definition benutzt: execution(modifiers-pattern? ret-type-pattern declaring-type-pattern?name-pattern(param-pattern) throws-pattern?). Es ist manchmal schwierig, ein gemeinsames Pattern für alle Methoden, die gematcht werden sollen, zu finden. In so einem Fall empfiehlt sich eine elegantere Variante und zwar die Erstellung einer eigenen Annotation, wie zum Beispiel @Transactional für die Pointcut-Definition.
Continue reading

Posted in Uncategorized | Leave a comment