A Java geek

Playing with Spring Boot, Vaadin and Kotlin

It’s no mystery that I’m a fan of both Spring Boot and Vaadin. When the Spring Boot Vaadin add-on became GA, I was ecstatic. Lately, I became interested in Kotlin, a JVM-based language offered by JetBrains. Thus, I wanted to check how I could develop a small Spring Boot Vaadin demo app in Kotlin - and learn something in the process. Here are my discoveries, in no particular order.

Miscellaneous

8 years of blogging in retrospect

This is quite an unusual post, as it is the first post of 2016. Moreover, it’s also unusual because it’s my 300th post there! Though it might seem like an ego trip, I feel it’s important to think about the things that lead here. This blog started in April 2008, a little less than 8 years ago. At the time, I was between 2 missions and had much time to spare.

Java

Refactoring code for testability: an example

Working on a legacy project those last weeks gave me plenty of material to write about tests, Mockito and PowerMock. Last week, I wrote about abusing PowerMock. However, this doesn’t mean that you should never use PowerMock; only that if its usage is commonplace, it’s a code smell. In this article, I’d like to show an example how one can refactor legacy code to a more testable design with the temporary help of PowerMock.

Java

On PowerMock abuse

Still working on my legacy application, and still trying to improve unit tests. This week, I noticed how much PowerMock was used throughout the tests, to mock either static or private methods. In one specific package, removing it improved tests execution time by one order of magnitude (from around 20 seconds to 2). That’s clearly abuse: I saw three main reasons of using PowerMock.

Java

The danger of @InjectMocks

Last week, I wrote about the ways to initialize your Mockito’s mocks and my personal preferences. I’m still working on my legacy project, and I wanted to go deeper into some Mockito’s feature that are used. For example, Mockito’s developers took a real strong opinionated stance on the design: Mockito can only mock public non-final instance methods. That’s something I completely endorse.

Java

Initializing your Mockito mocks

Maintenance projects are not fun compared to greenfield projects, but they sure provide most of the meat for this blog. This week saw me not checking the production code but the tests. What you see in tests reveals much of how the production code itself is written. And it’s a way to change things for the better, with less risks. At first, I only wanted to remove as much PowerMock uses as possible. Then I found out most Mockito spies were not necessary.

Technical

Semantics: state or dependency, not both

The more I program, the easier it gets. However, the more questions arise regarding programming. This week, my thinking was about Object-Oriented Programming. I’ve been told that OOP is about encapsulating state and behavior is a single isolated unit. In languages I know, state translates into attributes and behavior into methods. public class Cat { private Color color; public void mew() { ...

Development

Forget the language, the important is the tooling

There’s not one week passing without stumbling upon a post claiming language X is superior to all others, and offers you things you cannot do in other languages, even make your kitchenware shine brightier and sometimes even return lost love. I wouldn’t mind these claims, because some features really open my Java developer mind to the lacking of what I’m using now, but in general, they are just bashing another language - usually Java.

Development

Using a framework or not?

If you haven’t read Uncle Bob latest blog post, you should do now. For impatient readers, it can be summed up with: TL;DR: 'You don’t need frameworks, just write the appropriate code'. It’s not the first time I find myself at odd with Uncle Bob’s writing, which feels awkward in regard to his experience and aura. Another post that drew my attention was about JavaScript.

Nicolas Fränkel's blog