In modern Java, is AbstractFactoryFactoryAdapter still a thing?

Less than there used to be.

There are a lot of tools and frameworks that work on simple Java classes, you can write one with a few fields, then write another class that has a method tagged with some annotations like @𝙿𝙾𝚂𝚃, @𝙶𝙴𝚃 and @𝙿𝙰𝚃𝙷.

A web server like Jetty will automatically generate the code to serialize JSON and other objects so you can write API endpoints in a style very much like Sinatra with a minimum of boilerplate code.

Dependency inversion frameworks like Spring and Guava (particularly big these days) manage to break the 𝙵𝚊𝚌𝚝𝚘𝚛𝚢𝙵𝚊𝚌𝚝𝚘𝚛𝚢𝙵𝚊𝚌𝚝𝚘𝚛𝚢𝙵𝚊𝚌𝚝𝚘𝚛𝚢 recursion by creating one super factory that initializes your application based on a map of which part goes where.

People are learning that Java is a great language for DSLs. Sometimes type erasure gets in the way but it is possible to implement very complex APIs with pretty good type checking, see

https://www.jooq.org/

This feature is a huge amount of fun

https://openjdk.org/jeps/433

although it is still in preview. They are making small changes in each revision which is annoying on some level but it means they are tweaking it to work really well, together with

https://openjdk.org/jeps/432

you can do a lot of what you'd do with destructuring assignments in languages like Python and Javascript.

More than the language, it's the culture of the organization that matters. You could be working for a company that uses a 'modern' language like Typescript, but then restricts you to using UI components built by a central team who can't possibly have an insight into every use case that downstream teams deal with. So you're stuck working around the limitations of those components.

Or you work for who can't use a particular library which makes your life a lot easier because a competitor had developed it. Either you find time to reinvent the wheel, or you just put together something that works for now, but will be a pain later to modify or extend.

In cases like that, you can end up with code even uglier than N-Tier (where N > 4) Enterprise Java projects from the 2000s.

So if you see a company with bloated culture, which incidentally uses Java, then you will find over engineered Java code. But if it's a company that cares more about solving problems than having a lot of meetings on what standards to follow, their Java code will be unlike anything from the 2000s.

It's still overengineered in comparison to Typescript or similar more loose languages. The reasoning is a lot of the now senior developers and principals never moved on (I did - I use Typescript now) to use new techniques, sticking to Java 8 syntax. As a consequence bad design (by modern standards) is still prolific because the scene now has a large number of neck beards vs a younger and more receptive to change audience.

I don’t think that is specifically a Java thing, you can find over-engineered code in any place and time. Maybe Java bringing OOP and a large standard library inspired more than its share of this.

Having said that, I just did a sting at a Java company with a 20 year old codebase and deleted over 100 useless classes like this in the first 6 months. My favorite was a class that was called “AbstractAbstraction”, I kid you not. It was at the end of a particularly ridiculous string of gratuitously added classes.

I don’t think some people realize that when you are at the top of the stack, writing apps, not frameworks, it’s a mistake to spend too much time engineering too much flexibility into the design.

It will always be a thing.

The key factor is always people, not syntax or nuts and bolts of your tech stack.

And people tend to stick to what they’re familiar with.

Like they tend to stick to their social network -

just as facebook is slowly getting older and will eventually die,

java with its original overengineering and solve-all-problems mentality will be a thing until the majority of supporters retire.

There is really no technical reason anymore to use Java for anything. It was the OG cross platform language, so its understandable that it gained wide adoption over alternatives, but it is horribly designed, and there are better alternatives these days.