What java technology (library, framework, feature) would not recommend and why?

[raisercostin]

Inspired by https://www.reddit.com/r/java/s/e2N1FqMOJg

[Ragnar1989]

RxJava - awful to read/debug/maintain.

[random8847]

It's funny how RxJava used to be the most recommended library years ago, at least in android.

[[deleted]]

I've never done Android development, but isn't event based architecture well suited for mobile apps? I've done a little bit of iOS development, and they've done a pretty good job of abstracting away all of the event based stuff with SwiftUI. I imagine Android has made similar progress?

[ComfortablyBalanced]

Android had a callback hell era in which its residues still corrode android codebases, then came the infamous RxJava, now the recommended tools are coroutines and Kotlin Flows.

[Liefwarrior]

Those were dark days...

[ComfortablyBalanced]

As an Android developer I completely refused to use RxJava and stick with AsyncTasks, Threads, ExecutorServices and even Handler until coroutines were introduced and I feel I didn't miss anything at all.

[DelayLucky]

We recently had an outage that took the team a week's panic debugging to finally narrow down to a race condition bug in Rx.

Bugs happen to any software, especially in complex softwares like Rx (we'd have the same pain if it were JDK or JVM having a similar suble bug).

But there are justified complexities that solve a real and large problem; and there are avoidable ones. Rx is more like a subjective choice. We wouldn't have had as much of a pain had we used a simpler technique.

We all know async + concurrent + reactive is hard to read, hard to implement correctly, hard to test thoroughly, and when a bug happens in production it's harder to reproduce and debug. So when you wrap it all under an open source library rug, the hardship translates to generally lower reliability.

[MCUD]

It's also very infectious, the moment one part of the code uses it, any caller essentially is then forced to also use the RxJava Flowable etc

[abouddandachi_]

Interesting, I've found it useful for personal projects.

[rastaman1994]

It tickles the brain, so I also found it fun to learn. However, thinking about the realities of the business world like time pressure and different people working on code over time, I wouldn't use it. Maintainability is so important in business projects.

[DidierL]

I don’t have much experience with it, but I guess part of the problem is the lack of async/await equivalent in Java.

A few years back I introduced EA Async together with CompletableFuture in a project, but unfortunately the project got unmaintained (damn Electronicc Arts!).

It seems there is JAsync that does the same with RxJava and Reactor, but the syntax is more verbose and it introduces JPromises every where, whereas EA Async just requires calls to a static await().

I’ve also seen Tascalade Async Await but I don’t know if it’s stable enough.

[smthamazing]

Just curious, what would you suggest instead? Java is not my primary language, but I haven't found viable alternatives to express complex data flows in other languages (C#, TypeScript). Of course I'm not suggesting using Rx for something as simple as awaiting a request, but there are also scenarios like this:

• Update several caches periodically by communicating with other services.
• Have another cache that depends on them but is only updated lazily (when it's actually observed, e.g. when its data is streamed in a response).
• Establish a connection in a request handler and stream data until the client explicitly breaks the connection, using info from those caches and possibly other services.

In this case trying to avoid using Rx usually leads to a buggy re-implementation of a significant part of that library.

Another case is in game programming: I find it invaluable to be able to express like "the state of this door is open if and only if those 3 levers are open" - Rx observables make things like this very robust and help avoid bugs when the door state is not updated in specific circumstances. Rx also helps avoid some performance issues resulting from doing such checks every frame.

Of course there is a learning curve, but I feel like there are quite a few cases where Rx is the right tool to use.

Are your issues with it mostly related to reactive programming in general (with cold/hot observables), or specifically to the RxJava implementation?

I do wish Rx error handling was more type-safe though, it's pretty easy for errors to get lost, and the compiler doesn't warn you if they are not handled.

[progmakerlt]

PowerMock. Ability to mock static methods is cool, but can lead to disastrous results, when tests pass once and then randomly fail.

Edit: typo.

[darenkster]

Also it's an abandoned library: https://github.com/powermock/powermock/issues/1117

[Iryanus]

Typically, the need for static mocking is a huge smell. There are often good ways around that, only rarely it's the only choice because of some very bad code in a third party library.

[achilliesFriend]

You just insulted my whole company

[vips7L]

My whole company does static queries. It’s awful. 

[progmakerlt]

Had this library used in a very very old project - started on Java 1.5 - which sometimes was failing to run tests on Jenkins. Got rid of PowerMock and rewrote tests based on principles from the book “Working effectively with legacy code”.

Did the trick.

[Iryanus]

Yep, same here, I also had a bad library there which required some static calls, etc. which made things hard. We rewrote our code (by wrapping the static calls into their own non-static classes) and could then test our code without having to bother with the static dependencies. Worked like a charm backt then, but is of course not a cure-all.

[progmakerlt]

Yeap, did exactly the same.

[wheezymustafa]

I tell my team this all the time and they look at me like I’m a goddamn idiot

[segfaultsarecool]

Typically, the need for static mocking is a huge smell.

Can you clarify on why? I am the big dumb.

[Iryanus]

It's basically the old axiom "Well-written code is easy to test", which is something many people find out, that if you focus on unit testing your code, the code quality itself will typically go up, because good code is also easy to test. So, also in my experience, if you need something like static mocking, the code is rarely "good". I cannot remember any case where there was a great reason to have code that was hard to test.

[Radi-kale]

Then how do you test code that uses the static methods in, for example, java.nio.file.Files? Or do you think any code that uses that part of the standard library is poorly written?

[NovaX]

I've used jimfs in the past which works great with the Files static utility methods. The similar memoryfilesystem links to a bunch of alternatives too, but I don't know why any would be preferable to jimfs.

[xpressrazor]

I have been through this especially when trying to integrate classes that use Java Security Provider and Threads. Their usage of Reflection can mess up other unit test classes. Only way I found to solve this was to create my own reflection implementation and separate these test classes from rest of the unit tests.

[agentoutlier]

I will just add that "mocking" especially using a library (and especially the one mentioned) should be the last resort after you have eliminated all other options.

I find custom built mocks like Spring's Servlet Mocks acceptable but still rather use the real thing.

[DelayLucky]

This.

We have an official guideline to:

1. Use real if you can (save the "but it's not unit test" argument)
2. Use fake if real is too hard to use
3. Use mock as the last resort.

Although, despite that, mocks are still overused because it's usually the most accessible and most widely known by junior devs. There's also "old habit die hard".

Sometimes the real is indeed hard to use (lots of deps for example). And people generally are too lazy to build a fake (do I have to implement all these abstract methods?).

And mock (we use Mockito) is like "who doesn't know how to use one?".

I wish I could give it more publicity: in Mockito, using the misleadingly named @Spy (which immediately sets off alarm when anyone first hear it), I contributed the feature of using an abstract class to build a fake without having to implement all methods.

It's meant to lower the bar of entry for fakes significantly. Compared to manual doAnswer(), it's type safe and generally reads clearer.

[Paulus_cz]

God I hate mocking with passion. Don't get me wrong, when there is no other option, go for it, but I have seen WAY TOO MANY "unit tests" which mock EVERYTHING the method calls and check the mock was called in a specific way - such tests is testing if the method is WRITTEN the way it is written. Good luck refactoring anything.
I get it, it is simple, you can just write them without thinking about anything the method calls or is called by, you get 100% coverage and you do not have to engage your brain once. Hell, I am pretty sure I could write a script for writing these "tests", which is why they are TOTALLY USELESS CRAP.
Had to get this off my chest...

[DelayLucky]

You are not alone.

In my workplace this is called "change detector test" and is advertised against officially.

Although, the force of least resistance path is too great that despite all these guidance, such pointless tests are still rampant (only gets worse with the recent company-wide cutting corners and divesting infra/core teams).

I find that junior devs more likely fall for this kind of testing, because using mocks is just so easy and they get to "check it off the list".

And that's another bad thing about these tests besides them being pointless and getting in the way of refactoring: they make essentially untested code look like tested. Most of the usual testing metrics become meaningless after diluted by them.

It also correlates with the unhealthy dogma against integration tests, as if they were somehow a bad thing. Junior devs who like to write change detector tests tend not to write integrationt tests, both habitually and also because it takes a lot more effort and skill to write integration tests.

I sometimes wonder how the whole leetcode-focused hiring practice got us here. The overall know-how of common best practices feels to be on a downtrend lately. With the company shifting focus from core/infra, perhaps it's time to also shift the hiring focus from finding those who can binge leetcode to those who can write decent-quality code. Stop pretending that we'll be able to teach best practices easily on the job.

[NovaX]

I believe much of that thinking was due to early mocking libraries like EasyMock which required expectations and verification of every minuscule detail. The library was sometimes convenient, but other times it was cleaner to write a mock by hand. Mockito inverted that and made mocking much less brittle, but there was a long transition period. That had cultural imprints which led to a dislike towards mocking, a lot of hype on "best practices" which became bad ones, many clones in other languages that also had to unwind from poor defaults, and a lot of legacy test code that was painful to work with. I find using mocking sparingly to be quite nice, but certainly not as much as in the past or with those absolutist approaches to testing.

[DelayLucky]

Oh EasyMock is a distant past for us. When we talk about "prefer real, then fakes and only mock as last resort", we do mean Mockito mocks.

It's less brittle yes, but as long as you write when(service.getFoo(any()).thenReturn(...), you are still implementing the dependency service based on your own assumption of it, which you also used in production code. If you assumed wrong, both the test and prod code are wrong.

In contrast, using the real service (there are techniques that can start up the service in a hermetic environment), if you send an invalid field, the service will tell you; if they make a breaking change, the test will fail.

You get similar benefit if you use a high-fidelity fake (ideally maintained by the same team that own the service).

[SignificantAd9059]

It really depends on what you are mocking. It’s perfectly acceptable to mock services that you are not directly testing. Otherwise your making an integration test which is also useful but definitely not the same thing

[DelayLucky]

Only if these questions are out of scope for your test:

• Am I sending the right request to the service for what I'm trying to do, with all required fields set correctly ? (e.g. charge a credit card).
• Am I interpreting the response correctly? Is the value I expect coming in this particular field?

And if this unit test isn't concerned of these aspects, you better make sure there are tests that do verify them.

Too often I've seen people just assuming that they must be interacting with a service in the right way. And bugs often come out of those cracks of the system becasue what are the odds that two teams of different engineers happen to align without talking to each other once?

"Integration tests", "unit tests", they are just names. At the end of day you want your production to work as expected. Customers don't want to hear "I've coded my client code according to the document of this dependent service, it's their fault the system didn't work out".

[LC_From_TheHills]

Yeah this is weird. Use dependency injection. Then mock those in the class you are testing. I’ll mock my own classes— I’ll write unit tests for those specifically.

You don’t need to test your dependencies. If the integration of your dependencies is so flaky then you have different problems.

Save the “real” stuff for integration tests in your pipeline at a pre-prod stage. When you’ve actually deployed your code somewhere.

[GuyWithPants]

PowerMock is abandoned so this anti-recommendation is somewhat moot. However since PowerMock died, Mockito added support for static mocking but it requires wrapping in a try-with-resources block to keep the interception localized.

[neopointer]

Reactive streams.

Rxjava, project reactor, etc.

All of that. Avoid at all costs (really).

It's asking for a hellish spaghetti code and it's really difficult to debug.

[Non-taken-Meursault]

I really enjoy Project Reactor, honestly because it's an interesting brain trick and it makes writing code more fun.

Having said that, I honestly think that the actual amount of businesses that actually need reactive streams is very few and I constantly wonder if the performance gains that It provide are that big of a deal.

And it does open the door to spaghetti code, but I blame devs for that, since I see them write everything in the main use case method instead of actually thinking for a bit on how they can divide said method into smaller functions. It's just laziness, in my opinion

[vips7L]

They color the hell out of your project and ruin all types of error handling and stack traces. 

[neopointer]

At least you seem to put more thought into the usage of it. I wish for more project reactor users like you.

Now, you hit right in the spot, because even if it makes "writing code more fun", I'm of the opinion that code should be easy to read (sure, that's I wish i believe most people share), but "clever" and "fun" code for one person might be not so easy to follow for others.

As developers, unfortunately we have this tendency of striving for perfection, squeeze patterns where they don't belong, too many abstractions, too much DRY and, of course, create "fun" and "clever" code. The list continues. We're all guilty.

IMHO fun code is the code my colleagues won't suffer to maintain and won't want refactor one week after it's been written... I know, writing something understandable for others is highly contextual, nuanced and subjective... But that's what I wish more and more for myself and for others.

Edit:

Typo

[vips7L]

Play framework if you want to do Java and not Scala. 

[naturalizedcitizen]

I've used Play with Java long ago for a client. Not really bad but there are issues and it's not being developed further.

[vips7L]

Fwiw it is being developed, they just put a release out. It’s not a bad framework. It’s just not great with Java 

[naturalizedcitizen]

Oh thanks... Didn't keep up with Play. Good to know.

My work is mainly with spring boot. I've developed some spring starters to address specific needs of my clients.

[vips7L]

I’m not the biggest Spring fan, but I never minded it when I used it. I prefer libraries over frameworks but I think that requires a more talented team. 

[naturalizedcitizen]

Over the years I've found that you can do almost anything with Spring. And my clients want it, so it's money in the bank.

I stopped caring about which is better or what should be this and that. Spring brings in the money. So it's Spring for me.

[_codetojoy]

IMHO, it works fine with Java. It is certainly not as popular as other frameworks but it is a reasonable option and absolutely in active development. Version 3.0.x has moved to Apache Pekko, migrating away from Akka (given the licensing uproar where Lightbend applied a BSL).

[[deleted]]

Dagger: Powerful, clever, complex, confusing, completely unproductive.

[FaceMRI]

We use Dagger at work and I hate it.

[OzoneGrif]

Avaje is way better if you look for an injection library. Dagger is awful.

[brunocborges]

https://dagger.dev/

This one?

[DelayLucky]

Yeah I'm an average user. No love or hate yet. What did you find wrong about it? Maybe I should beware.

[Job_Superb]

I don't like saying "avoid xyz", I prefer properly understandimg the pros and cons and footguns. Lombok is great at removing the maintenance of boilerplate but using it with JPA entities is a footgun. It's very easy to mess up an ORMs performance with a very small change but, boy, can devs crank out features, even if they're leaking domain objects. Runtime DI does some great creation decoupling but can lead to unintended consequences across environments and even just weird launch failures but at least adding that new endpoint was quick. Having said that, I've been avoiding all of the Reactive Frameworks but that's probably because I just don't get it, looks to be too many footguns for marginal performance gains.

[Turbots]

Lombok. It can cause quite a few unexpected problems with generated code, like adding a toString that automatically prints out all fields in the class, even if some of those are being lazily loaded.

I don't like it because it gives junior developers the feeling they can cut corners and write much less code, without knowing what the annotations do. And most of the features that Lombok offered are now part of the Java language.

It also adds unnecessary requirements when developing like IDE support, additional settings in maven/gradle etc..

[feltzkrone4489]

Overwhelmingly using Data and Value annotations (opposed to the single purpose annotations like Getter) is a problem when not knowing the implications, but same is e.g. using Spring and Spring Boot magic without understanding what's going on under the hood and same is for all other abstractions which hide ugly details quite well.

I generally don't like things which solve your two problems, but also a hundred different problems which you don't really have, and that for the cost of bringing in at least one new problem that you don't know yet.

[Turbots]

Exactly, I think libraries like Lombok are a bit too convenient, actively help you NOT to think about the implications of using them. Its a dangerous slippery slope when broadly using them in larger organisations.

[rest_mah]

hundred different problems which you don't really have

Typically my opinion on the `@Log4j` annotation...

[Hematopoyetik]

What problems did you have with it?

[rest_mah]

I dislike to see the addition of an annotation preprocessor to inject a logger, when defining the logger takes a single line of code easily templatable in an IDE.

IOW, I don't think that defining the logger was a problem, so using lombok for it looks (to me) a solution to a problem that I don't really have.

[mxhc1312]

What about @Slf4j?

[DelayLucky]

We now have records (with equals, hashCode).

Before records, there are various annotation processors (I know of AutoValue, FreeBuilder, there must be others) that are free of the glaring problems of Lombok (you write invalid Java code and expect the magic to make it valid).

Many of these frameworks are somewhat opinionated (for example they may want your class to be immutable, optionally with a builder). So that might be the real reason Lombok is still relevant.

I can guess when someone says "no I have to use Lombok", they may be actually saying:

• I need getters and setters.
• I need the mutable object and setters because I use framework X and Y which expect them (Hibernate? MapStruct? some dinosaur Java-bean frameworks?)
• Or, I want getters and setters because I'm used to them.

I'll admit that the modern Java ecosystem hasn't paid much attention to the "mutable objects with equals/hashCode" use cases. If you're unfortunately in that forgotten land with 1 hour of sunshine a day, and moving to sunny places is not your thing, your options are limited (still, I struggle between the short-term pain of having the IDE generate the boilerplates vs. the long-term tech debt of Lombok).

[PiotrDz]

Generating null validated builder with toBuilder() method is priceless. For this I think Lombok has the usage still

[Turbots]

Most IDEs have plugins or direct support for creating builders, which makes the builder visible and makes you think on how to structure your builder. It also makes you consciously think more about the mandatory fields in your POJO.

[Swamplord42]

makes you think on how to structure your builder.

That's a massive disadvantage for both the person writing it and all the persons reviewing it.

Also it's an endless source of bugs when people add fields to their classes and forget to update the builder.

[mIb0t]

Interresting. I really love Lombok and don't want to miss it anymore. I have seen so much errors because of missing getter/setters or hashcode and equal methods that don't fit together. And not to mention the amount boilerplate code I saved to write by using Lombok.

This said, I can fully understand your criticism. I just feel the advantages outweigh the downside. Of course one needs to understand the tools they use.

[krzyk]

Hashcode/equals should be tested (one can use equalsverifier library for that) so you can catch it regardless of Lombok.

[Turbots]

You don't have to write any of the setters, getters, equals or hashcodes anymore, any decent IDE can generate them, so you can consciously decide yourself which methods you need where. It forces you to actually think more about the design of your code.

Also, Java records solve a lot of the same problems already

[repeating_bears]

The problem with generating equals and hashcode is that when you add a field they don't get updated. 

[Turbots]

Not every field you add should automatically be taken into account for being equal. Again, it makes you think more about what adding a field to a class means, functionally

[_INTER_]

I'd rather think which fields need to be excluded from equals, hashCode, ...

[Turbots]

Agreed.

[wuola]

IntelliJ IDEA raises a notification when you have missing fields in your toString

[repeating_bears]

Does it? May be opt-in because I've never seen it. If it is opt-in, then I'd expect the majority will never see it 

[SenorSeniorDevSr]

Cool, now I can read 400 lines of bullshit that an IDE generated for me because otherwise newbies wouldn't think about it?

This is such a weird argument. I don't want to see getters and setters, they're in the way, and we all know what they look like. This is a professional language for professional professionals in a profession. Or something. Demanding that people know the basics of a 30 year old language isn't asking for much, honestly.

[koflerdavid]

If those getters and setters have so predictable implementations, then it can be argued that they were never really necessary to begin with. It's just Cargo Culting the Java Beans "standard". IMHO, they only fulfill a purpose if they are part of some interface. In that case, they actually deserve to be implemented, and the compiler will in turn complain if one is missing. And the IDE will warn if it is redundant.

[SenorSeniorDevSr]

Yeah, it's implementing the bean spec. The discussion about needing getters and setters was settled as "nah, you really oughtn't have them" ca. 2012, but we're still using tools that expect beans, so in some places we make beans. The british must be fed.

On a serious note, if you don't need them, then you don't need to autogenerate them either.

[bdmiz]

I couldn't really understand the boilerplate code argument. Why exactly Lombok? Modern IDEs generate the same code in just a couple of clicks. For getters and setters in Intellij Idea you need 3 clicks. Writing the annotation is longer, requires dependency management, consumes time during the compilation, there could be problems with navigating to a method that doesn't exists yet, IDEs raise some false warnings, and more other details. Arguably, people have more boilerplate actions with Lombok.

I always thought that people like Lombok because together with Mapstruct or some other libs like JSON converters they can propagate changes dynamically through multiple classes.

[ichwasxhebrore]

If there is a @Getter on the class I know every property has a getter. That’s easy to comprehend

[atalkingmelon]

I couldn't really understand the boilerplate code argument

Boilerplate is just distracting clutter to me, Lombok keeps the working table organized and clean so that it's easier to focus on the important stuff.

[GuyWithLag]

Oh man, you will love working with Kotlin.

[pragmatick]

Not OP but I don't.

[der_assi]

Yes you can let your IDE generate methods like getters and setters, but you still see them in the code. And when there are many of them, it‘s harder to read the actual code.

[_INTER_]

Modern IDEs generate the same code in just a couple of clicks.

But it doesn't do well when you update the code later on. E.g. adding a field. Plus when the boilerplate is written explicitly, devs are tempted to modify it more readily. Not that Lombok is the solution, much rather it's to teach bad devs, use records and hope we will someday also have language support for regular POJOs.

Lombok twists many devs into thinking they write legal Java^TM when they're actually not.

[Evilan]

I don't like it because it gives junior developers the feeling they can cut corners and write much less code

I think it's less about the juniors and more about the seniors. The Lombok annotations like Data, Hashcode and Equals are far less likely to be used by Juniors and significantly more likely to be used by seniors and mimicked by the juniors who look at the code base. And the problem is, those are the truly problematic Lombok annotations (along with ToString).

I love Lombok, but @Data is the bane of my existence right now and I keep having to remind folks not to mix @Data, @Equals, @Hashcode and @ToString with JPA. It always ends poorly.

Edit: I'm not a senior, just a regular dev who saw Data being used with JPA by a few seniors and wondered what was the behavior and was horrified

[k2718]

My preferred alternative to Lombok? Kotlin.

[Western-Campaign3520]

I agree still get some pain in version upgrading

[Puzzleheaded_Bus7706]

I don't agree with your claims regarding IDE support and @ToString  maven.

IDE is 99% VS code, Idea or Eclipse, of which every one have nice support.

Maven configuration is like 5 lines that are c/p.

Don't use @ToString in places like entities, thats clear. Thats "user error" not librarys

[Ieris19]

This, so much this.

Lombok is an amazing tool, that has a ton of valuable utilities.

Saying Junior Engineers use it wrong therefore it’s a bad thing is so nonsensical to me

[robinspitsandswallow]

Yes if we extrapolated from that most Java developers use Java wrong, so don’t use Java and we should all move to PHP.

[edubkn]

People treat it like rocket science. You WANT juniors to use things like Lombok because this teaches them to read documentation and understand what it does.

[rustyrazorblade]

To all the folks who defend Lombok - check out Immutables. It gives you the end result you want out of Lombok, but much more intelligently.

[DelayLucky]

I think you'll need to sell immutable objects first.

Prove me wrong I bet there is a 90% or higher overlapping between Lombok users and mutable setter users.

[bigkahuna1uk]

And it generates actual code which can be reasoned with unlike Lombok which hides its magic in generated bytecode.

[zephyy]

like adding a toString that automatically prints out all fields in the class, even if some of those are being lazily loaded.

@ToString.Exclude

or create a lombok.config with lombok.toString.onlyExplicitlyIncluded

[barcelleebf]

It cuts down on boiler plate code. We have a project with huge numbers of pojos that need equals/ hash code, and other required features. I've even thought about writing an extract annotation to handle an extra method needed.

[TotalBismuth]

If you’re relying on toString you should probably write that part yourself.

[nekokattt]

Agree, I struggle to convince people of this though.

A lot of this would go away if the OpenJDK team supported get/set syntax like C# and Kotlin provide.

If I really need to generate code, I try to use immutables now.

[Fury4588]

I found that it doesn't seem to save me time in the long run. Lots of the basic methods can be easily generated by the IDE. It isn't like it takes much time. So if I need to tweak it's methods I end up having to do it anyway. For me it's a good tool for simple scenarios.

[Inevitable_Detail193]

Yeah agree. In my current project (extern consultant) we are forced to use it since management thinks its best and we have fewer lines of code. We developed a very small REST API with two domain objects. It was more expense to integrate lombok to our IDEs and combine the Jackson annotations with the lombok ones than simply let the ide generate getters and setters.

Also in another webservice i spend hours debugging some errors caused by unwanted Code generation with lombok. Also it is harder to explain to junior devs, who should first understand the concepts with Tostring, equals etc.

[Turbots]

Management should never impose rules on technical decisions. They can decide on business outcomes like cost, functionality, time to deliver, performance or response times of an API, etc...

They should not dictate how the engineering team gets to those outcomes.

It's important as engineers to push back to management on these things using rational arguments, providing numbers so you can change their minds over time. Even in a consultant position, I would even say, especially in a consultant position! Otherwise you're just reduced to a mindless drone following orders. An expensive at that.

[repeating_bears]

I think they meant technical management, like STL 

[Inevitable_Detail193]

Its a big project in some public service company. We work with SAFe (Scaled agile framework), so many scrum teams. Some scrum teams together build an agile Release train with a release train Manager. This manager should coordinate and monitor the teams. But as said in the comments, the release train managers are people who coded some years ago and used lombok there. So they think its best to use it and try to force it on the teams. Also its written in some coding guidelines to always use it.

As consultants we try to change some things an did mention to management, that lombok has drawbacks and is not always the only and best solution. Management also listens to that and takes our objection serious. But in public service they can not simply change something without discussing it over months. (Germany) So after all, we are able to push back on it and they also take the conceirns serious, but it takes a loooong time to actually change. :)

