coroutine concurrent programming thread

Even and odd with coroutines

Recently, I stumbled upon one of Baeldung’s post showing how to use threads to print odd and even numbers: one thread dedicated to print odd numbers, another one to print even ones. Since I became aware of them, I was very interested in Kotlin coroutines and how they make concurrent programming code easier to read and write. I wanted to check how using coroutines would yield better code. Show me the code This is what I came up with: import java.util.concurrent.ThreadLocalRandom imp

interface clean code

Limits of programming by interface

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

Kotlin collection sequence stream lazy evaluation

Kotlin, collections and sequences

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

Clojure sequence stream

Feedback on Learning Clojure: comparing with Java streams

This is the 7th post in the Learning Clojure focus series. 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 fr

builder design pattern state machine

The Builder pattern is a finite state machine!

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.

annotations reflection vaadin

Listing annotated classes in Java EE

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 a

Clojure dependent types programming by contract

Learning Clojure: dependent types and contract-based programming

This is the 5th post in the Learning Clojure focus series. While describing how to cope with dynamic typing, we used the spec library. The library is not a true replacement for types - checks are executed at runtime instead of compile-time. On the flip side, it can go further than mere types, including emulating dependent types and programming-by-contract.