In a previous post I’ve shown how to build a minimal example of a random case class generator using the metaprogramming features of Scala 3. While investigating this topic, I naturally came upon multiple ways to do this. In this post I will elaborate on two other ways to build the same generator and pick my personal favorite.
Coming from a Java background, reflection to me was a useful, albeit highly advanced tool in daily work. Being mostly used in libraries and frameworks, understanding its possibilities and usages was usually enough for me.
While advancing my career and moving to the scala ecosystem I learned about the existence of macros as a kind of compile-time reflection, used mostly by libraries. Still, it being a highly advanced language feature and not very ergonomic for daily programming, I felt more comfortable in the regular code world.
Then, during the development of a certain feature for the client I was working at, I felt the code I had written was so much boilerplate, there should be a way to shorten what I’ve written (unfortunately I cannot remember exactly what that was about, but it definitely had to do with some kind of mapping between data and their corresponding case classes…). In Java I would have tried my hand at reflection to extract and generate POJO’s, which could be done in scala as well, but I’ve always felt reflection isn’t the right tool for custom written production code, it being a slow, purely runtime process, which is never optimized by the compiler. I asked a senior colleague if using a macro to extract the field names and values would be a way to solve this, since it would bring me some compile-time safety. He then introduced me to the shapeless library, and the rabbit-hole opened up.
In a previous post I’ve shown how to use ZIO environments to provide your program with dependencies, or modules. While using environments at the customer I’m currently working for, we found out that the logic to get a database session object using a module would run over and again. This makes sense, since a ZIO[R, E, A] is a prescribed way of getting an A, and the result is not cached. Our application was reading configuration files and creating SQL sessions on every module call, while the resulting object was obviously constructed from the same underlying values. There are multiple ways to solve this:
Creating the singleton objects before running you application logic.
Caching the result of the loading code in a reference.
In this post I’ve chosen the latter, because I wanted to show the use of ZIO’s Ref. Also, I like how semantically the desired data and the logic of retrieving it belong together.
ZIO is a type-safe, composable library for asynchronous and concurrent programming in Scala (from: The ZIO github). The library copes with functional IO, like many Functional Programming libraries do. The added value of ZIO is that the ZIO[R, E, A] type-constructor
(the main IO monad of the library) acts as an IO monad, an error handling monad, and a reader monad. A functional programming style often needs a combination of these three types to cope with the most common problems when creating an application:
performing side effects (getting the A)
coping with errors (handling E)
supplying dependencies (providing R)
This blogpost will show you how to cope with the R part of a ZIO[R, E, A]: the Environment
ZIO is a type-safe, composable library for asynchronous and concurrent programming in Scala (from: The ZIO github). The ZIO framework provides your program as immutable and pure values, which are very simple to properly unit test. But how can you run an integration test to see if your application starts up properly?
Although Java has always been awesome, Java 8 has brought the language several features the language was in dire need of. Apart from the long-awaited improved DateTime-API and the introduction of Optionals, Java 8 finally gave behaviour the attention it deserves by incorporating (a form of) functional programming into the language using lambdas.
The opportunities that Java 8 brought the language and the platform have long since been taken and functional styles of programming are part of our day-to-day routines as Java Developers. For-loops are a thing of the past for most of us, and although it had quite the learning curve, passing streams around and chaining operations on them to create some very readable code is common sense for us now.