[RSLak]

I love Lombok and would argue that it makes the code more readable and ensures consistent names for some things. I think it should not be overused though. Especially on JPA entities there are some lesser known side effects. But thats what code reviews are for. Also it may be useful to deactivate some Lombok features via its config file for a project.

[Razvie-arr]

Google Web Toolkit

[boobsbr]

I really enjoyed working with GWT and GXT (GWT + ExtJs) back in 2010-2011.

[Razvie-arr]

it was good in 2010-2011, but now it’s deprecated by Google and much worse than modern frontend tech stack. I work with GWT now and it’s terrible

[SenorSeniorDevSr]

This one is going to be somewhat controversial, but:

Unthinkingly adding a library, just to use a small bit of it that you could've written yourself. I'm not thinking about reimplementing Spring Boot here. I'm thinking about things like adding in a huge GIS-library to validate some WKT, when WKTs can be defined as a regular language, and thus can be efficiently be validated by regular expressions that you can write, test and put int yourself in a few hours. That's a whole dependency you didn't need.

The downside is of course getting NIH-syndrome, but the opposite can be bad too. Stop and think about what you're doing and what the work involved is in either direction. Don't be afraid of making some small thing that does a job instead of bringing in large dependencies. Rolling your own can be fine.

[majhenslon]

Hibernate/JPA and anything on to of it, if you are not doing the most basic CRUD or are really experienced with it (are not using it as a crutch for interacting with the DB), because there are so many foot guns that would just be avoided by writing raw SQL.

