I don’t want to make a blog post about licenses, I am not an expert. Keeping it simple: beside commercial "Closed Source" code (e.g. the Microsoft Windows code) the Open Source code can have a varying degree of copyleft. There are permissive licenses, like MIT, Apache 2.0, and BSD, which allow any fair use of their code (linked or embedded). There are less permissive licenses like the LGPL and the GPL with classpath exception that allow the code to be linked by any other code (so in Java terms, you can have dependencies with those licenses), but not embedded (or, more likely copy-pasted). Finally there are licenses like the GPL and the AGPL which are considered strong copyleft and viral: if your code links a library with GPL code, then your code too should be licensed as GPL. This of course is acceptable if you are developing a open-source project, but it may be not if you are developing a commercial application.

If we are talking about commercial applications, it is not even black and white, it really depends also on many things like: is your application a service, or a product? Is your application residing on the customer premises? is your application charged on usage or as flat? and so on and on.

As you can understand the terrain here is very flaky, and many commercial companies try to stay away from GPL and similar strong copyleft code. Moreso, the commercial code embedding or linking open source code is required to attach the Licenses of the dependencies with the delivery software as well. So, you may end up being requested to audit code like it happened to me.

You would think that managing and auditing licenses in Java would be easy. The natural solution would be to use Maven during the CI builds. And this means, we are looking for a Maven plugin just like Jacoco, CheckStyle or similar.

I found out, however, that it is not that easy :). Yes, you can produce a mvn site and retrieve all dependencies and transitive dependencies on your project, including the licenses, and audit that potentially huge list. You can actually easily use the official CodeHaus maven-license-plugin for this (pretty fast and complete). This is after all the solution that we adopted at my workplace.

However, it would be really more useful to have an automated way to alert me if my project was using dependency artifacts with permissive or non permissive licenses and potentially fail the build. Surprisingly, the web was not very generous and I only found out about sparse experiments like https://github.com/mrice/license-check and https://www.ayoy.se/en/blog/2017/10-27-maven-license-plugin/. I could not make the first work, as the code seems unmaintained.

So i said, let’s take two pidgeons with one stone: I will produce the plugin that I want and in the meantime I will also learn how to produce a Maven plugin myself.

Again, turns out that the Maven documentation to write a plugin is not that easy, and I bounced a lot between the official maven.org documentation and StackOverflow.

In the end, I was able to hack something in the last two weeks on my own, that I think does the work. It is very basic, but has parametric configuration and I believe it is easy to use. You just need to follow the directions on the GitHub https://github.com/carlomorelli/licensescan-maven-plugin Readme file. Here is a summary:

1) Put the plugin configuration in your pom.xml:

2) Put the JitPack repository in your pluginRepository management block — this is required as the plugin is not published on the official Maven Central yet:

Here is the outcome of mvn clean compile for a simple Spring Boot project I was using to test the plugin:

Hacking Maven plugins is a strange thing. It feels OK, there is an automatic IoC managed by the Maven toolkit so passing parameters is not very difficult. But the documentation is a little bit lacky, so most of the times you are just guessing. Again, god bless StackOverflow.

Also I coded the plugin on Java 1.5 standard. I am not sure if forcing 1.8 would have made things not working on older projects. What I am sure is that once you learn Java 8 streams, it really sucks to program with the old for loop style. If you ever take a look at the code, please be gentle with the Mojo code :)

Tests? Not yet unfortunately. Maybe in future step releases as I find a good way to test the code. Right now I am experimenting with the official maven-plugin-test-harness, which is something very ancient (I mean, it is based on JUnit 3.x …​ ), but allows to hijack the dependency injection for testing.

And by all means, contributions are welcome.

In a previous blog post I discussed how I was moving the database backend from a H2 instance to a fully fledged Pgsql with connection pooling. However I was going to keep the H2 conf for testing, so I end up with a static Factory class that can provide the desired DataSource implementation: Factory::getPostgresDataSource and Factory::getH2DataSource.

