Showing posts with label Java. Show all posts
Showing posts with label Java. Show all posts

Wednesday, 3 January 2018

Big Releases and Handovers in the JVM World

Happy New Year everyone! Hard to believe it's already 2018, and I'm already 4 months into my ThoughtWorks journey. As they say, time flies...

Anyway, the second half of 2017 saw several news I felt quite excited about in the JVM space:

August: Ceylon handed over to the Eclipse Foundation

The Ceylon programming language has intrigued me ever since I came across it several years ago: Compile-time nullsafe programming, union types, functions as first-class citizens, a thought-through module system, can be compiled for the JVM as well as different JavaScript runtimes and (for a little over a year now) native Android. It targets pretty much the same "demographic" as JetBrains' better known Kotlin. I'm hoping that this handover will help resolve what in my mind has been Ceylon's biggest issue over the years - the lack of marketing. Until this day, I cannot understand why RedHat have never given it a real commercial push.
Currently, the Ceylon community is mostly busy with reworking the codebase so that it aligns with the foundation's guidelines, but I'm looking forward to the opportunities that will arise once this phase is completed.

September: JUnit 5 officially released

I've been using the various JUnit 5 milestone releases in my projects for over a year now, and I must say I'm very happy. A revamped extension model, finally the use of Java 8's language features including the very intriguing Dynamic Test concept. If you've ever worked with JUnit's Theories: It's the same idea, but employing the full power of the JDK (and with the new extension model, you don't need to limit your test to a single runner anymore). I've used it with Maven and with Gradle, it works flawlessly. Also, Hamcrest matchers are no longer included in the standard JUnit library, acknowledging the fact that there are alternatives e.g. AssertJ (which is prominently featured in ThoughtWorks' latest Technology Radar) out there. The project has learned its lessons.
Oh, and did I mention? If you (rightfully) feel rewriting your existing tests in Java 5 style is a lot of work, you can leave them as they are - or apply some tooling help: My IDE of choice (Intellij IDEA) offers a refactoring/code inspection that will help with "simple" tests. There is also a Java-based tool on GitHub which I haven't tested myself.

September: Oracle to transfer ownership of Java EE to the Eclipse Foundation

Others must have suspected this much earlier, but I've got to admit that these news struck me out of nowhere. My beloved Java EE platform will be handed over to the Eclipse Foundation which rebrands it as Eclipse Enterprise for Java (EE4J). There has been increasing criticism of the platform in recent years: Too bulky, not enough innovation (or velocity in the same), not fit for the cloud etc. While I consider some of the arguments exaggerated, they're not totally off. There are reasons for things like the MicroProfile to emerge - which is (probably not at all coincidentally) run by the Eclipse Foundation as well. Having both of these under the same governance will hopefully benefit us guys in the trenches.

September: JDK 9 officially released

Only a year late compared to the original announcement. Well, at least we've finally got modularity that people have been talking about since IIRC Java 6 days. In fact, it's such an intriguing concept that there's actually a book only devoted to this topic. But there's more:
  • The JShell is a long overdue REPL tool which allows developers to quickly test code snippets without having to write a class wrapper. This will enable us dinosaurs to play around with statements and unfamiliar APIs much in a similar way to what JavaScript developers have been doing in the browser console for years.
  • The Collections API receives methods in the style of List.of("A", "B", "C") for creating immutable Lists/Sets/Maps/... on the fly. Until now, we had to rely on Google's Guava library for this feature.
  • I registered some excitement about the new Process API. Although I see no personal benefit on the horizon, I can imagine certain projects that will happily welcome these new capabilities.
  • The Javadoc tool can now generate HTML5 code. Starting with the next major version, this will be default behaviour.
These features are only the ones that I myself found particularly interesting. I know there's stuff "under the hood" (e.g. GC changes) and I'm also aware of the supposedly improved JavaScript support. However, I can't comment on either of these due to my lack of practical knowledge.
Compared to the Java 8 release, I feel a lot less excited. Nevertheless, it's great news that this release has been completed.

December: Effective Java, 3rd Edition published

I had been wondering about this since the Java 8 release: Will Josh Bloch go back to his invaluable piece of work one more time and incorporate the new features? Well, he did. Not only that, he even added Java 9 specific items. I haven't bought the new edition yet, but I will very likely do so pretty soon. Bloch's book should be standard material for any half-way serious Java developer. I remember reading the 2nd edition years back and experiencing quite a few "Aha" moments, and I'm expecting the same from this much-awaited update. Like only very few developer books, this is actually a good "read-only" piece - read the item and remember it when necessary. I found for myself that I didn't need to type the code examples in order to understand them.

That's all for this time. I'm wishing everyone a great start into 2018. May it be at least as good as (if not better than) 2017 for all of you!

Friday, 26 February 2016

JavaFX with Spring (and a few other technologies...)

A few weeks ago I was asked to develop a little software that would solve a real-life issue: A teacher with a worldwide audience, who regularly sends out standard emails reminding his listeners of the next lesson which includes dates and times in different places around the world, asked for a way of reducing the time he spends on creating these emails. So far, he had used one of the many websites out there to convert the date and time in his timezone into the respective dates and times around the world, but always only one at a time - and then copied the results into a standard text (again, obviously, one by one). Due to the mass email service he uses, calendar invites were not an option.
So I spent some time researching and to my own surprise didn't find a free service or software which would help reduce his worktime. Thus, I wrote one myself. The result is visible on my GitHub account. In this post, I'd like to give an overview of how I used what I consider the main technologies for this little project:

JavaFX

No big surprise here, this is the only choice you should make nowadays when using Java for desktop development. Maybe it's the fact that I'm old-school, but I just did everything in pure Java without any FXML. Comes more natural to me. The UI does the job, but can certainly use some improvement - in particular the ZoneIdSelectionDialog. It's way too large and lacks a nice structure. If anyone has some ideas how to improve this, please go ahead and fork me.

Spring

It's a Java SE project, so there's no native CDI. Therefore I added Spring into the mix. The annotations work like a charm. The aforementioned ZoneIdSelectionDialog is also a Spring component - which shows the (from a developer's point of view) only downside of using Spring (or any other Dependency Injection framework) within a JavaFX application:
The lovely Application class follows a very straightforward pattern when launched:
  1. Constructs an instance of the specified Application class.
  2. Calls the init() method.
  3. Calls the start(javafx.stage.Stage) method.
  4. Waits for the application to finish, which happens when either of the following occur:
    • the application calls Platform.exit()
    • the last window has been closed and the implicitExit attribute on Platform is true
  5. Calls the stop() method
So far, so good. So think for a moment: Where would you want to instantiate your Spring beans? Sounds like it should be part of the init(), doesn't it?
The bad news is: This doesn't work when you use Spring (or any other DI framework) to initialize a JavaFX component, because these are only allowed to be constructed on the so-called JavaFX Application Thread. If you've never heard of it, this is where all the UI beauty is actually executed (for Swing veterans like me: It's the equivalent of the Event Dispatch Thread).
So this leaves us no choice but to initialize the Spring context first thing in the start(javafx.stage.Stage) method which seems unnatural, but is a technical restriction. Nevertheless, the gain outweighs this.

The Java Time API

A great addition to Java 8 and probably the one which generated the biggest buzz aside from Lambdas and Streams, I found it nice to use. This application only shows a small portion, but it already highlights a few key advantages over the much older Date and Calendar classes:
  • Instant and the other "value" classes in the package are immutable. This eases their usage and automatically makes them thread safe.
  • The same holds for the DateTimeFormatter - which I consider even more valuable. I've stopped counting how often in my career I stumbled over a strange behavior which I traced back to an unsafe usage of SimpleDateFormat, e.g. as a constant. This is bound to break in a multithreaded environment, as this class isn't thread safe.

Apache Velocity

OK, this library's usage in here is really a no-brainer. I'm using it in a very basic way to replace two tokens with values which are computed in the application. Probably smarter usage is possible, but I wanted to give the user an option of not using a template at all. I know that Velocity can do a lot more, but I really had no need for anything else here.

Lessons learned

  1. Use JavaFX! It's even better than you think.
  2. DI fits in nicely with FX if you keep in mind that you must use it in a slightly "unnatural" way.
  3. The Java Time API is just great. If you haven't done so yet, get acquainted with it. In my view, it's now about time (please excuse the pun) to deprecate Calendar and SimpleDateFormat.
Questions? Criticism? Ideas for improvement? Please feel free to leave any of these in the comments section or as mentioned, fork me on GitHub.

Wednesday, 22 July 2015

So THAT's what LinkedHashMap is for!

One often cited phrase in Software Craftsmanship is "Know Your Library". This came in quite handy in my latest contribution to the GreenMail project.

My current dayjob project uses GreenMail for simulating a receiving email server as part of testing the ones sent by our system. Every now and then, we have to restart the server, because the heap space has run out - by default, GreenMail stores all received emails in memory. Not much of an issue by itself, but if it happens too often, we'll just waste too much time.

We have similar simulators for other messaging channels such as SMS or Push Notifications. Like GreenMail, the Push simulators just stored all received messages in an unbounded ArrayList which was constantly growing until it exploded. We fixed this by replacing the ArrayList with Guava's EvictingQueue.

My initial idea for the GreenMail fix was the same, but the project coordinators are keen on keeping 3rd party dependencies as low as possible, so they rejected a Guava-based solution. However, I remembered how my former coworker Rafal had solved the issue for the SMS simulator which needed a Map- instead of a List- (or Queue-)based solution.

One standard Java class that a lot of people have heard of (or maybe even briefly scanned the first paragraph of Javadoc), but don't really know, is LinkedHashMap. Most Java devs will know this class as a HashMap with predictable iteration order - something we hardly ever need, so no need to feel bad if you (like me) never bothered to look at its full Javadoc in depth.

So in case you never did that, you will have most likely missed a very special method which is only part of this class and doesn't exist in the Map interface: protected boolean removeEldestEntry(Map.Entry<K,V> eldest).  Let's take a brief look at its JavaDoc:
Returns true if this map should remove its eldest entry. This method is invoked by put and putAll after inserting a new entry into the map. It provides the implementor with the opportunity to remove the eldest entry each time a new one is added. This is useful if the map represents a cache: it allows the map to reduce memory consumption by deleting stale entries.
Sample use: this override will allow the map to grow up to 100 entries and then delete the eldest entry each time a new entry is added, maintaining a steady state of 100 entries.
private static final int MAX_ENTRIES = 100;
protected boolean removeEldestEntry(Map.Entry eldest) {
   return size() > MAX_ENTRIES;
}
At the end of the day, an InMemoryStore is really no different from a cache. And the above example is pretty much exactly what we require it to do: Always purge the oldest message once a certain number is reached.

So on this base I created a simple utility class inside the GreenMail project which extends LinkedHashMap and provides exactly the required functionality. Starting from this, I was able to extract and abstract the methods needed to provide a somewhat easy way to exchange the existing List-based implementation for one based on the new Map class. Please feel free to explore the other parts of the changes for Issue #62 and ask any questions that may arise.

And always remember to Know Your Library.

Friday, 24 April 2015

Meine persönliche JAX

Nach zweimaliger Abstinenz habe ich mich 2015 mal wieder zur JAX begeben. Das Programm war wie stets ansprechend gestaltet, wenngleich mich die Auswahl im Vergleich zu früheren Jahren doch etwas enttäuschte. Nichtsdestotrotz war für den geneigten Professional noch mehr als genug an abwechslungsreichen Sessions zu finden.

Hier nun mein ganz persönlicher, total voreingenommener Bericht:

Tag 1: Dienstag, der 21.04.2015

Da ich erst an diesem Morgen aus Wales anreiste, verpasste ich notgedrungen die Eröffnung sowie den ersten Session-Durchgang. Pünktlich zur Kaffeepause traf ich dann endlich ein. Als erste Session hatte ich mir Thilo Frotschers "Eventbasierte Architekturen mit Java EE" herausgepickt. Kurz gesagt stellte Thilo CDI Events vor, mit denen ich schon gearbeitet hatte. Vermutlich genau deswegen konnte ich aus dieser Präsentation, die an sich ganz gut gestaltet war, nur sehr wenig herausziehen - ich hätte mir mehr Tiefe gewünscht, aber Thilos Idee war halt eine andere.
Nach dem Mittagessen folgte mit Lars Röwekamps "Not your Father's Java EE" und seinen Chuck-Norris-Regeln ein Vortrag, der mir persönlich deutlich mehr zusagte. An sich erzählte Lars gar nichts Neues, aber viele Dinge, die einem im Alltag schnell abhanden kommen. Insbesondere habe ich auch schon zu viele Anemic Domain Models gesehen und bin es schon fast Leid, dagegen noch anzupredigen. Nach diesem Talk bin ich jedoch wieder motiviert, diese Prinzipien stärker zu betonen.
Michael Hunger bot mit "Von Relational zu (Big) Graph" gewohnt gute Kost. Überraschenderweise war der Talk selbst für neo4j-Einsteiger gut verständlich - für mich war eher der zweite Teil interessant, wo er tatsächlich mal aufzeigte, wie man eine Migration praktisch durchführen kann. Ach, könnte ich doch nur unsere Entscheidungsträger überzeugen...
Andy Gumbrechts "RunWith(Arquillian.class)" empfand ich leider als maßlose Enttäuschung. OK, ich war zwar ein paar Minuten zu spät, aber Andy beschränkte sich in meinen Augen zu sehr auf die Praxisdemo, anstatt mehr zu erläutern, was da eigentlich passierte. Meine Erfahrungen mit Arquillian, das ich grundsätzlich für ein sehr interessantes Projekt halte, waren bisher aufgrund der meiner Ansicht nach recht hohen Lernkurve leider nicht so gut, und ich hatte mir hier Abhilfe versprochen. Soweit ich mich entsinnen kann, habe ich hier erstmals einen JAX-Talk deutlich vorzeitig (bereits nach etwa der Hälfte) vorzeitig verlassen - und ich war beileibe nicht der einzige.
Den Abschluss bot eine Keynote mit dem stets gut aufgelegten Brian Goetz, die er "Stewardship: The Sobering Parts" genannt hatte. Im wesentlichen ein historischer Abriss zu den wichtigsten Java-Meilensteinen kombiniert mit einem Ausblick auf mögliche kommende Sprachfeatures in Versionen nach Java 9. Sehr gespannt bin ich auf Value Types, mit deren Hilfe man die doch inzwischen sehr künstliche Trennung zwischen primitiven (z.B. int) und Objekttypen (z.B. Integer) mehr oder weniger aufheben können soll.

Irgendwie hatte mir dieser Tag nicht so zugesagt. Insgesamt hatten die Vorträge wenig Neues gebracht, Andy Gumbrecht war sogar völlig an mir vorbeigelaufen. Vielleicht war ich aber auch nur zu erschöpft von der kurzen Nacht und langen Anreise - ich war schon morgens um 1:30 aufgestanden.

Tag 2: Mittwoch, der 22.04.2015

Dank eines verspäteten Busses - darauf ist man halt angewiesen, wenn man auf eigene Kosten reist - erschien ich bereits sehr abgehetzt zu "Andocken bitte!" mit dem mir bisher unbekannten Michael Johann. Von Docker hatte ich schon einiges gehört, aber hier hatte ich wirklich den perfekten Einstieg gefunden. Ich war praktisch sofort infiziert. Man hört zwar oft den Claim "In einem Jahr machen das alle", aber hier könnte es tatsächlich stimmen. Wir hatten Docker in unserem Projekt schon auf dem Radar, haben es aber immer wieder verschoben. Jetzt muss ich da wirklich mal mehr drauf drücken.
Ich hatte sehr lange überlegt, mir die Q&A-Session mit Brian Goetz und der mindestens ebenso kompetenten Angelika Langer zu geben, entschied mich aber schließlich doch für "Functional Thinking" mit Neal Ford - bei einem ThoughtWorker macht man nie was falsch. ;-) Zudem empfinde ich Lambdas, Streams etc. nach wie vor ein bisschen wie etwas sehr Fremdes - ich beherrsche zwar die Syntax und setze sie auch ein, wo ich kann, aber diese Sprachmittel sind mir beileibe noch nicht so in Fleisch und Blut übergegangen wie Vererbung, Polymorphie und ähnliche Dinge, über die ich gar nicht mehr nachdenke. Während ich hier nach wie vor mehr Praxis benötige, hat Neal mir doch zumindest ein kleines Stück weiter geholfen.
Die obligatorische SAP-Keynote "Die dunkle Seite von IoT" mit Matthias Steiner gefiel mir sehr, vor allem wenn man bedenkt, dass es eben SAP war, die sich bei Keynotes sonst an Langweiligkeit gegenseitig überboten. Wenngleich er natürlich (es ist ja SAP) geänderte Businessmodelle und ähnliches erwähnte, war der Vortrag auch für mich als Techie interessant.
Von Eric Evans, der sich mit seinem DDD-Buch schon lange ein Denkmal gesetzt hat, hatten sich natürlich viele Leute einiges erwartet. Am Montag hatte er wohl auch einen sehr guten Workshop geleitet, aber seine Keynote "At last, some boundaries!" wollte bei mir überhaupt nicht ankommen. Anstatt mal wirklich konkrete Beispiele zu betrachten, schickten sich Services A, B, C, D, E und F Nachrichten in den Formaten a, b, c, d, e und f und konnten sich damit gegenseitig stören. Oder auch nicht. Oder irgendwie sowas. Irgendwo unterwegs hatte er mich definitiv verloren, weswegen ich mich frühzeitig zum Mittagessen begab.
Nach diesem erneut eher durchwachsenen Erlebnis hatte ich für den Rest des Tages genug vom Experimentieren und beschränkte ich mich auf Vorträge von Leuten, bei denen ich wusste, woran ich war - in diesem Fall Arno HaaseStefan Tooth und Stefan Zörner. Arno erzählte zu "Reaktiven Geschäftsanwendungen" eher aus Architekten- als aus Entwicklersicht. Wie gesagt, bei Arno weiß ich, dass er Ahnung hat und gute Vorträge hält, und er enttäuschte auch hier nicht. Ich konnte einiges mitnehmen.
Stefan Tooths Betrachtung der Netflix-Architektur litt unter dem für diesen Talk unterdimensionierten Watford-Saal. Im Gegensatz zu den Erdgeschoss-Räumen gibt es hier keine erhöhte Leinwand, zudem steht noch eine Säule in der Mitte. Ich konnte von relativ weit hinten die Folien nur zu etwa zwei Dritteln sehen, auch die Luft war aufgrund der hohen Teilnehmerzahl nicht die beste. Das ist natürlich alles nicht Stefans Schuld, der Vortrag selbst war gut gestaltet und zeigte mir leider nur einmal mehr auf, warum es in der hochregulierten Finanzwelt, in der ich mich im weiteren Sinne noch immmer bewege, praktisch unmöglich ist, wirklich agil zu arbeiten. Dennoch war ich ob der äußeren Umstände doch recht froh, als Stefan mit seinem Talk durch war. Lange hätte ich wegen der schlechten Luft wohl nicht mehr durchgehalten.
Sein Geschäftspartner Sefan Zörner zeigte hernach seine Vortragserfahrung in seinem Talk zu Tipps und Tricks zu Architekturüberblicken. Das ist halt Stefans Thema, wozu man ihn quasi um 2 Uhr nachts wecken könnte: "Kannst du mal in einer halben Stunde einen Talk fertig machen? Mr. X hat Probleme mit seinem Flieger und uns deswegen abgesagt." Ich garantiere euch, er könnte - und man würde es nicht mal merken! Stets unterhaltsam, wenn auch vielleicht etwas überzogen an der Stelle, als er klatschte, um vermutlich unnötigerweise noch mal Aufmerksamkeit auf den nach seiner Ansicht wichtigsten Teil seiner Präsentation zu lenken. Außerdem kann man aus Stefans Vorträgen praktisch immer irgendetwas mitnehmen, so auch hier.
Die JAX-Awards und folgende Keynote schenkte ich mir und unterhielt mich lieber mit ein paar Ausstellern, dazu vielleicht mehr in einem späteren Beitrag. Zu Arno Haases "Java-Trickkiste" gibt es nicht viel zu sagen. Dieses jmh-Tool muss ich mir mal bei Gelegenheit anschauen; ansonsten zeigte Arno ein paar nette Spielereien, den Claim "mit hohem Unterhaltungsfaktor" erfüllte er auf jeden Fall - besonderen Tiefgang erwartet man von den Spätvorträgen sowieso nicht mehr, schließlich haben um diese Zeit schon praktisch alle Anwesenden einen langen Tag hinter sich und die eine oder andere Apfelsaftschorle intus.

Der Mittwoch hatte mir unterm Strich deutlich mehr gebracht als der Dienstag. Ich hatte sogar zwischen den Sessions die ersten Teile der Docker-Einführung durchgespielt. So sollte die JAX eigentlich immer sein.

Tag 3: Donnerstag, der 23.04.2015

Meine Lernfähigkeit bewies ich, indem ich einen Bus früher nahm und eine Haltestelle eher ausstieg, so dass ich wenig abgehetzt und mit gutem Zeitpolster zu "Docker für Java-Entwickler" mit Jolokia-Erfinder Roland Huß erschien. Definitiv eine gute Wahl und die logische Fortsetzung von Michael Johanns Vortrag vom Mittwoch. Michaels Präsentation hatte sich hauptsächlich um die Frage "Was ist Docker?" gedreht, während Roland nun die Antwort auf "Und was mache ich damit?" brachte. Gut vorbereitet, ordentliche Demo. Spätestens jetzt fühlte ich mich bereit, nötigstenfalls bis aufs Blut um den Einsatz von Docker in unserem Projekt zu kämpfen.
Kirk Pepperdine erzählte zu "The dark Art of Performance Tuning". Ich hatte ihn noch nie gehört oder gesehen. Als Bilanz kann ich sagen, dass er definitiv weiß, wovon er redet. Der Vortrag war ein Stück weit interaktiv, wodurch er die Teilnehmer gut bei Laune hielt. Dennoch erschien mir das ganze insgesamt zu unrund - ich kann nicht den Verdacht verhehlen, dass Kirk sich für die Vorbereitung keine allzu große Zeit genommen hatte.
Es folgte die vielleicht merkwürdigste Keynote, die ich bei allen drei JAXen, denen ich beiwohnen durfte, gesehen habe. Der Titel lautete "Technologie-Trends jenseits von Java". Eberhard WolffKai TödterOliver GierkePeter Roßbach und Uwe Friedrichsen hielten, jeder für sich, eine Mini-Präsentation zu diesem doch recht weit gefassten Titel. Große Koordination zwischen den fünf erfahrenen Speakern hatte offenbar nicht stattgefunden, ein roter Faden fehlte komplett. Sebastian Meyhen bemühte sich redlich bei seinen Überleitungen, aber letztendlich blieben es fünf unabhängige Kurztalks. Ich kann mich des Eindrucks nicht erwehren, dass hier kurzfristig ein Slot gefüllt wurde, den der Veranstalter ursprünglich für etwas ganz anderes vorgesehen hatte.
Nach dem Mittagessen und der JAX-Verlosung, die mir einen Teilnahmecode für eine Vaadin-Zertifizierung beschert hatte, wandte ich mich wieder der Architekturschiene zu, dieses Mal in Gestalt eines Vortrags mit dem reißerischen Titel "Know Your Enemies". Gernot Starke hatte ich noch nie erlebt - wem's ebenso geht, sollte das unbedingt nachholen. Der Mann hat Ahnung und einen hochgradigen Unterhaltungsfaktor. Eine sehr lebendige Präsentation, aus der ich einiges herausgezogen habe - so sollte es eigentlich immer sein...
"Mobile Push for the Enterprise" ist sicherlich eher ein Nischenthema, mit dem ich mich aber im aktuellen Projekt schon seit einigen Monaten auseinandersetze. Da wir uns der Schwächen unserer eigenen Lösung bewusst sind, hatte ich mir diesen Vortrag extra schon in der Vorwoche herausgesucht sowie die dazugehörige AeroGear-Website, die zum JBoss-Ökosystem zählt, besucht. Der UnifiedPush-Server löst genau einige unserer zentralen Probleme. Matthias Wessendorffs westfälisch-schnodderige Art mag nicht jedem zusagen, ich komme damit jedoch gut zurecht. Hoffentlich kriege ich die Freigabe, diesen Server in unserem Projekt einzusetzen. Für wen Push ein Thema ist, sollte sich definitiv mit diesem Projekt befassen.
Vor einem wegen Heimreisen schon deutlich gelichteten Publikum durfte Dominik Schadow noch etwas zu "Java-Web-Security Anti-Patterns" erzählen. Für die meisten (wie für mich) ein eher dröges Thema, um das man aber einfach nicht herumkommt. Insofern gelungen, aber unspektakulär. Ich weiß nicht, wie oft Dominik Vorträge hält, aber er wirkte auf mich etwas gequält. Dennoch ein würdiger Abschluss für die Konferenz.

Was gibt's sonst zu sagen? Das Essen war gut und reichlich, auch stand ich gefühlt nicht so lange in der Schlange wie in früheren Jahren - wer weiß, vielleicht waren es weniger Teilnehmer. Ich hatte ein nettes kleines Hotel in Wiesbaden, musste aber jeden Abend darauf achten, noch den letzten Bus zu erwischen. Die Atmosphäre auf der Konferenz war wie immer nett, und ich habe einige alte Bekannte inklusive ehemaliger Kollegen wiedergetroffen.

Unterm Strich hat sich die Reise, die ich dieses Mal voll selbst finanziert habe (das Ticket hatte ich hier gewonnen), definitiv gelohnt. Es wird echt Zeit, dass ich mal meinen Ar... hochkriege und mir ein Thema suche, zu dem ich selbst etwas erzählen kann.

[tl;dr]

Die JAX gibt's noch immer, aber ich war nicht mehr so begeistert wie früher. Docker muss sein. Java ist dank Java 8 wieder da, und ich muss noch immer jeden Tag dazulernen.

Auf bald!