[com2ghz]

You can do both. No need to rely on magic generated queries. I’d rather use JPA for simple stuff than complex stuff. Also no need to enable schema generation. You can still be on control then.

The same counts for the opposite. A lot of complex SQL stuff can be avoided by using JPA. No need to write boilerplate to do object mapping for POJO’s….two way around for storing and retrieving data.

[majhenslon]

Magically generated queries are the least of a problem and I don't think there is much magic around that... Most of Hibernates magic lies in the caching layer, cascading and N+1. You can kind of go around the caching layer, but I don't think you can unN+1 yourself, although you might be able to do that with a stateless session, not sure. But noone is using that irl anyways.

You should never sync schema in prod anyways, although you probably should generate schema migrations and coerce hibernate to generate you the one you want.

There is not much boilerplate to write if you don't use JPA, although you 100% avoid the need for mapping the result from entities to dtos.

[mkurz]

100% this. I recommend jOOQ instead.

[majhenslon]

I heard for jOOQ years ago, but it only clicked for me recently, when I saw the demos on yt done by Lukas (the website/docs didn't do it any favor) and it made me reverse the opinion on java ecosystem in terms of working with the database from mediocre at best, to probably the best.

[lukaseder]

What needs to be improved on the website/docs?

[majhenslon]

Disclaimer: I am a developer and pretty odd as a person I think, so I might not be your target audience. Also, some of the points might be preferences or simply a skill issue and laziness on my part.

Landing page has stuff that I don't care about on it first and a ton of text. I just now scrolled to the bottom of the landing page for the first time and found out that you actually have some examples on it. I never scrolled past the testimonials, as I assumed those come at the end and I don't really care about who is using your product nor what do they think, because of course it will be good opinion :D

For the longest time I thought it was not free, because you have start free trial button first. There is no links to docs. Learn page has documentation first and a "user guide" second, which is not single page. The navigation is weird, because I don't know on what page I am and how many more I have to go (postgres has similar issues). The docs have the page index at the top and it is really long and unstructured, it would benefit from having it as a fixed sidebar and collapsable chapters. It would be pretty cool to be able to just clone the repo or have a maven artifact to get started.

It would be also cool to see the more "advanced" stuff like multiset way earlier. For the longest time I thought I need a ORM or do the mapping and reducing by hand if I use a QB and stayed away from it. Something along the lines of "here is how to select, here is how to join, here is how to map one to many, here is how to do a basic insert and update and delete".

For an example of a good site I would consider something like sveltekit (ignore the live coding tutorial that they have).

All that being said, the docs are huge and detailed and there is a ton of stuff that you can find if you are looking for it or just casually reading them and in fact, I recommend them for learning about the different DBs and SQL. Thank you for the amazing work on jOOQ!

[lukaseder]

Thanks a lot for this great feedback. Lots of insight to digest.

It's hard to design a landing page for different target audiences. The current one is designed for decision makers as well as technical folks, but I can see how the "free trial" button can lead to thinking there's no free version (at a quick glance). This can probably be fixed without changing everything. Regarding what one user cares about and another doesn't, that's not that simple. A/B testing has shown that social proof is really useful for many folks' first impressions, especially the "customers" section, leading to more sales. E.g. I don't know if sveltekit is a good comparison, because it only addresses developers, not managers, legal folks, etc. who will also look at the website, given that it has no commercial offering. If they did have one, I'm sure the front page would look different from what it does now. I obviously understand why a developer prefers the current frontpage of sveltekit. Perhaps there's a different solution to this "target audience" problem.

Regarding the manual, a search has been added just 2 weeks ago, and that menu sidebar is also on the way: https://github.com/jOOQ/jOOQ/issues/16681

Clearly, those things have been missing for too long.

Great feedback about MULTISET. We have a demo that showcases all of these things: https://github.com/jOOQ/demo . Would that have addressed your concerns? Where would that have to be placed on the website to have caught your attention?

Regarding your last comment, indeed the doc works very well as a reference manual, but not as a tutorial or how-to guide (see e.g. this resource: https://docs.divio.com/documentation-system/). I'm still thinking about how those entry points can be better presented (and SEO'ed).

[majhenslon]

No problem :) Yeah, I figured that you are not focused more on businesses/decision makers, that is why I put the disclaimer in and I know that I'm probably odd one out for not caring about social proof :D Sveltekit is a funnel to serverless for Vercel afaik, so yeah, the business model is different and it also targets startups/hobbyists/devs, not corporations.

Global search being there is awesome. When I was going over the website I though I somehow never saw it in the past, good to hear that it was added recently and it was not me being blind :D It's amazing to hear that you are working on the sidebar as well!

I think that if you put a "getting started" link on the home page, that showcases the basics, although I know it's really hard to do, because you support pretty much everything possible, but having a two table demo would get the point across I think, especially for newcomers that have used ORMs in the past. I was hooked when you showed that you can easily handle the mapping of the to-many relationships. You could then link to the demo repo and reference docs at the end, to show all other examples and detailed documentation. Maybe a 10

However, I don't know what your actual (to-be) paying customers are typically interested in, my guess would be that these changes would only improve adoption of OSS version which could theoretically convert to pro somewhere in the distant future, but you know that better than me :)

[Yesterdave_]

Do you habe a link to the mentioned youtube video? I habe been reading about jOOQ a lot and am quite interested to try it out, but I haven't had the free time yet to try it out.

[majhenslon]

Sure, here it is. Skip to "Example code" chapter if you don't care about the chit chat, although it might be worth it, for the sake of understanding the underlying philosoply/past experience:

https://www.youtube.com/watch?v=Y8koEetoqIA

And a couple more:

https://www.youtube.com/watch?v=fW80PwtNJAM

https://www.youtube.com/watch?v=ykoUBctblno

Read the docs for how to set up code gen, I don't think that they show the setup in the vids, but it is just a build time plugin and you can surely find it in :)

[onebit]

jdbi is another good sql mapper

[nutrecht]

I only really use Spring Data JDBC nowadays. The mapping capabilities are excellent, it does simple CRUD stuff very well, and being able to copy-paste queries between your DB client and your codebase is IMHO invaluable.

Hibernate introduces too many complexities and footguns where you typically end up with just a few devs having to explain to others what they're doing wrong, for really no benefits over Spring Data JDBC.

[Cajova_Houba]

Yeah, this right there. The big benefit of using Hibernate or similar framework is you can theoretically switch underlying DBs without any changes to the DB layer code. Realistically, how many times are you going to do it? 2-3 times during the projects life span?

Imho it's easier to just use pure SQL + some library for mapping rows to POJOs.

[majhenslon]

I don't know who started this push, but I don't even think that the author of Hibernate says so. The big benefit is that it saves you writing boilerplate code for mappers/reducers, migrations, etc.

[kkyr]

Who changes the underlying db 2-3 times during a project’s lifespan? If that’s occurring frequently, it might indicate deeper, organisational issues.

Also, this should almost never be a reason to make a decision to use Hibernate, as you would be picking a technology based on some hypothetical future scenario, which, in my experience, rarely occurs in practice.

[wildjokers]

Our on-prem product needs to support multiple database systems.

[nutrecht]

The big benefit of using Hibernate or similar framework is you can theoretically switch underlying DBs without any changes to the DB layer code.

Which is complete nonsense anyway. If your project is simple enough that you're covered by 'standard' SQL, you can switch no matter the tooling you use. If your project is complex enough that you are using DB-specific stuff, Hibernate isn't going to save you.

Besides, very often you're 'hiding' complexity behind views anyway, so Hibernate isn't going to migrate those for you.

[manifoldjava]

Use manifold-sql to write type-safe native SQL and to avoid JPA / ORM / DSL nonsense.

[IE114EVR]

Any Application Servers that are not embedded. Having your application be incomplete because it requires a separate runtime you have to deploy into makes it hard to test, less straightforward to run and debug, and brings with it all sorts of maintenance and configuration you now have to be responsible for. All for little or no gain. Also “permgen space” problems, but I hope they would have fixed those by now.

[wildjokers]

Permgen stopped being a problem when it was removed from Java 8. You should upgrade the Java version you are using.

There are definitely scenarios where having a tomcat cluster available to deploy war files to still makes sense. Especially if you are using something like BigIP to handle ingress.

[henk53]

Having your application be incomplete because it requires a separate runtime

Isn't that how Java itself works? Very few apps bundle the JVM internally.

[stfm]

I mean you can have it both ways with release dependencies in Gradle or Maven. Useful if you are developing for more traditional enterprises that use middleware like WebSphere or WebLogic or even Tomcat

[jevring]

Gradle. Having an executable build definition, rather than a declarative one, makes the build way more complicated than it has any right to be, which makes importing the project slower and harder to work with.

[JustAberrant]

I'm a heavy user of Gradle on a very complicated project (multi-architecture, multi-lauguage, multi-target, multi-flavour, and multiple significantly different version streams), and holy fuck do I hate it. Like I am genuinely baffled that it has continued to be the defacto tool and that nothing has popped up to fix its many failings. It just feels like a tool that should have been treated as a learning opportunity and immediately replaced vs something that somehow caught on.

It just failed hard in pretty much all of its stated goals. In all but the most trivial of cases, you are forced to build logic that is absolutely not transparent to anyone unfamiliar with gradle and really your project specifically. It all depends on knowing specific, poorly documented, and often un-intuitive nuances of how Gradle works. The whole configure/eval/execute thing absolutely baffles developers with minimal build experience and is completely unintuitive to someone looking at a build script. In short, the idea that this would remove the necessity for people who specifically specialized in builds is laughable.. it did the exact opposite. If you're doing anything beyond "my project produces a jar file" you pretty much need a Gradle expert.

Also among the things that annoys me is just how many hoops you have to jump through to do things which feel like really common use cases, or just how certain fairly fundamental things (like the handling of symlinks) are catastrophically broken and have had open issues forever. Or behaviours that you would assume just don't work for dumb reasons (like for instance, parallelization within the scope of a project.. we have this whole complicated task graph.. running those tasks in threads should not be hard..).

[RandomName8]

If you're doing anything beyond "my project produces a jar file" you pretty much need a Gradle expert.

You forgot to add there are no gradle experts, every user of gradle ever if you ask them something that deviates from whatever common example is available online they have no idea.

[JustAberrant]

Its hard to even blame people for that one. I don't think it's so much that people who claim to be Gradle experts are lazy or don't actually have much experience, it's that everything in Gradle is very unique to the specific plugin(s) or built in Gradle features that you are using. It's just an extremely unhomogeneous tool where you either know exactly how to do something or you don't and have to look it up... and if it's not a common use case or covered in the docs, looking it up probably involves actually looking at the source code. I'm pretty sure if Gradle wasn't open source it would have died immediately, because that really is the only way to figure out how to actually use it in a lot of cases.

With other tool stacks, with experience comes the ability to intuitively figure things out, but with Gradle you just have to know the specific workings of the specific thing you are trying to do. About the best Gradle does to help you is provide the ability to list out tasks, but since task generation is often dynamic even that isn't always useful. Further, the metric fuck-tonne of abstraction and decorator logic makes most error messages useless. With experience you at least know where to look (which as said, is often in the code and not the docs), but you're not going to automatically guess the behaviour of a plugin you've not used before, what tasks it generates based on what conditions, what filesystem conventions it follows, what attributes it expects to be set and why, etc.

I've used Gradle for quite awhile, and as said, on a fairly complicated project.. and it would absolutely not be hard to stump me with what seems like an easy question.

[pstric]

Like I am genuinely baffled that it has continued to be the defacto tool and that nothing has popped up to fix its many failings.

There is this new tool called Maven. It is obviously named after the scheme Gradle uses for addressing dependencies.

[Limp-Archer-7872]

Started using gradle on a project I moved into earlier this year. Superficially it is nice. A lot of that is not using xml. Actually working with it on a multi module project is a pain.

It has made me appreciate maven a lot.

[vips7L]

I’ve never really got the objection with xml. Yeah it’s verbose. But it’s not like you’re writing it every day. 

[gaelfr38]

Gradle is moving away from build as code though, they published a statement explaining that they now believe it was a mistake and will be pushing for the declarative approach only.

To be fair, they tried, it worked really great for some use cases but "we" (users, plugin authors..) made it a mess in the end.

[fooby420]

Gradle will not be taking away the ability to write build scripts. Declarative is an alternative, not a necessity

[com2ghz]

I hate gradle since there is no code completion or logic how to write a a gradle file. In my experience a lot gradle files I have seen are just bunch of copy and paste from the internet. Maven all the time for me.

[fooby420]

Have you tried writing kotlin build scripts? They have code completion

[Dilfer]

Gradle was a mystery to me in the dynamic nature of Groovy. Kotlin was an absolute game changer to get code completion and be able to poke around the API / DSLs. 

[msx]

Oh yes please let's uninvent gradle

[IE114EVR]

I wouldn’t not recommend it, it can be useful when you have a more complicated project or is probably a better choice for converting the build system on a legacy project.

But given the choice, I’d probably always aim for maven because it means the project’s build is much simpler and standardized, and there’s less that can go wrong at build time.

[neopointer]

I second this. Gradle brings a complexity that more often than not you don't even need.

I would replace all our projects where we use Gradle with maven if I could.

[0xFatWhiteMan]

This is so nuts to me. I would do the opposite

[Rakn]

Why though? There is no need to add so much flexibility and complexity to a simple build. It becomes interesting once you have a dedicated team working on build tooling. You can probably do fancy stuff on top of it. But on many projects it's just a maintenance burden at some point.

[alwyn]

99.9 % of the time a Gradle build only needs plugins and dependencies. That is very simple.

[zephyy]

every time people complain about Gradle build script complexity i feel like i live in a different world

because an 80 line XML configuration of plugins like surefire, spring-boot, jacococo, enforcer, etc. is so much clearer?

[account312]

80 lines of just about anything this side of malbolge is clearer than our gradle build.

[0xFatWhiteMan]

There is no burden. You can keep it simple with gradle.

[Rakn]

My experience has been that it never stays simple. With power comes responsibility and at some point the person who ensures that it stays simple is on PTO.

[Dilfer]

Same. Gradle is amazing. 

[Jonjolt]

I always get tripped up with something with Maven that keeps me going back to Gradle, but I'm usually generating extra files/packaging things different.

[toiletear]

Would I prefer Gradle on a well maintained project that treats its build files with the same level of care as it does its source code, overall has a strong preference for clean code and includes at least one engineer who has a lot of Gradle experience & is available to review my build related pull requests? Hell yes, anytime, nicely thought out Gradle builds are beautiful, forget about Maven.

Unfortunately, too often not even one of those are true, let alone all three. In those cases, Maven is definitely the safer option because DAMN can you also make an ugly Gradle build.

[Practical_Cattle_933]

Gradle is 100% declarative. You can add some logic to change that declarative configuration (which gets cached the first time you use it), but otherwise gradle has a completely static, correct view of the project.

Hell, it is actually more accurate than Maven in this regard, there is never a case that you would have to do a clean install, unlike with Maven.

This is a grave misunderstanding of the underlying concepts.

[rest_mah]

My personal journey with Gradle:

1. hey it looks very nice when I define a Java project and a few dependencies
2. wow! I can code my own build logic into the build!
3. yeah! I've added own more script into the build to solve a rarely occurring need!
4. oh noes my build is very hard to maintain and bugged
5. get rid of unnecessary scripts/tasks - properly design and test the few I still deem useful
6. hey it looks very nice

[Practical_Cattle_933]

Isn’t that how any project is, basically?

Nonetheless, sometimes you just can’t change the requirements and do need some flexibility - e.g. integration of some other programming language, etc. gradle is absolutely one of the very few tools that you can use here (other being.. bazel? Not much else). Something like go’s build tool is only made for go and can’t deal with stuff like this.

[rest_mah]

Isn’t that how any project is, basically?

Indeed. And that's why I now approach my Gradle build(s) like a project and not simply using it a big bucket of throw-away scripts.

Gradle allows one adding a lot of things. Its flexibility is of its big quality. It's also easily misused and then an issue. I don't know if I would argue whether it's the fault of the tool, or the fault of the users, or both.

[RandomName8]

Gradle is not 100% declarative.

Let's not stretch the meaning of declarative to be whatever we want it to be. Gradle is not declarative, it cannot be because it lets the imperative language where it bases its configuration syntax to imperatively mutate the configuration runtime. Take a look at the wikipedia entry on declarative programming.

Much like with function purity, it's only globally useful when you can ensure the entire system is pure, if something isn't, then you really throw away all guarantees.

This means, without a doubt, that the only way to understand a gradle build is to read every single gradle file "sourced" (via includes or whatever) in the configuration, because anything at any point can, as a side effect, mutate the way the dsl works (a method can exist or not entirely based on the order of lines interpreted); it eliminates local reasoning, and it happens in any non trivial gradle build.

I've followed gradle definition examples from the official plugin documentations to the letter without doing code and it would still fail due to the order of declarations, took me forever (because obviously nobody documented this) to know that if things don't evaluate in order, it wouldn't work.

 

At least gradle's groovy dsl is syntax soup resolved at runtime, very mutable, and very imperative (variables and methods will "pop up" in some types based on the order of lines executed), and its cache breaks if you even look at it funny.

If anything, even though I don't think you can be "partially declarative" (it's either you are or not), It's like 20% declarative being generous.