This DataSource impl is used in the app code. Let’s assume for a moment that my app runs with a normal p.s.v. main() funcion in the App class. That is, we have something like this:

In this case switching from a DataSource implementation to the other would not be such a pain after all.

However, things get complicated when it is not the frontend App class that uses the DataSource object, but some internal class. For example, a common pattern in enterprise Java is to have a Repository class that abstracts data manipulation for the frontend App class — there are several reasons why this makes sense, like for example the mantainability according to SOLID design. So let’s assume instead that App has a reference to Repository and that it is Repository that needs a DataSource instance. Something like:

What happened now, is that the DataSource is not manageable anymore from the frontend. Granted, if we want to change the DataSource impl to be the Factory::getPostgresDataSource instead of the original, we can go to the Repository class and tweak the ds = …​ line. The problem is that if there are more other "middlemen" in the app structure other than Repository, that need to use a DataSource instance, things will go awry pretty soon: if by mistake we are using, say, DataSourceImpl1 in one part of the code and DataSourceImpl2 in another part of the code, what is going to happen?

So the only solution is to centralize somewhere the "configuration" of what DataSource implementation we want to use, say, in in the App class itself like we were doing originally, and to inject the chosen DataSource implementation from there into Repository. In other words: we have to change the Repository code so that the DataSource dependency is injected in the constructor by the caller, instead of being created over there:

This is basically what Dependency Injection is all about: to make code more manageable, we centralize all chosen configuration of interfaces and inject it in cascade through the object constructors.

When working in structured manner (the aforementioned SOLID method), DI is very useful for unit testing. We can test separately pieces of code and mock the needed resources. In my case, I want that Repository uses the Postgres d.s. in the real world scenario, but the H2 d.s. in unittests. Unit testing then is relatively easy:

Of course it could be the case to totally create a database mock (e.g. using Mockito) instead of relying on H2 for testing. It does not matter though, because in the @Before function we would just write ds = mock(DataSource.class) instead of taking an implementation from Factory, but the injection of ds into Repository would still be done in the same way (the tests would not change…​ nice!).

Dependency Injection as a concept is not difficult to grasp. However, complex projects need to inject multitudes of configurations in multiple different places, and so DI easily becomes a burden.

Google Guice to the rescue! Guice is a DI framework oriented to simplicity and in-code configuration through the power of decorators. First, we need to add the dependency to the project pom.xml:

Secondly, with Guice the DI configuration must be done within a class extending the abstract class AbstractModule provided by the framework itself. Let’s call this class AppConfig:

The bind(this).to(that) DSL is very readable and intuitive: the this must be an interface, the that must be any implementation of that interface, that’s it!

More precisely, you have to master few different variants: if you get the implementation from a factory (like in our example), you have to use the .toInstance() DSL, but if you get the implementation from a written class, the correct syntax is .to().

There is a little other step to do in the actual App class code, and is to retrieve the configured implementation in AppConfig within the App class itself, using the Guice::createInjector function:

So the net number of lines has slightly increased, but the DI configuration is now isolated in its own class. If we want to switch from H2 to Postgres, we just go to AppConfig and modify the line in configure() as bind(DataSource.class).toInstance(Factory.getPostgresDataSource()); without even touching the Application itself or its dependencies.

Needless to say, the very same approach can be done in unit testing: we can create an independent TestConfig class extending AbstractModule, and in the RepositoryTest discussed in the last section we would simply change the line in the @Before function like this:

and the tests would still work as they did previously, no line of code should be touched other than this.

