One of the earliest and most fundamental principle one learns while coding is programming by interface. Definition Interface-based programming defines the application as a collection of components, in which Application Programming Interface (API) calls between components may only be made through abstract interfaces, not concrete classes. Instances of classes will generally be obtained through other interfaces using techniques such as the Factory pattern. — Wikipedia https://en.wiki
A post brought to light an interesting feature of the JDK I didn’t know about: the ability to update a code running in a JVM. The referenced post shows how to apply a bugfix using that feature. The devious white hat JVM hacker in me started to think how one could apply that trick for other less beneficial purposes. And of course, how to prevent that. Hack overview Let’s imagine a banking application based on the familiar Spring Boot stack. A TransferService class is dedicated to
When streams were added to Java 8, I wanted to jump on the bandwagon. I read blog posts, watched videos, attended workshops to understand what this was all about. After a while, I became comfortable enough… but I was unhappy with the implementation: while streams offer methods with a functional approach, legacy collections do not. When one wants to use Java capabilities on an existing collection, the later needs to be transformed to a stream, and then back again. For example, the f
Coming from a Java background, I'm currently trying to learn the Clojure programming language, with the help of online resources and mentorship. Some weeks ago, I tried to wire things together by trying to find equivalent methods to those available in Java streams. While I managed to get things working, writing working code and writing idiomatic code are two very different things. I was fortunate to have a good degree of feedback from different sources: Hacker News, Reddit and on this very blog.
Some weeks ago, I read the post referenced in a tweet. In short, the article provides two ways to generate the boilerplate code required by the Builder pattern: Lombok, to generate code at compile time and the Spark Eclipse plugin, to generate code at development time. However, I already wrote about the Builder pattern. And it's a bit more complex than what's described in the referenced post.
The Java EE platform is huge, and I must confess I'm not aware of every one of its API. This is also true of the Spring framework, even though I think I know more of Spring than of Java EE. Lately, I was working on the version 10 of the Vaadin framework also known as Vaadin Flow. This version introduces routes. When a path is requested, the Vaadin Servlet displays the component. Routes are created by annotating specific components with the @Route annotation. Thus, Vaadin needs to list all annotat
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.
This post is part of a series on learning the Clojure language. A common pattern in software development is the dynamic dispatching (or routing) table. The table is responsible for returning the relevant output for a specific input. In the Object-Oriented programming world, the object model would look something like the following.