Blogeinträge aus dem Jahr 2015

8. April 2015 Bereit für das kommende Google-Update, und noch viel mehr

Der Suchmaschinen-Riese Google ändert mal wieder seinen Algorithmus, dieses Mal um mobile Geräte einen besseren Inhalt anzuzeigen. Wer eine Website nach klassischem Verfahren "Desktop-only" besitzt, wird bald über wegbrechende Erstbesucher fallen. Nur gut, dass ich meine Seite geupdated habe, sodass hier das blaue Licht auch blau leuchtet ;)

Was hat sich geändert?

  • Mobile first Ein von mir schon länger verfolgtes Ziel war es ein vollständiges RWD (Responsive Web Design) für meine eigene Website zu erstellen, ohne dabei auf die gängigen Frameworks zurückgreifen zu müssen. Nicht nur, dass ich dadurch mehr lerne, der Overhead an Boilerplate-Code fällt gleichzeitig weg. Ich wundere mich immer, wieso eine 200KB große Bibliothek eingebunden wird um nur EIN Element davon zu verwenden, daher ist es manchmal besser alles from-scratch zu machen.
  • Gültiges SSL-Zertifikat Da CACert leider nicht als mehr valide Zertifizierungsstelle akzeptiert wird, musste ich mir eine funktionierende und nicht zu teure Alternative zu einem Domain-Zertifikat suchen und habe es bei RapidSSLOnline gefunden. Das DV-Zertifikat für 2 Jahre hat mich gerade mal $18 gekostet, ging schnell und jetzt kann ich meinen Auftritt auch verschlüsselt anbieten. Durch den Einsatz eines aktuellen Apache-Webservers habe ich sogar eine recht gute Wertung von Qualys SSL Labs, welcher nicht nur für die Sicherheit der Informationen relevant ist, sondern auch durch Google insgesamt positiv beeinflusst wird.
  • Verbesserte Navigation Sagen wir es doch mit wenigen, aber harten und treffenden Worten: Die alte Navigation war grausam und absolut "nicht-intuitiv bedienbar". Dies wurde nun durch eine Umstellung auf eine andere HTML-Struktur gelöst und sieht jetzt sogar durch den Einsatz von SVG-Grafiken um einiges besser aus.
  • Neue Seitenstruktur Bei der Anpassung der Navigation habe ich auch eine bessere Seitenstruktur umgesetzt. Diese Seite soll sowohl als Portfolio als auch Projektseite funktionieren, daher war es notwendig diese Bereiche auch zu trennen. Zusätzlich zu der Ordnung bietet mir dies nun die Möglichkeit mehr Unterpunkte aufzunehmen als dies noch mit der alten Struktur oder Navigation möglich war.
  • Socializing Dieses Mal habe ich es fertig, meine Website versteht das Modewort "social". Für den Fall, dass jemand einen Inhalt teilen möchte, der kann dies nun mittels jewiligen Share-Button per Klick auf das Networking-Icon machen. Facebook werde ich jedoch nicht anbieten, da dieses Netzwerk IMHO zu viele Informationen bereits über seine Nutzer und auch seine nicht-Nutzer besitzt, wie auch in den unzähligen Presseberichten zu lesen ist. Google+ habe ich leider auch nicht reingeworfen, da ich hier irre Probleme mit den Content-Security-Policy-Regeln hatte bzw. diese für zu umfangreich erachte. Wer wirklich will, der kann die URL eh über andere Wege teilen.

Alles in allem bin ich gespannt, was Tante Google und Co. nun mit meiner Seite machen, die Bezeichnung Portfolio hat meine Seite umso mehr verdient.

Jeder Website-Betreiber sollte für vernünftiges Ranking immer entsprechende URLs mittels Redirect einrichten, sonst gehen die User flöten. Mal schauen ob ich alle erwischt habe ;)

19. Mai 2015 Mitentwickler des JavaFX-Maven-Plugins, Gulp und ein bisschen Ranting