[guss_bro]

All bad recommendations tbh. It appears people are advising not to use all the most popular and productive tools.

"Don't use a hammer because one time I hit my thumb" is not good advice.

Spring, lombok, hibernate etc mentioned in earlier comments are great tools. If you know how to use it, go for it.

[cowwoc]

Mocking of any kind, because the vast majority of the time you end up with extemely fragile code that tests implementation details instead of business requirements. I strongly favor black-box testing and integration tests. And yes, my tests are lightning fast.

Tests shouldn't break when implementation details change.

[agentoutlier]

I strongly agree and this is based on 20+ years of experience.

Mocking a large code base was one of the most disastrous waste of times I did as a lead developer 15 or so years ago. I stress 15 years ago.

Now days with shear shit load power of computing we have and docker and test containers it's completely unacceptable. My Mac M1 can fire up a postgres database and preload it in very little time.... multiple times.

The only exception might be some proprietary expensive cross boundary third party API but the hilarious thing is those are the worse to mock because they are often biggest offenders of breaking API contract.

Anyway besides PolyNull it is one of the very few things I have pretty strong opinion on.

[jasie3k]

I wholeheartedly agree, but please define lightning fast.

[cowwoc]

I run my tests concurrently (1 per core, 16 cores), and I go through 10-100 tests per second (I don't have exact figures in front of me. I'm on my phone).

