Builders provide a nice, if verbose, way to create immutable java beans.
The upsides are a nice syntax for creating immutable beans, and a way to provide copy-on-write behaviour for immutable objects.
The downsides are the need for verbose boilerplate code, approximately doubling the code size of the bean source files, and the overhead of one extra object created and then left for garbage collection, for each created bean.
The blog post How I learnt to like Optional shows an example of how to chain Optional values safely, using Optional.orElse() to provide empty objects for the next level in the chain.
This blog post uses Optional.flatMap() and Optional.map(), to achieve the same thing, without having to create the empty objects, and without doing any evaluation for empty objects.
I used to see Optional<Something> as a completely useless addition to Java, adding to the bloat of Java without being any clearer than checking if a reference is null.
I have changed my mind, and now think Optional<> can be useful in making code simpler, easier to understand, and more robust.
The reason I changed my mind, was the usefulness of Optional.orElseThrow() when having to traverse deeply nested data structures in Java code.
I create web applications by first creating a set of OSGi bundles that form the building blocks of the application, and then use karaf features to pull the building blocks together to create complete applications that run inside apache karaf.
I use travis-ci to build my github projects and use sonarcloud to do analysis of the builds.
In the start of January 2020, the test coverage percentage on all sonarcloud projects suddenly dropped to 0%.
This blog post explains why coverage percentage dropped to 0% and how to get the test coverage back in the sonarcloud reports.
Continue reading How to get test coverage back in sonarcloud maven builds
I have written the Java class JerseyServlet which is intended as a base class for DS (Declarative Services) components providing Servlet services to the OSGi web whiteboard.
The JerseyServlet simplifies the approach outlined in Use Jersey to provide REST APIs from karaf applications.
Continue reading Simplified REST APIs from karaf using Jersey
OSGi is a Java plugin framework and module system that were initially created for supporting embdedded applications in the automotive industry. OSGi also forms the foundations for the Eclipse IDE plugin model. The plugin model of OSGi consists of components waiting for services and starting and exposing services when all of the dependencies are satsified. A “service” in OSGi terminology, is a Java interface.
I first encountered OSGi in 2006. The company I worked from used OSGi as the basis for an ETL processing system implementing various processing elements as OSGi plugins plugging into the processing framework. Since writing OSGi activators (which was the state of the art for OSGi plugins back in the day) is kind of boring, we created a Dependency Injection system on top of OSGi.
After creating the post Pluggable databases for apache karaf applications I posted a link to the blog post in the karaf user mailing list, and the immediate response was, “why didn’t I just pax-jdbc-config instead?“.
The answer to that is that I didn’t know about pax-jdbc-config. I started using pax-jdbc in the summer of 2016, and started using apache karaf in the autumn of 2016 and pax-jdbc-config didn’t exist then (or at least: not as complete and usable as it became in 2017), and any announcement that has gone past since then, has not registered.
Continue reading Rewriting applications to use pax-jdbc-config and liquibase
Edit: I no longer use this approach. I use pax-jdbc-config instead. See the article Rewriting applications to use pax-jdbc-config and liquibase for details
Continue reading Pluggable databases for apache karaf applications
Steinar Bangs blogg 