Software Notes from Underground

Introduction Throughout my career as a Java developer, I've frequently implemented a particular pattern across numerous projects. This pattern, known as the operation result pattern , encapsulates the outcome of an operation along with its return object, enhancing code clarity. It distinctly categorizes function call outcomes into success or failure, each requiring appropriate handling by the developer. In contrast, certain languages, such as Kotlin, integrate this pattern within their standard libraries, or like Golang, facilitate the return of additional information to indicate the operation's outcome. Unfortunately, Java lacks such a built-in solution, prompting the need for a standardized approach. Motivated by this gap, I created a library that implements the result pattern in the JResult , a library aimed at brining the operation result pattern in Java applications. Java's Built-in Error Handling Mechanisms Java's conventional approach to managing errors reli...

Throughout my journey in various Java projects, I've consistently encountered the need to reimplement a specific pattern — one that encapsulates the results of operations without resorting to exceptions, such as during input validation.  This pattern, known as the Operation Result Pattern, may not be universally recognized as a formal design pattern, but in my experience, it's an incredibly useful approach for handling operation outcomes. I thought it would be nice to have it in a form of a simple library that can be easily integrated in the Java projects. After dedicating a few weeks to development, I'm excited to announce the release of the first version of this library, which I've named JResult.  It's designed to be lightweight, easy to use, and flexible enough to accommodate various project needs. You can explore JResult and its documentation on GitHub: https://github.com/ArtyomPanfutov/jresult Stay tuned for updates, and don't hesitate to contribute or reac...

The initial setup  I have a serverless container built with Java and Micronaut framework. It has one HTTPS endpoint for calculating the loan amortization schedule.  When there are no requests — the container is down and no resources are consumed. When the request comes the container is initialized. It takes time to start the application, and JVM is not warmed up. These kinds of things really impact the request latency.  Take a look at the screenshot of the dashboard: As you can see the request latency is 5-10 seconds. This is a very long time to wait for a user.  I've been considering different ways to improve this situation — from migrating to a VM instance that will be up all the time, so there will be no time spent to start a container for every request, to switching to another technology.  But since the service is not used much it is a bit overkill to keep the service up all the time. I wanted to save the serverless setup.  Trying GraalVM One of the sol...