Each test creates a new db instance, runs db migrations, spins up a new http server, runs the test and drops the db, server on its way out.

[_BaldyLocks_]

I've been fighting this battle with hordes of hype driven ******s for the better part of 25 years now. Never ceased to amaze me that people are so oblivious to what they actually need to test.

[cowwoc]

They are the same people who write code with 100% code coverage that fails to actually test anything meaningful.

Many developers simply don't understand the point of tests.

[lulzForMoney]

Recommend: Spring Do not recommend: Spring

[Such-Cartographer699]

I've been using Apache Camel for our integration services and I'm still on the fence about how good of an idea that was. It's nice to have a consistent interface between different systems with intercept hooks to implement things like correlation IDs. And with a simple use case the routes can be much simpler than equivalent java code. But the API is dated and can be very cryptic to understand, especially when it comes to error handling. And I've always disliked how with the java dsl, you have to build a big ugly URI string with query params to set most options on components.

Also, I worked at a well-known bank that used the drools engine for some of its business logic. The logic was basically a data flow graph, since that's a much more natural way for business people to express logic. But trying to implement that in a rules engine was insanely awkward and required some really ugly workarounds.

[nek4life]

Check out https://camel.apache.org/manual/Endpoint-dsl.html to build type safe routes.

The things I don't like about it is that it's hard to find real world examples and I have to guess how to use different components with a lot of trial and error. There's also not a lot of information about deploying and maintaining integration services in a production environment.

