Sugar-like series (I)

It’s good, tempting, it comes instantly, but on a long run it will most probably cause some issues. What are the similarities when it comes to building applications?

Unnecessary mix of frameworks and libraries

So, adding yet another maven dependency might solve a particular problem “easily” and “for free”, we might say. Indeed, adding just a few lines of code in your codebase for using that library seems really tempting, and in the end productive, but:

Dependency Clash

It this going to make the dependency hell event worse?

Licensing

How is that library licensed? Is it in line with the rest of the policies?

Size

What is the size of that library? Will it significantly increase your build size, transfer time, application memory usage?

Security

How about the security? Does it come from a trustworthy source? (https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/)

Coding style

Does that library API affect the overall coding style of the codebase? E.g. Is it worth introducing an Rx-ified library while the rest of the code is entirely synchronous?

In order to properly address this kind of checklist, you might need to spent some serious time.

In the end, it could take less to just implement yourself that functionality.

On top of that, using one of the “pure” platforms (JavaEE containers, Spring Boot, Quarkus, Micronaut, Helidon) should usually cover most of the needs for regular applications. And such an approach comes with a huge advantage – all the pieces are tested and released together and you don’t need to worry about individual libraries versions (e.g. Jackson).