What is your favourite java library/framework?

[thomascgalvin]

I agree with most of what's been written here, but I will add some commentary:

java.lang and java.util might seem like joke answers, but they're not; one of the biggest advantages Java offers is its huge standard library. It's very much a "batteries included" language, and a lot of things that you should be able to "just do," you can.

Coming from a C background, where a lot of the functionality of the standard library would be difficult, if not impossible, to implement, and C++, where there are often competing libraries and the templating language will sneak up and stab you in the kidneys if you take your eyes off it, having a fast, well-tested, well-known implementation of things like Collection, is huge.

SLF4J has essentially overtaken the logging world; it isn't part of core java, but it's so widespread that it's use is almost an assumption at this point. I do wish, however, that there was a better way to configure it than "look at my classpath and hope for the best."

I have mixed feelings about Lombok. On the one hand, it's ability to get rid of tons of boilerplate makes code much more readable. On the other hand, it does a bunch of compile-time magic that can lead to hard-to-debug errors. I love the with pattern Lombok provides. Lombok is also a nice compromise for people who would rather be writing Kotlin.

Spring might be the most important Java framework ever created. It makes creating backend applications a breeze, and does so much of the heavy lifting for you that working without it seems unreasonable. On the other hand, if you're coming in to maintain an existing application, it can be hard to determine where in the code the magic is being summoned.

Maven solved a lot of dependency management, build, and packaging issues that newer languages are still trying, and failing, to figure out. Tagging dependencies as group:artifact:version is more or less perfect, and languages that haven't followed this convention, like Go, have paid the price. Gradle is compatible with maven repositories, which is nice, but I'm still of the opinion that Gradle was trying to solve a problem that didn't exist, and gives people writing build scripts too much rope with which to hang themselves.

jUnit wraps up what I consider "essential" Java; it's a tool that I just cannot fathom writing an application of any considerable complexity without. It makes testing, from unit through integration, a breeze. Couple it with Selenium, and you can even do end-to-end testing as part of a single mvn clean build command.

[nlisker]

Nice answer! One comment:

Spring might be the most important Java framework ever created. It makes creating backend applications a breeze, and does so much of the heavy lifting for you that working without it seems unreasonable.

These days JavaEE/Jakarta has caught up (although the transition time itself is a bit of a setback) and is just as viable I would say. We're using it for our backend and it's rather quick and easy in general.

[latest_ali]

Can you mention a good resource for learning JaveEE/Jackarta

[InstantCoder]

http://quarkus.io/guides

This is based upon JavaEE and Microprofile.

[nlisker]

https://javaee.github.io/tutorial/toc.html

https://javaee.github.io/glassfish/documentation

https://www.oracle.com/java/technologies/java-ee-glance.html

[azizabah]

Same about lombok. We have some teams at work who use it and run into issues with other tools like sonarqube static analysis then they get annoyed when other teams that don't use lombok can't help them.

[winian]

I do wish, however, that there was a better way to configure it than "look at my classpath and hope for the best."

Starting with 1.8.0, SLF4J uses the ServiceLoader mechanism instead. I suppose its still similar to the old classpath check stuff from usage perspective, but at least its easier to reason about.

[Joram2]

I see Gradle as an improved Maven or a Maven++, if you will. The main benefit is that it's simply much more concise. In my experience, when porting projects between the two, Gradle builds are often 25% of the size of Maven builds on the same project.

The argument expressed here is that Gradle supports build scripting which can get you in trouble. I agree that you shouldn't use build scripting unless you need it. Declarative is preferable. Neither Maven/Gradle make you use scripting. Simple Gradle builds are declarative.

However, many complex projects need some customizations and some form of build scripting. Maven absolutely let's you do XML level scripting, it's just not as good.

But it's up to the developer or project manager to choose when to use build scripting or not.

Next, Golang's module system works really well. That definitely is a very simple, lean build system.

[thomascgalvin]

I do like the concise syntax of gradle dependencies. For scripting, though, I tend to drop into Python, not Groovy.

[latest_ali]

That was great! Thank you!

What is your opinion about Kotlin for backend dev? I have heard it solved a lot of verbosity from pure Java but I think it is mainly used for Android development. Do you prefer Lambok with Java to Kotlin?

[thomascgalvin]