You can see that DI is a very important piece of the puzzle in writing enterprise-quality code. In must be said though that it is a pattern coming from how Java (and C#) are structured and have traditionally been programmed — especially considering the evolution of those languagues and what became a pattern (DI) and what became an anti-pattern (not using DI when having multiple implementations of interfaces).

Other languages don’t have interfaces and in those kind of languages DI management is simply impossible (as also mocking is impossible). Some of these, like Python, have evolved in time and even if they don’t provide interfaces, they provide Abstract Base Classes (ABCs) as injecting point, so DI and mocking are possible.

Hope you liked my tutorial!

On my Windows pc I like to micromanage the system and keep things tidy. If a software I need offers the 'zip' binary archive to download instead of any MSI/EXE installer, I usually go that way.

I put normal software blobs in a C:\opt folder, and if it is developement-related software, I use the C:\workspace\opt folder (as C:\workspace is the root of all my code). Yes yes I know, bad habits from Linux…​ moving on :P

It happens that Postgres offers precisely this: https://www.enterprisedb.com/download-postgresql-binaries. So time to download the Win-x86-64 blob for version 9.5.6 and unpack it.

The binary blob provides not only the classic Pgsql commands (initdb, dropdb, psql), but also the handy pgAdminIII frontend. In the root folder of the unpacked software (in my case, C:\workspace\opt\postgres-9.5.6\), then, create the batch file launch_pg.bat with this content:

If you are wondering, %~dp0 variable return the current directory — that is, the directory where the .bat file is being executed.

WARNING: The first run of this script will initialize the database in the %PGDATA% directory with the initdb line. For the following launches, remember to comment that line, otherwise you’ll see some error message popping up.

At this point, I am basically done: I’ll just create Desktop launchers for both this .bat file and the pgAdmin.exe file that you can find in bin\. As you can understand my need is to launch and terminate the server on-demand.

However, other people may want to launch Postgres as system service or scheduled task (at startup). If that’s the case, I suggest to create a startup task in Windows' Task Scheduler in Control Panel.

Few words on why I chose Postgres? Basically, because it is mantained and popular, it is the one I felt more confortable together with MySQL, with the advantage that installing it on Windows is relatively painless — as you can see. Also, apparently it is the most lightweight of all: my home machine is not that great — it’s a desktop-replacement laptop from 2012 with Windows 7, so no heavy loads thank you :-). In general the choice was limited to the followings:

The drawbacks of using a SQL RDBMS instead of a NoSQL db is that it is more complicated. You have not only to manage relational data in SQL transactions (which don’t always map easily to object-oriented patterns, regardless of what you thing of ORM libraries), but also you have to account for Schema formatting and preparation in your app, database migrations and so on.

In a next blog post, I will discuss how I manage Postgres (via a connection-pool) using the canonical Java JDBC way. Stay tuned!

This should appear in the pom.xml:

You actually only need the Postgresql (which is actually the Postgres JDBC driver for Java) and HikariCP dependencies. The reason why the other dependencies are shown is that the code that I will show you now is also managing the old H2 db instance I had before this change (which I’m retaining for testing), and uses the library SQL2o for submitting queries — more on this in the examples.

Using Hikari is very straightforward. Instead of instantiating a connector to the Postgres JDBC driver directly, we have to instantiate the javax.sql.DataSource implementation of HikariCP: A configuration file in src/main/resources will worry telling Hikari how to connect to Pg and which Driver class to use:

The config file content should be something like this:

Because I’m preserving also H2 in my project for testing, I will create a DataSourceFactory class that can return the DataSource implementation that I want, for example using some Dependency Injection lib — but this is a topic for another time.

What I usually do at this point, is having a a Dao class that masks, or abstracts, the database interactions. In the future, I want this object Dao to be injected, so it will have a constructor that gets a DataSource implementation, coming from the static Factory that we wrote before. As mentioned, I’m using Sql2o library which is a nice wrapper of SQL statements in object oriented form (it is NOT an ORM like Hibernate, it is just a SQL formatter). So the Sql2o main class accepts DataSource injection instead of direct DB connection so we end up with a Dao class like this:

Aaaaand, to wrap this tutorial up, here is how you would use the Dao in the caller code:

Clearly it is not worth the pain of managing a DB server if you only manage a single kind of entity (Person.class). The focus of this tutorial is not really the complexity of the data to manage, but how to build the persistence layer of your application is a structured manner and to be ready to switch database under the hood — and also some advanced information about connection pooling :) Hope you liked it!