Seit dem letzten Update hat sich einiges getan, hier die Ereignisse:

  • JavaFX-Maven-Plugin Wer hätte das gedacht? Ich werde ein Baustein in der Java-Welt, und das auch noch ganz unverhofft. Ich darf mich seit dem 21. April 2015 zu den offiziellen "Mitarbeitern" am JavaFX-Maven-Plugin hinzuzählen! Wie der Name bereits sagt, handelt es sich hierbei um ein Maven-Plugin, welches für die Entwicklung von JavaFX-Projekten anfangs entwickelt worden ist, da der zur Verfügung stehende JavaFX-Packager nur mittels Ant erreichbar ist. Wer jedoch seinen Build-Prozess auf Maven setzte, musste hier entweder mit dem Ant-Plugin für Maven seine pom.xml aufblähen, oder aber nach dem erfolgreichem Build immer diverse Skripte laufen lassen. Dank des findigen Entwicklers Daniel Zwolenski konnte hier jedoch eine Lücke geschlossen werden, welche die beiden Welten "Maven" und "JavaFX" miteinander verbunden hat.
    Soviel zur Historie, doch aus Zeitmangel und ein paar anderen Gründen ist das mittlerweile auch im Open-Source-Bereich eingesetzte Maven-Plugin etwas in die Tage gekommen, die Bug-Meldungen hatten sich angesammelt und Pull-Requests wurden nicht mehr bearbeitet. Doch wen wundert es, wenn der tägliche Beruf und die Familie die spärliche Freizeit schon genügend ausfüllen, da bleibt kaum Luft für solche freiwilligen Projekte.
    Zur Unterstützung sind nun Maxim Dobryakov und ich (Danny Althoff) eingesprungen, um dem Plugin auch unter Java 8 und folgenden Versionen den Glanz zurück zu bringen, welchen es sich bereits verdient hat.
  • Ich mag kein anfälliges CMS Schaut man sich auf einschlägigen Seiten um, so kann man eine Unzahl an offenen Sicherheitslücken, Bugs und anderer digitaler Löcher in diversen Content-Management-Systemen schön der Reihe nach gelistet bekommen. Je mehr Systeme für den Betrieb notwendig sind, umso mehr Probleme holt man sich auf den Server. Doch wieso braucht man ein CMS, wenn statische Seiten ausreichend wären? Dynamische Inhalte liefern Auslieferungszeiten jenseits von gut und böse, und wenn man dann noch verlangt, dass es bei schlechter Internet-Anbindung bitte auch ordentlich funktioniert, dann ist richtig Schluss! Ich halte nichts von einem CMS, was von außen mit Funktionalitäten strotzt, aber ebenso auch von außen bedienbar ist, daher habe ich mich für eine andere gängige Strategie entschieden, wie es auch damals oft eingesetzt worden ist: die Statische Generierung.
    Durch den Einsatz von dem TaskRunner Gulp in Kombination mit Markdown, Swig und Node.js habe ich meine Website in Templates, Rohdaten und diversen statischen Elementen zerlegt, welche anhand von den in Markdown geschriebenen Artikeln oder Seiten zusammengebaut werden, ohne jedes Mal alle Dateien von Hand anzupassen. Dies hat mehrere Vorteile: kein Content-Management-System (und somit hier keine Angriffsfläche), immer-gleiche Seitenaufbauten, automatisch generierte Navigation und ganz viel neuem Knowhow.
  • Zugriffe, Statistiken und OXID Wenn ich den Google-Webmaster-Zahlen trauen soll, dann habe ich durch das Suchmaschinen-Update von Google (hehe, Mobilegeddon) ein paar Besucher verloren, allerdings stört mich dies bisher wenig. Es ist weiterhin interessant zu sehen, wie mein OXID-Modul so rankt, doch bin ich weit davon entfernt dieses Produkt detailgenau in seiner Tiefe zu verfolgen. Der tägliche Besuch des Bugtrackers wird aber erstmal bleiben, da ich natürlich am laufendem Geschäft nichts ändern kann. Zusätzlich scheint es einen immerwährenden Bedarf zu geben, Konzeptionsschwächen oder Designfehler eines OXID eShop-Systems durch ein Modul zu umfahren. IMHO sollte hier aus den gemachten Fehlern gelernt werden und von Grund her der Workflow überdacht werden, ein kompletter Code-Review würde hier sehr gut tun, aber wer soll das schon bezahlen ... und die Dienstleister müssen ja auch noch was zu tun haben.