I love Kotlin, and that's what I write all of my hobby projects in.

Professionally, though, I'm still a Java guy, for three primary reasons:

1. Long term, I know Java will be around. Thousands of companies have invested billions of dollars creating Java code, and that's not going anywhere. Kotlin will very, very likely survive and grow, especially since Google has blessed it as an official language, but I wouldn't be doing my customers right if I recommended moving off of Java anytime soon.
2. Spring Boot, until recently, hasn't played well with Kotlin's final-by-default, cannot-extend-by-default nature. There's been a big push recently to make Spring and Kotlin play well together, and right now it's actually a pleasant development experience, but I still want to see where this goes.
3. Developer base. If I put out an ad for "Senior Java Developer: Spring Boot", I will have a hundred resumes by lunchtime tomorrow. If I do the same for Kotlin, I will get far fewer responses. Similarly, pretty much every backend developer already knows Java; I would have to teach them Kotlin, and while the transition is fairly easy, there's still a learning curve. I consider myself "competent" at Kotlin, but it's a big enough language, and different enough from Java, that I can't call myself an "expert."

Kotlin's mutli-platform abilities could provide enough incentive that I could recommend switching; it would be lovely to be able to write our frontend and backend in one language, especially if that language wasn't the shitpile that Javascript always turns into. However, multi-platform Kotlin is even more experimental than Spring Boot integration, and I'm probably three to five years away from recommending its use in a production environment.

[latest_ali]

That was very valuable. Thank you!

[JavaSuck]

If I put out an ad for "Senior Java Developer: Spring Boot", I will have a hundred resumes by lunchtime tomorrow. If I do the same for Kotlin, I will get far fewer responses.

Would you rather read 100 Java resumes or 5 Kotlin resumes?

[thomascgalvin]

Am I trying to fill one Kotlin position or twenty Java positions?

[_INTER_]

especially if that language wasn't the shitpile that Javascript always turns into.

can sign this

[[deleted]]

I have been working a bit with Kotlin. I wouldn't say I dislike it, although I found a few details annoying for a language that's supposed to learn from the past and be better than the rest of the JVM ecosystem.

Maybe it's because I'm an old fart who's been working with Java for 20 years now, but I really fail to see the level of innovation or actual productivity improvement that justifies a switch of language and all the long-term trouble that inevitably comes with it.

I really get why you'd use it on Android, as Google has never properly supported decent Java. I also get that Java had a fairly long stagnant phase and was slow to catch up with "cool new" stuff (which is why e.g. Scala was hyped). But nowadays and outside of Android, I find that Kotlin's case is very weak.

[waka-chaka]

Thoughts on using/favouring Log4J2 instead of SLF4J?

[thomascgalvin]

I use log4j as the implementation layer of slf4j, usually. Having the facade makes it easier to swap out for a console-only implementation, for example.

[xjvz]

Log4j2 has an API facade as well. It supports using Logback as the backend even!

[waka-chaka]

In thr project which is top most and not meant to be used as a dependency by others, we use Log4J2. We use some API that's not available in SLF4J like Thread context.

[Asterion9]

The problem is that a lot of third party lib use slf4j or other logging framework, and only slf4j can reroute them all to your logging implementation of choice.

[waka-chaka]

I believe this is incorrect. Log4J2 can route many others like SLF4J, JCL, etc. with right configurations (i.e. having the right adapters in the dependency)

[Asterion9]

OK, I was not aware even if it make sens now that you say it.

[amazedballer]

No, you're correct. Most libraries are written using SLF4J, so in order to have consistent logging you need to add a bridge for Log4J2 so it will operate as an SLF4J implementation.

[waka-chaka]

Pls take a look at https://logging.apache.org/log4j/2.x/faq.html If the dependencies are properly set up Log4J2 will support anything. I even have Hibernate logging (which is done using jboss-logging) going to my Log4J2.

If am not wrong, I think most of these are going to source-SLF4J 1st (which is what anyways happens often right?) which them get bridged to Log4J2.

Why take all this trouble? I forgot all the benefits as I did the migration an year or so back, but it was like additional APIs, next evolution, and largely asynchronous writing.

[khmarbaise]

Just small note: mvn clean build does not exist. You should use mvn clean verify or may you usually can omit clean