A Java geek

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.

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.

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.

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 the 3rd post in the JVM Security focus series. Last week, I wrote about the JVM policy file that explicitly lists allowed sensitive API calls when running the JVM in sandboxed mode. This week, I’d like to improve the security by signing the JAR.

This is the 2nd post in the JVM Security focus series. I’ve already written about the JVM security manager, and why it should be used - despite it being rarely the case, if ever. However, just advocating for it won’t change the harsh reality unless some guidelines are provided to do so. This post has the ambition to be the basis of such guidelines. As a reminder, the JVM can run in two different modes, standard and sandboxed.

Java makes it possible to compile Java code at runtime…​ any Java code. The entry-point to the compilation is the ToolProvider class. From its Javadoc: Provides methods for locating tool providers, for example, providers of compilers. This class complements the functionality of ServiceLoader. This class is available in Java since version 1.6 - released 10 years ago, but seems to have been largely ignored.

In this post, I’d like to explore a sample data set using Kibana. This requires some data to start with: let’s index some tweets. It’s quite straightforward to achieve that by following explanations found in my good friend David’s blog post and wait for some time to fill the index with data. Basic metric Let’s start with something basic, the number of tweets indexed so far. In Kibana, go to Visualize  Metric, then choose the twitter index.

Though Kotlin and Spring Boot play well together, there are some friction areas between the two. IMHO, chief among them is the fact that Kotlin classes and methods are final by default. The Kotlin docs cite the following reason: The open annotation on a class is the opposite of Java’s final: it allows others to inherit from this class.