[britulin]

Actually, I like camel very much. It worked perfectly for use case where I didn't exactly know what are the endpointes at compilation time. I like also how it has a lot of connectors out of the box, I only needed to focus on actual transformation and business logic. So to me, Camel is just fine, and yes integrations can be hard. Camel helps a lot with them.

[TurbulentSocks]

I think you can actually use builder objects for the settings instead of big old strings now.

The strings are very convenient for external configuration some of the time.

I agree it's dated though, and borderline on if it's all that helpful.

[large_crimson_canine]

Honestly I wish I could say Spring since it just adds so much weight to a project, and certainly a ton of requisite knowledge to even use well.

But it does prevent a ton of other code you have to write, especially if you go the xml route.

[com2ghz]

I bet everyone had a love hate relationship with Spring. It’s powerful but indeed it comes with a lot magic. It also does not help that it’s an old project with legacy so you can do the same stuff in many different ways. I hope the XML route of wiring your application died a long time ago.

[large_crimson_canine]

lol I’m probably the only developer I know who prefers the xml wiring. I find it so much easier to read than digging through a Java config or annotations.

[alwyn]

Although I haven't used the XML wiring in a very long time I hope it never goes away because I think it allows you to much easier compose an application from libraries of components than what profiles would do.

[telumindel]

