A Java geek

Designing your own Spring Boot starter – part 2

In the last post, I tried to describe the internal working of Spring Boot starter. It’s now time to develop our own! As an example, we will use XStream, a no-fluff just-stuff XML/JSON (de)serializer offered by Thoughtworks. Readers who only use JAXB and Jackson are advised to have a look at XStream, it’s extremely efficient and its API is quite easy to use. As seen in our last post, the entry-point of a starter lies in the META-INF/spring.factories file.

Java

Designing your own Spring Boot starter - part 1

Since its release, Spring Boot has been a huge success: it boosts developers productivity with its convention over configuration philosophy. However, sometimes, it just feels too magical. I have always been an opponent of autowiring for this exact same reason. And when something doesn’t work, it’s hard to get back on track. This is the reason why I wanted to dig deeper into Spring Boot starter mechanism - to understand every nook and cranny.

Development

Why you shouldn't trust the HTML password input

This week, I wanted to make a simple experiment. For sure, all applications we develop make use of HTTPS to encrypt the login/password but what happens before? Let’s say I typed my login/password but before sending them, I’m called by my colleague and I leave my computer open. My password is protected by the HTML password input, right? It shows stars instead of the real characters. Well, it’s stupidly easy to circumvent this.

Java

The Java Security Manager: why and how?

Generally, security concerns are boring for developers. I hope this article is entertaining enough for you to read it until the end since it tackles a very serious issue on the JVM.

JavaEE

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.

Nicolas Fränkel's blog