A Java geek

Last week, I tried to make a Spring Boot app - the famous Pet Clinic, Java 9 compatible. It was not easy. I had to let go of a lot of features along the way. And all in all, the only benefit I got was improvement of String memory management. This week, I want to continue the migration by fully embracing the Java 9 module system.

With the coming of Java 9, there is a lot of buzz on how to migrate applications to use the module system. Unfortunately, most of the articles written focus on simple Hello world applications. Or worse, regarding Spring applications, the sample app uses legacy practices - like XML for example. This post aims to correct that by providing a step-to-step migration guide for a non-trivial modern Spring Boot application. The sample app chosen to do that is the Spring Pet clinic.

It sometimes happen that after a few years, an app is stable enough that it gets into hibernating mode. Though it’s used and useful, there are no changes to it and it happily runs its life. Then, after a while, someone decides to add some new features again. Apart from simple things such as locating the sources, one of the most important thing is to be able to build the app. Though it may seem trivial, there are some things to think about.

Nowadays, when a webapp offers a registration page, it usually duplicates the password field (or sometimes even the email field). By having you type the password twice, it wants to ensure that you didn’t make any mistake. And that you don’t have to reset the password the next time you try to login. It makes sense if you actually type the password. Me, I’m using a password manager. That means, I do a copy-paste the password I got from the password manager twice.

As software developers, we behave like children. When we see shiny new things, we just have to play with them. That’s normal, accepted, and in general, even beneficial to our job…​ up to a point. When Java started to provide annotations with version 5, there was a huge move toward using them. Anywhere. Everywhere. Even when it was not a good idea to. But it was new, hence it had to be good. Of course, when something is abused, there’s a strong movement against it.

There is a bunch of languages running on the JVM, from of course Java, to Clojure and JRuby. All of them have different syntaxes, but it’s awesome they all compile to the same bytecode. The JVM unites them all. Of course, it’s biased toward Java, but even in Java, there is some magic happening in the bytecode. The most well-known trick comes from the following code: public class Foo { static class Bar { private Bar() {} } public static void main(String...

Every now and then, there’s an angry post or comment bitching about how the Spring framework is full of XML, how terrible and verbose it is, and how the author would never use it because of that. Of course, that is completely crap. First, when Spring was created, XML was pretty hot. J2EE deployment descriptors (yes, that was the name at the time) was XML-based. Anyway, it’s 2017 folks, and there are multiple ways to skin a cat.

When Java came out some decades ago, it was pretty innovative at the time. In particular, its exception handling mechanism was a great improvement over previous C/C++. For example, in order to read from the file, there could be a lot of exceptions happening: the file can be absent, it can be read-only, etc.

At conferences, it’s common to get gifts at booths. In general, you need to pass some some sort of challenge. Some of those challenges involve answering a code puzzle, like guessing the output of running some code snippet.

Every now and then, there’s a post predicting the death of the Java language. The funny thing is that none of them writes about a date. But to be honest, they are all probably true. This is the fate of every language: to disappear into oblivion - or more precisely to be used less and less for new projects.