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.
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.
Nachdem wir in den letzten Artikeln zu OAuth2 umfangreiche Grundlagen geschaffen haben, soll es hier darum gehen, wie in einer eigenen Spring-Boot-Anwendung das Login via OAuth2 Single-Sign-On über einen fremden Authorization Server geregelt werden kann.
Dazu werden wir eine kleine CRM-artige Webanwendung mit Spring Boot entwickeln, bei der man Kundenobjekte ansehen und hinzufügen kann. Das Ganze soll allerdings erst nach Anmeldung möglich sein. Diese Anmeldung soll entweder über den GitHub-Account oder über einen Facebook-Account geschehen können.
Da sich das Ganze als nicht ganz trivial herausgestellt hat, gibt es dieses Mal den gesamten Source-Code weitestgehend ungekürzt im Artikel zum Kopieren und Einfügen.
Dieser Blog-Post soll einen kurzen Überblick darüber geben, was BOMs sind, warum man diese verwenden möchte und wie dies mit Gradle funktioniert.
Was ist eine BOM?
Bei einer BOM (Bill Of Materials) handelt es sich um eine Maven POM, welche einen <dependencyManagement> Block enthält. Mithilfe von diesem können für Abhängigkeiten deren Version festgelegt werden.
Wenn es darum geht, eine Technologie auszuwählen, um eine API zu bauen, wird heutzutage oft ohne weiter zu evaluieren REST gewählt. Es gibt auch viele gute Gründe, warum REST der De-Facto-Standard für APIs ist. Es gibt jedoch Fälle, in denen auch andere Technologien einen Blick wert sind.
In diesem Artikel werden die Grundlagen zu OAuth2 und das Setup einer OAuth2-Anwendung aus den letzten Artikeln anhand eines neuen Beispiels angewendet. Das beispielhafte Java-Programm in diesem Artikel soll sich automatisch bei Twitter authentifizieren und anschließend einen Tweet versenden können. Der Benutzer kann die Authentifizierungs-Anfrage bestätigen und den Authorization Code an das Programm weitergeben, welches ihn dann ein Access-Token umtauschen kann.
