design

The book Design Patterns: Elements of Reusable Object-Oriented Software was one of the texts that changed how we think about software design.

Error management is a fact of life in software development as it is often inevitable and generated by different causes that also include incorrect or incomplete understanding of the requirements or even lack of knowledge of some tools or elements used during development.

This post is neither a recommendation, nor even a suggestion. It’s just me toying with an idea: Implement it at your own risk! The main benefit of Docker containers is that they are self-contained. For developers, that means one just needs to inherit from the desired Docker image that contains the necessary required dependencies, and presto, one can build one’s application deliver it to production. Most of the times, the process is pretty straightforward.

Some time ago, I described a couple of surprising design choices in the JDK functional interfaces API. Lately, during a lesson, a student of mine proposed to shallow-copy an ArrayList by using the clone() method: I thought this is another API gotcha worth writing about. Cloning an object means a new object is created with the same state as the original one. As per the JavaDoc: Creates and returns a copy of this object. The precise meaning of 'copy' may depend on the class of the object.

Because of a course I prepared, I recently had a closer look at the java.util.function package in JDK 8, and discovered a couple of interesting design choices. A Callable and a Supplier are defined in the same way. But they are not equivalent.

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.

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.

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.

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.

Kotlin’s extension functions are a great way to add behavior to a type sitting outside one’s control - the JDK or a third-party library. For example, the JDK’s String class offers the toLowerCase() and toUpperCase() methods but nothing to capitalize the string. In Kotlin, this can be helped by adding the desired behavior to the String class through an extension function: fun String.capitalize() = when { length < 2 -> toUpperCase() else -> Character.

My post about immutability provoked some stir and received plenty of comments, from the daunting to the interesting, both on reddit and here.