It is more beneficial to use sealed and value class instead of enumerations in Kotlin; let’s find out why.
Almost all Java developers are familiar with logging frameworks like Log4j and the facade SLF4J, but not the System.Logger that has been available since java 9. Let’s learn about the standard.
Learn how to improve the API provided by third-party libraries by combining Kotlin extension functions and delegation.
Serverless data offers benefits, but market offerings are limited. What serverless data can, should, or could do isn’t always understood.
I’d like to describe how to add new behavior to an existing object/type. I won’t use any reactive type to make it more general.
The JVM ecosystem is mature and offers plenty of libraries, so you don’t need to reinvent the wheel. Basic – and not so basic – functionalities are just a dependency away. Sometimes, however, the dependency and your use-case are slightly misaligned.
The correct way to fix this would be to create a Pull Request. But your deadline is tomorrow: you need to make it work now! It’s time to hack the provided API.
In this article, we are going through some alternatives that allow you to make third-party APIs behave in a way that their designers didn’t intend to.
Last week, I described a use-case for a custom Stream Collector. I received a intriguing comment on Twitter.
So I decided to investigate what is the teeing() method about, which returns a Collector that is a composite of two downstream collectors.
Every element passed to the resulting collector is processed by both downstream collectors, then their results are merged using the specified merge function into the final result.
You can solve most use cases with one of the out-of-the-box collectors provided in the Collectors class.
However, some require to implement a custom Collector, e.g., when you need to collect more than a single collection or a single scalar.
While it may seem complicated if you never developed one before, it’s not. You only need a bit of practice.
I hope this article might help you with it!
This week, I learned about a nifty “new” feature of Optional that I want to share in this post. It’s available since Java 9, so its novelty is relative.
We start with a sequence to compute the total price of an order, for which it is nowadays more adequate to use streams instead of iterations.
Optional makes the code less readable! I believe that readability should trump code style every single time.
Fortunately, Optional offers a stream() method (since Java 9). It allows to simplify the functional pipeline. Functional code doesn’t necessarily mean readable code. With the last changes, I believe it’s both.