JVM

Im Fokus: Projekt Valhalla

Projekt Valhalla [1] ist ein sehr umfangreiches Projekt, das Oracle bereits im Jahr 2014 gestartet hat. Aktuell gibt es bereits den zweiten Prototyp, am dritten wird gearbeitet. In diesem Artikel erläutern wir die Beweggründe hinter dem Projekt sowie Lösungsansätze und den aktuellen Stand.

Rekordverdächtig strukturiert: Ein Blick auf JEP 359: Java Records

Datenklassen, also Java-Klassen, deren einziger Zweck darin besteht, Daten zu halten und diese über Getter und Setter zugänglich zu machen, gehören in vielen Softwareprojekten zu den größten Sammelstellen von Boilerplate-Code. Für jede neue Klasse jeweils Konstruktoren, die Methoden equals, hashCode und toString und für jedes Feld noch einen Getter und einen Setter zu erstellen, ist für viele Entwickler eine verhasste Zeremonie geworden – sofern sie nicht direkt Bibliotheken wie Lombok einsetzen, um dieser zu entgehen. JEP 359 soll Abhilfe schaffen.

Das eierlegende Truffle-Schwein: Neue polyglotte Programmierung auf der JVM

Viele, die im Java-Umfeld unterwegs sind, werden von ihr gehört haben: der sagenumwobenen GraalVM. Diese „magische“ neue Virtual Machine für Java soll vor allem für blanke Performance sorgen, indem sie den Java-Bytecode in nativen Code kompiliert. Dadurch fällt insbesondere der Start-up-Overhead weg, da weite Teile der Initialisierung bereits vom Compiler erledigt werden. So oder so ähnlich ist es vielerorts zu lesen. Doch das ist bei weitem nicht das einzige Feature, das Oracle der GraalVM gegeben hat. Hinzu kommt, dass sie zu nichts weniger das Potenzial hat, als eine neue Ära der polyglotten Programmierung auf der JVM einzuläuten. Die Rede ist vom Truffle API, einem generischen Framework zur Implementierung von Interpretern.

Deep Learning: Training von TensorFlow-Modellen mit JVM-Sprachen

Zwar gibt es mit Frameworks wie DL4J mächtige und umfangreiche Machine-Learning-Lösungen für die JVM, dennoch kann es in der Praxis vorkommen, dass der Einsatz von TensorFlow notwendig wird. Das kann beispielsweise der Fall sein, wenn es einen bestimmten Algorithmus nur in einer TensorFlow-Implementierung gibt und der Portierungsaufwand in ein anderes Framework zu hoch ist. Zwar interagiert man mit TensorFlow über ein Python API, die zugrunde liegende Engine jedoch ist in C++ geschrieben. Mit Hilfe der TensorFlow-Java-Wrapper-Bibliothek kann man deshalb sowohl Training als auch Inferenz von TensorFlow-Modellen aus der JVM heraus betreiben, ohne auf Python angewiesen zu sein. So können bestehende Schnittstellen, Datenquellen und Infrastruktur mit TensorFlow integriert werden, ohne die JVM zu verlassen.

Java zu statisch? So wird Java dynamischer!

Obwohl Javas strenges Typsystem Entwicklern dabei hilft, Fehler beim Coden zu vermeiden, beschränkt es natürlich auf der anderen Seite deren Flexibilität, die die Nutzung von dynamischen so attraktiv macht. In seiner Session von der W-JAX 2018 gibt Rafael Winterhalter, Software Consultant bei Scienta, eine Einführung in die Codegenerierung zur Laufzeit und erklärt, wie man dies auf der Java-Plattform nutzen kann.

Java in der Cloud: Raus mit dem Alten und rein mit dem Neuen

Im Laufe des letzten Jahres hat sich in Java, der JVM und dem Java-Ökosystem einiges getan. Doch es gibt noch so viel mehr zu tun, sagt Steve Poole (IBM) und zeigt in seiner Session von der W-JAX 2018, die wirtschaftlichen und technischen Kräfte, die die Entwicklung von Java vorantreiben. Außerdem wagt er einen Blick über den Tellerrand und erklärt, wie sich Java für die Cloud bereitmacht.

Groovy vs. Kotlin – Die JVM-Sprachen im Vergleich

Die JVM ist ein großer Spielplatz, auf dem sich deutlich mehr Sprachen tummeln, als einzig und allein Java. Zwei bekannte Vertreter dieser JVM-Sprachen sind Groovy und Kotlin. Doch welche der beiden JVM-Sprachen ist die bessere? In ihrer Session auf der W-JAX 2018 wagen Jochen Kraushaar und Matthias Merdes den Vergleich. Sie sprechen über die Vor- bzw. Nachteile der Sprachen und zeigen ihre Unterschiede auf.

Consumer-driven Contracts mit Spring

In verteilten Systemen müssen Komponenten über externe Schnittstellen kommunizieren. Consumer-driven Contracts stellen einen speziellen Fall von Integrationstests dar. Sie ermöglichen es, bereits in der Entwicklung Schnittstellenverträge abzusichern, ohne dabei die beteiligten Services starten und End-to-end-Tests durchführen zu müssen. Für Spring-Entwickler stehen mit Pact JVM und Spring Cloud Contract gleich zwei Frameworks zur Verfügung, um solche Tests umzusetzen. Dieser Artikel soll bei der Entscheidung helfen, welches Framework man einsetzen möchte.

  • 1
  • 2