Big thanks to "maxd", because he included me when requesting the original developer of the javafx-maven-plugin for being official contributer! I would have never thought about it ;)

8. Juli 2015 Projekt "Named Binary Tag For Java" auf Maven-Central

Seit dem letzten Update hat sich einiges getan, hier die Ereignisse:

  • nbt4j über Maven-Central und Github Nachdem ich das Projekt ein wenig habe liegen lassen, ist es nun sogar offiziell über die Kanäle Maven-Central und Github verfügbar. Die Anpassungen in der POM zum Publizieren nach Maven-Central waren nicht wirklich schwierig, sie haben sogar dazu beigetragen, dass ich die Dependencies aktualisieren konnte.
  • Sommer, Sonne und mehr Freizeit Da die Hitze und das gute Wetter dazu verleiten, auch mal einen Schritt nach draußen zu machen, und es draußen wirklich eine Menge gibt, was man anstellen kann, werden meine Projekte JavaFX-Maven-Plugin und dessen Dokumentation etwas langsamer weitergehen, als vielleicht gedacht.
    Aber genau das ist das Zeichen für eine gute Work/Live-Balance, bei der man nicht nur Arbeitet um zu überleben, sondern auch mal lebt und vom täglichen Stress entfernt.
  • Was ist nur mit den Google Webmaster-Tools los Nachdem ich meine Website umgestellt habe, um dem Mobile-geddon auszuweichen, scheint keine andere Website mehr zu mir zu verlinken ... was ich für höchst unrichtig erachte. Es scheint als wäre das Tool so langsam richtig kaputt, das Update von Google hat wohl richtig viele Daten verworfen, weil die Seiten, von denen verlinkt wird, nicht auf "Mobile" umgestellt worden sind.
    Tracking wird es auf meiner Website nicht (mehr) geben, zu wenig bringt mir dieses Feature und ist den zusätzlichen Aufwand nicht wert.

26. Juli 2015 Neue Version des JavaFX-Maven-Plugins released

Kurzes Update, große Wirkung!

Der Sprung von Version 8.1.2 zu Version 8.1.3 mag sich in kleiner Nummer unterscheiden, bringt jedoch eine Menge neuer Features und vor allem wichtige Bugfixes mit sich, gerade die Erstellung eines neuen Keystores war mit der Vorversion nicht mehr möglich.

Das Projekt lebt wieder und es ist mir nun auch möglich neue Versionen zu releasen, hierfür hat Daniel Zwolenski alles in die Wege geleitet, vielen Dank nochmal von meiner Seite.

Appropo "Seite", die Website von Zen Java wird auch nicht mehr lange auf sich warten lassen. Aktuell bin ich durch meine tägliche Arbeit und das bisschen Freizeit, das ich genießen kann, weniger erfolgreich dazu gekommen weiterzubauen, aber die nächsten Tage sehen hier sehr Erfolg versprechen aus.

Ein großes Problem war hier die Erstellung einer JavaFX-Applikation ohne Integration in den Maven-Lifecycle, dies wurde nun behoben, sodass man nun einfach per mvn install nicht nur sein Projekt compilieren, sondern auch den Installer erstellen lassen kann. Hier ein kleines Konfigurations-Beispiel:

<plugin>
    <groupId>com.zenjava</groupId>
    <artifactId>javafx-maven-plugin</artifactId>
    <version>8.1.3</version>
    <configuration>
        <mainClass>com.zenjava.test.Main</mainClass>
    </configuration>
    <executions>
        <!-- create jfx-jar, required before build-native -->
        <execution>
            <id>create-jfxjar</id>
            <phase>package</phase>
            <goals>
                <goal>build-jar</goal>
            </goals>
        </execution>
        <!-- create native installer -->
        <execution>
            <id>create-native</id>
            <phase>package</phase>
            <goals>
                <goal>build-native</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Aktuell ist die neue Version bereits über Maven-Central verfügbar, es wird aber noch etwas dauern, bis diese Version auch bei mvnrepository gelistet wird.

