A Java geek

Since one year or so, I try to show the developer community that there’s no magic involved in Spring Boot but rather just straightforward software engineering. This is achieved with blog posts and conference talks. At jDays, Stéphane Nicoll was nice enough to attend my talk and pointed out an issue in the code. I didn’t fix it then, and it came back to bite me last week during a Pivotal webinar. Since a lesson learned is only as useful as its audience, I’d like to share my mista

I assume that readers are already familiar with the Kotlin language. Advertised from the site: Statically typed programming language for the JVM, Android and the browser 100% interoperable with Java™ — Headline from the Kotlin website Kotlin first penetrated the Android ecosystem and has seen a huge adoption there. There’s also a growing trend on the JVM, via Spring Boot. Since its latest 1.1 release, Kotlin also offers a production-grade Kotlin to JavaScript transpiler. Thi

During my journey coding an actuator for a non-Spring Boot application, I came upon an interesting problem regarding where to actually put a snippet of common code. This post tries to list all available options, and their respective pros and cons in a specific context. As a concrete example, let’s use the REST endpoint returning the map of all JVM properties accessible through the /jvmprops sub-context. Furthermore, I wanted to offer the option to search not only for a single property e.g

As a developer, you’re a pretty important resources for service providers. Without developers, service providers cannot make savings based on scale. Having developers also means higher chances of someone having a killer idea on top of your service, creating even more value. And developers attract more developers. In order to achieve that, service providers offer free services. In the Cloud realm, both Google and Amazon have a packaged offer valid for a year. Once the grace period has expi

As I wrote some weeks earlier, I’m trying to implement features of the Spring Boot actuator in a non-Boot Spring MVC applications. Developing the endpoints themselves is quite straightforward. Much more challenging, however, is to be able to configure the mapping in a properties file, like in the actuator. This got me to check more closely at how it was done in the current code. This post sums up my 'reverse-engineering' attempt around the subject. Standard MVC Usage In Spring MVC, in

UPDATED on March 13, 2017: Add Builder pattern section Most developers have strong opinions regarding whether a language should be strongly-typed or weakly-typed, whatever notions they put behind those terms. Some also actively practice stringly-typed programming - mostly without even being aware of it. It happens when most of attributes and parameters of a codebase are String. In this post, I will make use of the following simple snippet as an example: public class Person { private fin

Regular readers of this blog know I’m a big proponent of the Spring framework, but I’m quite opinionated in the way it should be used. For example, I favor explicit object instantiation and explicit component wiring over self-annotated classes, component scanning and autowiring. Concepts Though those concepts are used by many Spring developers, my experience has taught me they are not always fully understood. Some explanation is in order. Self-annotated classes Self-annotated c

One of the first things one learns when starting with Java development is how to declare a class into its own file. Potential later stages include: Declaring multiple classes into the same file - with at most one of them publicDeclaring static nested classes or inner classesDeclaring anonymous (inner) classes But this doesn’t stop there: the JLS is a trove full of surprises. I recently learned classes can be declared inside any block, including methods. This is called local class declarat