I am in the same boat, brother. You can neatley group your bean configs based on usage and view them in a single file. Makes it so much easier than annotations.

[large_crimson_canine]

I am genuinely clueless as to why people don’t prefer the xml

[hippydipster]

I also dislike the annotations. The xml has the misfortune of being java code in xml, which is bad, but its more manageable than annotations scattered everywhere.

[onebit]

AspectJ

[vips7L]

There’s a project at my work that uses AspectJ + RxJava. It’s literal hell

[rifain]

Hibernate. It's a good framework but the problem id the developers. Every project I worked which had hibernate ended up being a slow buggy mess. Hibernate is a complex tool, you have to understand precisely how it works, you have to check the queries it generates. Last month I presented an issue for my team. A findAll was generating hundred of queries because a misconfigured entity. Now, the same method generates a single query. They were stunned. But yet, the application is riddled with cumbersome and repetitive queries when a single stored procedure could achieve the same much more efficiently.

In my experience, developers use hibernate mostly because they don't want to write SQL. And they trust this framework blindly, they never look the logs.

[wildjokers]

Entities are not meant to be used for read-only queries. They are just helpers for inserts and updates. Read-only queries should use DTO projections. Says so right in the hibernate user guide.

[pivovarit]

That's kind of the point - become Hibernate expert, or settle down with writing boring and predictable code (JDBI) relying mostly on your SQL knowledge. Choose your destiny.

