Ask HN: In modern Java, is AbstractFactoryFactoryAdapter still a thing?
In the late 2000s I was a Java coder and there was a whole culture of obsession with design patterns, overengineering object hierarchies, "Kingdom of Nouns" (http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html)
I hear a lot that the Java landscape has changed a lot in recent years, especially the language itself and the JVM. But is the culture of encouraging overengineering still there or its been relegated to the past?
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 <insert famous tech company> 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.
Syntax-wise, Java 8 is a big improvement in many ways. What post-Java-8 syntax do you have in mind?
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.
In what ways is it horribly designed?
1. Integer/Double vs int/double. That alone should make anyone question the design of the language. There is no good reason for a language to have both.
2. Annotation processing is just silly. Python decorators did it right - the decorator is defined within the language spec. With Java annotation, often times that annotation processing code is actually writing code strings to a file to be compiled. Not to mention the whole Lombok thing, which is considered almost a standard library to use in all projects, but is extremely hacky in the way its implemented. And the reasons for using it are even more silly. Somehow it's bad to make the class fields public, so you should write getters and setters, but also its bad to write all the getters in setters in the first place so you just use the lombok annotation.
3. Having a main function be part of a class, and then resolving which main function gets called if you have multiple ones through an additional file that is packaged into the jar is pretty horrible design.
4. The whole log4j vulnerability issue highlights the fact that there are so many libraries that are used as part of standard codebases, where the developers of those libraries have zero understanding of the ecosystem, to where someone can write code that results in a network call from a log function and nobody sees anything wrong with that.
5. GC tuning is a thing in Java. Shouldn't be. Python seems to function fine without having to touch the GC.
6. While not necessarily a flaw, Java isn't fit for modern day. Compare what it takes to write a API backend in Java versus something like Python or Go. You have to do a lot more configuration and write more code.
The whole language of Kotlin (and before Groovy) was pretty much made to fix a good number of issues with Java, with Android dev switching hard into it.
A peeve of mine is no access to stack values; I like to know where my memory is, and having a ~+50% overallocated heap also doesn't sit well (I know it's tuneable, but I'd prefer to prove my SW doesn't need a resource than guess-and-check).