25. September 2015 It's the JDK! Bug im Native-Launcher unter Linux/Ubuntu von Java(FX) 8

Im Mai trudelte ein unscheinbarer Bug-Eintrag bei Github bezüglich des nativen Launchers unter Ubuntu ein, in der Konsole war etwas ähnliches wie das hier zu sehen:

awesome-javafx-app-1.0-SNAPSHOT No main class specified
awesome-javafx-app-1.0-SNAPSHOT Failed to launch JVM

Doch da hier leider kein Test-Projekt verfügbar war, und auch sonst kein weiteres Feedack dazu gekommen war, wurde das Ticket entsprechend geschlossen. Ein wenig später, gegen Ende Juni, hatte Jens Deters mich mit dem gleichen Problem nochmal per Mail angeschrieben, aber leider hatte ich weiterhin kein entsprechendes Szenario zur Reproduzierbarkeit.

Als dann jedoch das Ticket wiederbelebt wurde von Stefan Helfrich nochmalig ein Fehler reported, zum Glück dieses Mal auch mit einem Beispiel, wo dies reproduzierbar war, wurde ich etwas nervös, dass hier etwas Größeres verborgen liegt! Hier nochmal der Appell für alle Entwickler, die einen Bug finden: bitte macht uns das Leben leichter und erstellt ein kleines Projekt, das den Fehler reproduzierbar erzeugt, denn sonst findet man den eigentlichen Fehler nie.

Da ich aktuell nur unter Windows meine JavaFX-Applikationen entwickle, bin ich mit diesem Problem nie konfrontiert gewesen. Also erstmal eine VM mit VirtualBox aufziehen und ein Ubuntu installieren, dann nochmal schnell den Link für das Oracle-JDK unter Debian/Ubuntu rauskramen und Szenario nachstellen. Tatsächlich! Der Fehler ist reproduzierbar! Unglaublich ...

Okay, ist bestimmt nur irgendwie eine Abhängigkeit, die noch zu viel war, also erstmal das Projekt bereinigen. Doch Fehlanzeige, der Fehler blieb.

Direkt nach dem Reproduzieren erstmal im Log von ein paar Fehlermeldungen fehlgeleitet worden (ich hatte ja noch immer den Gedanken, dass hier die Main-Klasse nicht richtig gesetzt worden wäre, oder aber mit den neueren Versionen ein neues zu füllendes Feld hinzugekommen ist). Doch dann hab ich aus Neugierde mal mein eigenes JavaFX-Programm unter Ubuntu kompiliert und ausgeführt ... und es hat ganz normal funktioniert (somit konnte es schonmal kein Problem der nicht-gefüllten Felder oder Dependencies sein).

Der Unterschied war in der Konfiguration des javafx-maven-plugins ansich nur die <appName>-Einstellung.

Seit Java 8 Update 40 gibt es eine neue Version des sogenannten Nativen Launchers, dieser ermittelt anhand des eigenen Dateinamens den Pfad zu der Konfigurationsdatei, in der die Meta-Informationen zur Java-Applikation und dessen Classpath enthalten sind. Doch leider hat sich hier ein Denkfehler eingeschlichen: wenn der Programmname einen Punkt enthält, funktioniert der Algorithmus nicht mehr für Linux-Systeme (z.B. Ubuntu).

Die Jagd zwischen Java-Sourcecode, der Sprung zum nativen Launcher (sowohl die C-Version, als auch die aktuell verwendete C++-Version) und dann durch diverse Klassen- und Header-Files war spannend und sehr aufschlussreich und hat dazu geführt, dass ich für das Maven-Plugin einen Workaround eingeführt habe.

Da leider das JavaFX-JIRA abgeschaltet worden ist bzw. ins Oracle-System übertragen wurde, konnte ich diesen Bug somit nicht mehr über den mir bekannten Weg reporten. Zum Glück ist der javafxpackager in javapackager umbenannt worden, also ab ins normale Oracle-Java-Bugsystem, und dann auch direkt zu OpenJDK.