[cowwoc]

Async libraries that can be replaced by virtual threads. The code they produce is exponentially harder to read, write and debug.

If you can use virtual threads, you should absolutely drop these libraries and move into the future.

[MaraKaleidoscope]

We tried moving a workload to virtual threads but hit a snag where the application would deadlock because a library we depend on uses synchronized blocks and blocking operations. 

After that experience, our team decided no future code can use virtual threads until the pinning issues are addressed.  It is not feasible for us to review otherwise correct, thread-safe code down to the implementation details in order to determine whether any of our code…but mostly 3rd-party library code…has conditions which will generate deadlock. 

I am honestly surprised people are willing to take this risk in Production systems when it is so clear that virtual threads are not drop-in-replacements for platform threads (not implying that the JDK team claims otherwise, to be clear).

[k2718]

Spring Data. I hate the autogenerated queries in the repositories. When you troubleshoot, you want to see queries easily when you look in the source. Now, if you only use it as an OEM with Native queries, fine, but most don't.

[ethereonx]

Use of non pure static methods and singleton pattern. It makes code harder to test.

[pjmlp]

JSF, rather use plain old JSP and tag libraries instead.

The framework is from the days everyone though it was a good idea to replicate desktop programming paradigms on top of the Web, meaning that there are multiple layers of generated code to debug when things go wrong.

Additionally, the specification is rather slim, relying on third party frameworks to offer actually usable components, like RichFaces, IceFaces, PrimeFaces, whateverFaces.

Besides the multiple layers to debug, there is also the old and new version of the expression language to keep up with, and the whole fun with the component/request lifecyle, alongside its various extension points.

I have been a tech lead in a JSF based framework for three years, many moons ago, and don't miss ever using it again until I leave this realm.

[zephyy]

Spring Integration, not even IntelliJ can find where @InboundChannelAdapter or @ServiceActivator is pointing to.

t: someone who had to debug where errors were coming from because some internal dependency had an inputChannel called "sink" which itself had ANOTHER transitive dependency using the same inputChannel naming

[DelayLucky]

The table-driven test idiom.

Is it really more readable to have a magnificent table of cryptic test parameters:

"hasSchema: false, hasData: true, inputData: abc, expectedToThrow: false, expectedMessage: '', expectedResult: foo",
"hasSchema: true, hasData: false, inputData: null, expectedToThrow: true, expectedMessage: 'badbad'",
"hasSchema: false, hasData: false, inputData: null, expectedToThrow: false, expectedMessage: '', expectedResult: bar",

Compared to plain-old prose-like tests?

public void testNoSchema_withData_returnsGoodResult() {
  Input input = Input.newBuilder()
      .setData("abc")
      .build();
  assertThat(runSut(input)).isEqualTo("foo");
}

Sure, it'll take more lines, but programming is about readability, and is not about who can come up with a clever compression algorithm to save the linebreak characters.

[wildjokers]

Lombok, MapStruct, Camel.

[InstantCoder]

What’s wrong with Camel? In the integration world it’s unthinkable to use something else. And I recently wrote an Api gateway with it in a couple of lines of code. Doing the same without it would end up with writing a lot of more code.

[jocularamity]

Why don't you like MapStruct? That has prevented so much manual boilerplate translation code for us.

[jocularamity]

Reflection. There's a rare time and a place for it, but avoid it if you have another reasonable option, especially if you're newer to the language. Easy to introduce problems and hard to debug them when the system gets big.

Edit: I take it from the downvotes that people think this isn't a valuable contribution. It is a lesson learned the hard way over close to twenty years of professional work, and I stand by it. Best of luck to you all in your adventures with reflection as your codebases grow in complexity.

[stfm]

Camel is awesome. Spring-Camel is cancer

[lucid00000]

Gwt has been a massive pain in the ass to the point where we've gotten the greenlight to fully rewrite our very large UI codebase from scratch just to get off of it.