The HTTP/2 specification was finished by the end of 2015 and is the first significant protocal update since HTTP1.1, which was released in 1997.
HTTP/2’s main goals are shortened loading times and decreased latency. Additionally, performance tweaks that are currently used for HTTP1.1 (domain sharding, image sprites,…) ought to be obsolete.
The browser and web server support is already quite good and Java delevopers can start to write HTTP/2 clients.
Let’s have a look at the concepts of HTTP/2 and how Java developers can use them.
Jede Anwendung hat heutzutage ein Logfile oder speichert das Log in einer Datenbank. Häufig werden diese Logfiles erst dann ausgegraben, wenn es ein Problem gibt. Dafür benötigt man jemanden, der sich mit den Logfiles auskennt und die relevanten Daten schnell findet. Besonders bei Logfiles, die sich von der Größe her im Gigabytebereich befinden, kann dies zum Problem werden. Dabei stecken in den Logfiles nicht nur die Information über potenzielle oder aufgetretene Probleme, sondern häufig auch businessrelevante Details über die Nutzung eines Service. Es wäre hilfreich, diese Gigabyte an gesammelten Logdaten auswerten zu können, ohne jede Zeile einzeln durchlesen zu müssen.
Gradle 3.0 wurde vor einigen Tagen veröffentlicht.
Wieder gibt es spannende Neuerungen und Verbesserungen. Hier meine persönlichen Highlights:
For controlling and managing processes on your operating system, Java provides the ProcessAPI. But the API lacks some key functionality, which makes handling with processes in Java a mess. With Java 9, this API will get a considerable update. What this means, what the benefits are and what it looks like is discussed in this article.
What are new features of the ProcessAPI?
The primary goal of the developers is, to make it easier for you to manage processes on your operating system. They start with giving you the ability to enumerate the system processes via the updated API (no hacky solutions anymore). That means, you can get different properties for each process, e.g. the PID, the process name, the user who started it, the path of the process, resource usage, etc. It is also planned, to make it easier to deal with process trees, especially destructing entire process trees and managing processes with over 100 sub-processes. To do so, it is planned to multiplex their output streams into one output stream, so you do no longer have one thread per monitored process listening for its output stream.
Garbage Collection is a very important issues and often one of the reasons, why you cannot deliver your non-functional performance requirements. Finding the garbage collector which fits your purpose best is not always an easy task. Some developers do not even care about the selection of their garbage collector. Especially for those, the change coming with Java 9 will affect their applications performancewise.
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’.
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.