Bin mal gespannt, was daraus wird! Helfen konnte ich damit bereits den Nutzern von dem Projekt MQTT.fx, bei dem mittlerweile ein paar Bugreports eingegangen waren.

Es ist erstaunlich, in welch ein Netzwerk ich durch meine Arbeit an diesem Maven-Plugin geraten durfte, es macht riesigen Spaß mitzuerleben, was für eine wichtige Arbeit man hier durch kleine Änderungen leistet.

26. November 2015 Es wird kalt, doch die Bugs sind noch warm! Doch das JavaFX-Maven-Plugin bleibt heiß!

Ich gebe zu, ich mache von einem SDK nicht regelmäßig ein Update, so auch beim Oracle JDK. Umso verwirrender ist es dann, wenn man doch einmal updated und sich dann "Dinge ändern", zum Beispiel das Dateiformat in dem die Konfigurationen der nativen Launcher gespeichert werden. Vorher: Property, seit Java 8 Update 60: INI ... und wieso ist das so tragisch? Seht selbst:

Vorher:

app.runtime=
app.mainjar=someSpecialProject-jfx.jar
app.version=1.0
app.id=de.dynamicfiles.projects.someSpecialProject
app.preferences.id=de/dynamicfiles/projects/someSpecialProject
app.identifier=de.dynamicfiles.projects.someSpecialProject
app.mainclass=de/dynamicfiles/projects/someSpecialProject/Launcher
app.classpath=lib/javaee-api-7.0-SNAPSHOT.jar;(...removed...)

Nachher:

[Application]
app.name=someSpecialProject
app.mainjar=someSpecialProject-jfx.jar
app.version=1.0
app.preferences.id=de/dynamicfiles/projects/someSpecialProject
app.mainclass=de/dynamicfiles/projects/someSpecialProject/Launcher
app.classpath=lib/javaee-api-7.0-SNAPSHOT.jar;(...removed...)
app.runtime=$APPDIR\runtime
app.identifier=de.dynamicfiles.projects.someSpecialProject

[JVMOptions]

[JVMUserOptions]

[ArgOptions]

Na, das Problem gefunden? Nein, es ist aber auch trivial! Ich zeig es euch mal, vorher: app.runtime= und jetzt: app.runtime=$APPDIR\runtime ... kann manchmal so einfach sein.

Normalerweise kann man durch die entsprechende Konfiguration das gebündelte JRE-Paket deaktivieren, sodass das lokal installierte Java verwendet wird:

<configuration>
    <mainClass>com.zenjava.test.Main</mainClass>
    <bundleArguments>
        <runtime />
    </bundleArguments>
</configuration>

Der Vollständikeit halber: in dem ANT-xml würde man folgendes hinzufügen:

<fx:platform basedir="" />

Wenn allerdings wegen des Dateiformat-Wechsels diese Angaben falsch verarbeitet werden, darf man sich nicht wundern, wenn das Programm nicht mehr funktioniert, obwohl man am Code oder der Konfiguration nichts geändert hat. Es hat mich nicht gewundert, dass bereits auf StackOverflow dazu Fragen aufkommen.

Möglicher Workaround:

  • aktuelles JavaFX-Maven-Plugin verwenden
  • die ANT-Konfiguration erweitern: <fx:bundleArgument arg="launcher-cfg-format" value="prop"/>

Ich warte noch immer, dass Oracle diesen Bug bestätigt, die Tests von OpenJDK/OpenJFX zeigen zumindest keine Warnlampe, hier wird aber auch nicht der Inhalt geprüft, sondern lediglich, ob etwas drin ist. Ich warte also gespannt auf Feedback. (Update 27.11.2015: scheinbar habe ich nur noch keine Mail bekommen, aber der Bug ist nun offiziell, und bereits gefixt für Java 8 als Backport und Java 9)

Es sind noch viele andere Dinge in die neue Version eingeflossen, so zum Beispiel die Möglichkeit einen oder mehrere "Secondary Launcher" erstellen zu lassen. Genaueres kann man aber in den RELEASE-Notes, oder aber dem Changelog nachlesen. Einen Blick in die Test-Projekte kann ich auch immer empfehlen, gerade um neue Features bzw. deren Benutzung zu finden.

work in progress