Seven tips to be happy as a Java Developer (or at least less sad)

Most Java Developers still are trapped working in Banks. These developers cannot simply stop writing bureaucratic code. If you already identified yourself, unfortunately, this post isn't for you, I'm so sorry, you're completely lost, but don't worry, I'm pretty sure there's a special place in heaven for people like you.
On the other hand, there are a few Java developers who could escape the agony of writing "enterprise" Java code and started writing Kotlin, Scala or even a non JVM language. If you are a developer like this one, this post isn't for your either (you're already happy, pal, dunno what you're doing over here).
In the middle of these two kinds of developers, there is this kind of special one. The kind of developer how still need to write Java code, but, they have the power to choose whatever tools they want to work with. If you identified yourself only now, there's hope. There are some tips that could change how you can write Java, making you more productive and even better, as the title says: start being happy.

From now on, I'll give you seven tips. You may already know some of them. You may already know all of them. But, also, you may not know none, and that's when I cry for you.


Use embedded containers

I'd say this tip is the most import one. This is where you start to create your whole application based only in one jar. No servlet or application containers. No need to set the environment up. Just the JRE and your jar, happy forever.
I never thought the idea of having a bootable application before creating my first one. It sounded like magic: no need to be stuck with Eclipse to run your application inside a container if you want to run locally, no need to setup a server with a servlet container, you just need to run a jar, and, voilà! There it is! The app is running!
When I remember the time I wrote WAR applications, I think: what have I done to myself? It was so painful! It was hard! Not all IDEs even supported container plugins, so, remote debbuging was the only solution to debug my apps, and, of course, using a container implies that you must be aware that you need to use the same container version at development that you have in production, otherwise it was very likely that you could screw a delivery up.

Use at least Java 8

I think everyone agrees: Java is verbose.
Too verbose.
And. This. Really. Sucks.
Don't get me wrong, even Java 8 is too verbose. But, there is something nice about Java 8: Lambdas. Which leaded Java 8 to another nice thing: The Java 8 Stream API.

I mean, I guess you can't say that this: (...)

public List<String> getAdminEmails() {
    List<User> users = getUsers();
    List<String> emails = new ArrayList<>();

    for (User u: users) {
        if (!u.isActive()){
        if (!u.hasEmail()){
        if (!u.isAdmin()){
    return emails;

(...) moving to this: (...)

public List<String> getAdminEmails() {
    return getUsers()

(...) is not a big improvement, right?

11 lines less than the Java 7 code and also with no mutability whatsoever.

Of course, if you're not convinced, this is just one example. There are a world of other examples. The whole idea of reactive programming got more palpable after Java 8. If you think callbacks can get messy, imagine callbacks based on anonymous inner classes. Lambdas made things easier and I guess everyones here agrees with that.

Use Gradle 4

Well, I don't like Gradle. I don't like any build tool, actually. Everyone of them sucks at somepoint. Gradle, for instance, don't have a REPL like SBT, but, Gradle is much faster, so, 1x1.
Anyway, if you're using Java, you probably will end up using Maven or Gradle, but, my advice here is: use Gradle. And not any version, try to use the last one. Gradle 4 is considerably faster than the old ones, and also you will find plugins for pretty much anything you want.

Consider using another JVM language to create your tests

Java sucks at DSL because Java wasn't design for DSL creation, simple like that. Knowning that, you could take advantage of one little thing: Java runs on the JVM and, guess what? So are many other languages which are very "DSL welcoming".
Have you have heard about ScalaTest? KotlinTest? Spock? Consider using one of them when you write your tests.

Move away from the enterprise world

Containers, EARs, Remote EJBs, etc. Stuff like that makes you be stuck at the enterprise world.
All of these things will make your Java application more bureaucratic, heavier, harder to test, to deploy, to integrate with other applications, so, you need to let it go. You probably won't need any of these stuff anyway.

Always automatize your deploy

This advice is useful for any language, actually. Always automatize your deploy. There are a few tools that will help you do that, so, if you're developing an application, any application, automatize whatever you can.

The lighter, the better

Here is where everything that I said before comes together. If you move away from the enterprise world, use the last Java version, create bootable applications instead of deployable ones, you probably will notice that: the ligther, the better.
And we can go even further: if you create microservices, it will be considerable more easy to create and maintain your applications. Of course, you need a certain governance if you have many microservices, but, it'll pay off.
There are tons of APIs and frameworks that will help you so, such as: Spring Boot, SparkJava, Apollo, Light-4j and so on. Any of them provides you several features to create these kind of applications.


There is no magic, if we talk about language features, Java are still behind most other langs. But, as you can see, you can make your life a little easier if you be aware what exists in the JVM world. =)

Any questions, sugestions or whatever, please, leave a comment.


Gabriel Francisco

Software Engineer at 99, 24 years, under graduated in Computer Science and graduated in Service-oriented Software Engineering. Like playing guitar once in a while. Oh, and I'm kind of boring.

São Paulo

comments powered by Disqus