Fremde Java-Klassen erweitern mit Manifold: Extensions

In den letzten Artikeln hatten wir bereits über die mannigfaltigen Möglichkeiten Manifolds geschrieben. Neben einem kurzen Artikel zu den Grundlagen von Manifold hatten wir gezeigt, mit wie wenig Aufwand sich JSON-Schnittstellen über Manifold integrieren ließen. Ein anderes interessantes Feature von Manifold ist das Erweitern fremder Klassen mit eigenen Methoden und wird in diesem Artikel beschrieben.

Continue reading

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

Einfache JSON Integration in Java ohne JAXB mit Manifold

Im letzten Artikel hatten wir bereits eine Übersicht über die wichtigsten Funktionen von Manifold geliefert. In diesem Artikel der Serie soll es nun um die Möglichkeiten für die Integration von JSON-Objekten und JSON-Schemata direkt in den Java-Code gehen.

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

Manifold – Unsichtbare Code-Generierung für die Praxis

Code-Generierung ist bei einigen Entwicklern allgemein eher unbeliebt, da sie zwar meist notwendig ist, in der Praxis jedoch häufig einige Probleme mit sich bringt. Daher wird dieses Mittel im Entwickleralltag häufig nur in den Bereichen eingesetzt, in denen es absolut notwendig oder längst selbstverständlich ist. Etwa bei der Generierung von hashCode()-/equals()-Methoden in Java oder Getter und Setter in Domainobjekten.

An dieser Stelle setzt Manifold an. Denn automatische Code-Generierung, insbesondere wenn sie unsichtbar für die Entwickler im Hintergrund abläuft, kann einige Vorteile haben. So können etwa fehlende Sprachfeatures nachgerüstet werden und unnötige Fleißarbeit auf ein Minimum reduziert werden. Da Manifold jedoch über ein Compiler-Plugin arbeitet, erkauft man sich die oben genannten Vorteile durch einen gewissen Lock-In. Ein direkter Ausbau durch eine Realisierung der “unsichtbaren Klassen” im Hintergrund zu echten Java-Klassen, wie etwa bei TypeScript, wäre vielleicht für einige Features von Manifold möglich, allerdings nur in der Theorie.

Da Manifold ein recht mächtiges und umfangreiches Framework ist, wird es dazu eine ganze Serie an Blogartikeln geben.

Continue reading

Posted in Java and Quality | Tagged , , | 1 Comment

Die Zukunft von GWT: J2CL

Ursprünglich wurde das Google Web Toolkit entwickelt, um in einem nur sehr begrenzt existierenden JavaScript-Ökosystem mit sich teils stark unterscheidenden JavaScript-Implementierungen einheitlich und sicher Anwendungen entwickeln zu können.

Seit damals haben sich einige Probleme am GWT-Konzept offenbart. Da GWT einen großen Funktionsumfang hat und sich somit unter anderen um Compiler, CSS und die Widget-API kümmert, hat das Framework sehr lange Release-Zyklen.

Wenn nun Browserhersteller einige Teile ihrer Implementierung ändern oder Fehler beheben, wie z. B. hier, ist man leider aufgrund der langen Release-Zyklen dazu gezwungen, selbst einen Workaround einzubauen.

Continue reading
Posted in Java Web Frameworks | Tagged , | Leave a comment

Switch Expressions in Java 12

Java 12 bringt einige interessante neue Features, darunter auch umfassende Erweiterungen für die Kontrollstruktur switch. Spezifisch befassen wir uns im Folgenden mit bisherigen Problemen und wie diese unter anderem durch die neue Switch-Expression in Java 12 gelöst werden.

Continue reading
Posted in Java Basics | Tagged , | 1 Comment

Koloboke für schnelle Java Collections

Die normale Java-Collections API kann die meisten normalen Use-Cases wunderbar abdecken, und ist im Allgemeinen sehr gut. Leider gibt es jedoch immer wieder Sonderfälle, in denen Workarounds oder inperformante Ansätze genommen werden müssen. Koloboke ist eine der Bibliotheken, die sich genau dieses Performance-Thema zum erklärten Ziel gemacht hat.

Continue reading
Posted in Did you know? | Tagged | Leave a comment

Gradle mit UTF-8 Byte Order Mark

Während Gradle absolut wunderbar mit UTF-8 funktioniert, gibt es hier leider eine Untiefe, die einen erwischen kann, wenn die Gradle Dateien z. B. mit dem Programm “Editor” unter Windows bearbeitet werden.

C:\test>gradle build
FAILURE: Build failed with an exception.
Where:
Build file 'C:\test\build.gradle' line: 9
What went wrong:
Could not compile build file 'C:\test\build.gradle'.
startup failed:
build file 'C:\test\build.gradle': 9: only buildscript {} and other plugins {} script blocks are allowed before plugins {} blocks, no other statements are allowed
See https://docs.gradle.org/5.1/userguide/plugins.html#sec:plugins_block for information on the plugins {} block
@ line 9, column 1.
plugins {
^
1 error
Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
Get more help at https://help.gradle.org
BUILD FAILED in 1s

Plötzlich und ohne Vorwarnung funktioniert dann einfach nix mehr, nicht einmal ein vermeintlich leeres Skript kompiliert. Was ist passiert? Optisch ist kein Unterschied an der Datei zu der letzten funktionierenden Version feststellbar. Allerdings, wenn die betroffene Datei in einem Hex Editor geöffnet wird:

Anfang einer gradle.build Datei mit UTF8-BOM

Achten wir auf die ersten Zeichen in der Datei. Hierbei handelt es sich um einen UTF-8-Byte Order Mark (BOM), einen festgelegten Wert, der die Datei als UTF-8 auszeichnet. Dieses ist optional. Bei Java (und Groovy, woraus letztendlich ein Gradle Skript besteht) sollten diese jedoch weggelassen werden, da der Compiler diese nicht verarbeitet: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4508058

Wenn nun in einem Projekt dieses Problem auftritt, wie lässt sich das schnell lösen? Einige Editoren (z. B. Notepad++) erlauben es auszuwählen, ob die Datei mit BOM oder ohne gespeichert wird, und können zwischen den Varianten konvertieren.

Alternativ ist es möglich, mit Eclipse kurzfristig das Source-Encoding auf ein nicht UTF-basiertes Encoding zu stellen, womit die ersten drei Bytes wie oben im Hex Editor sichtbar erscheinen und einfach gelöscht werden können.

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