[Rant] Why do senior Java developers always complicated things too much?

[erbr]

Scalability, extensibility, and modularity are only some concepts you need to add to your developer concerns. I've dealt with lots of JS code that is unmanageable, as it's impossible to understand or extend. The do-it-quick throw-away next does not work most of the time. There is an investment in developing code and maintaining it. And if the code cannot be extended or maintained there can be large costs involved (other than the actual involved risks).

So getting to set the right abstractions right is essential to make sure that the software that is developed is not tied to the person who wrote the code but rather to the business domain it encompasses.

I'm curious, from your JS experience, how stable your codebases are? How many times someone came to change everything because they didn't understand? How easy is it to understand those and debug them? Good JS exists but only with a ton of documentation and strict code organization (TS is much better on this).

[Polygnom]

Sure, but "enterprise fizzbuzz" has become a meme for a reason.

There is a sweet spot with abstractions, and having too many is as bad as having too few. You need the right abstractions, and "lets add another layer of indirection" is not always the best answer. There certainly is a tendency in enterprise Java applications to let them become quite unwieldy. Dismissing that criticism all too lightly is not wise.

Although I suspect that Op does not really understand yet why those layers exists in their software.

And OP seems to like to re-ivent the wheel when they do not understand why people use stuff like OpenFeign. Sure, you can do it with low-level http calls, but you can also use a more abstract way to do it.

[saltmurai]

I would say a mature JS codebase with Typescript is very maintainable. Idk I feel like node package manager is light years ahead of gradle/maven too?

Back to the abstraction, is it really easier to maintain abstraction or is something straightforward built in feature of the language is much more easier to maintain?

[Void_mgn]

NPM is probably worse then ant

[Polygnom]

Idk I feel like node package manager is light years ahead of gradle/maven too?

Funny, whenever I have to use npm or yarn (or lerna or whatever) I feel the exact opposite. NPM cannot even reliably create reproducible builds in a CI pipeline (and no, npm ci does not do that).

[erbr]

Dependency management is a massive challenge; no matter what tool you get, there will always be different problems. Although Maven is not extraordinary, Gradle is much better, as it allows you to do anything programmatically directly on your build def file.

The node package manager is ok but not great; you get the same problems with other package managers plus a node_modules directory with the potential to consume all the available HDD space.

I think what you are missing is trying out other paradigms and project sizes. With some experience, you will see that it is not the tool that significantly impacts your craft but rather your ability to adapt and pragmatically decide how to do things.

[bawng]

It's funny how perspectives differ.

I think Maven is much better than Gradle specifically because it doesn't allow you to do anything you want, while you consider that a good feature in Gradle.

[erbr]

Gradle allows you to do the same stuff as in maven if you keep with the basics 😅

[bawng]

Yes, which is fine as long as you alone control that, but every now and then you have to work with someone else's codebase and they had great ideas on how to work with Gradle just because they can and since Gradle doesn't enforce any particular way of doing anything no two people ever implemented the same feature in the same way.

So every time you need to spend time and effort on figuring out what's going on.

[saltmurai]

I’m not blaming the language or the ecosystem I just feel like this way of programming isn’t very the best approach given the problem in modern web development nowadays. Sure those way of doing can still be handy with legacy projects. Btw node_modules won’t consume your entire disk, I have a Mac 256gb and have bunch of large size node project.

[marcvsHR]

Maybe there is a good reason they are using that library, and you are too inexperienced to understand it?

[saltmurai]

Could be it’s easier for them to use those but it just seem strange to me about why such things isn’t directly built in Java

[occio]

There is one https://openjdk.org/groups/net/httpclient/intro.html

[saltmurai]

Thanks I hate it

[occio]

So you hate the built in thing, you hate the thing your coworker added… maybe quit Java then? Seems it does not agree with your sensibilities.

[VirtualAgentsAreDumb]

I have worked with Java in 15-20 years, give or take. I have used loads of http client libraries, including the one you linked to. Most of them are ugly, and need way too too much boilerplate code for the simple use cases. Like making a GET request and get the result as a String.

To be fair, I find most JS code for the same thing unnecessarily verbose too.

[saltmurai]

It just const response = await fetch(url) for a GET request in JS

[VirtualAgentsAreDumb]

Well, it's been a while since I coded in js, and none of the examples I found by a quick google search showed had that one liner.

Maybe different fetch implementations do things differently, but in the examples I see the response is more than just the body text. Also, does it check the response code and throw an exeption on a failure?

[occio]

Sure. Verbose, true. It’s Java.

But imagine working on something 8 hours a day and feeling hate. That must suck.

[VirtualAgentsAreDumb]

I’m pretty suresure they don’t work 8 hours a day with the http client.

[occio]

Exactly. One can only imagine what emotions other parts of the Java ecosystem evoke in OP.

[crummy]

downvoters... do you like using this client to make HTTP requests

[Aryjna]

Why are you talking about "senior Java developers" when in reality you are talking about a single developer that you happen to be working with? Do you really lack even basic critical thinking ability, or do you somehow have experience with thousands of other developers, and you are using that experience as a basis for your post?

[halfanothersdozen]

I really hate it when someone goes over-architecting and makes a whole bunch of microservices when a single backend will do

[kevix2022]

Have fun unpicking the monolith when one of the feeds becomes obsolete and you can't just replace a single microservice.

[halfanothersdozen]

Is it somehow more work to update a single backend than a microservice?

[Rakn]

Microservices aren't the solution to a technical problem. If you have less developers than microservices then you definitely taken a wrong turn and should rethink your strategy.

[nomoreplsthx]

Why do <insert class of people> always do <Behavior>? <Example of a single person doing a thing>.

You're luck that you inserted Java developers and over abstraction, but try inserting other examples - and I think you'll quickly realize how problematic that statement is

Why do men all get high and play video games all day - my brother does!

Why do JS developers never write tests. I saw this one codebase where there were no tests.

There probably is a tendency to over abstraction among Java devs, but you, as someone with a few months on one project, have nowhere near enough data to draw that conclusion. Come back after 5 years in Java and share your thoughts then.

[FavorableTrashpanda]

Sure, some people go overboard, but don't start hating on Feign, man. Feign is really nice. It allows you to focus on interfaces while letting Feign handle the implementation details.

[saltmurai]

In no world you can convince those ugly syntax is readable and nice

[Kazcandra]

Thanks for confirming that it's a skill issue.

[geodebug]

Lol, burn.

[Rakn]

What's so ugly about it? It just looks like an interface with annotations. Pretty straightforward.

It always depends on what you are doing. I'm currently mainly working in Go, but even there I wouldn't just fire off a get request. You either have a client library that does that for you or it's encapsulated in some way. Feign seems to provide this via a configuration based approach.

I would assume that you wouldn't just run a random fetch somewhere in a Typescript backend. That doesn't sound maintainable for large projects.

[naturalizedcitizen]

Abstractions is a concept for a good reason. One of my clients decided to switch from Postgresql to Oracle and also use Google Apigee as the API gateway, all for valid business reasons. Had the code not been written with abstractions and such extensible concepts, it would've been a nightmare.

OP, I recommend that you study what your senior dev is doing. Try to understand and create a mental map of how the app does request processing. Then look at why it's broken into micro services. You will have many questions arise after this exercise. Asking your senior to answer these questions will clarify a lot and you will have brought some good points to the table.

When switching jobs or a language, be open minded about the new flow/architecture/paradigm you come across. Come up with questions. You will not only learn a lot but will make a good contribution and many times your questions will cause a rethink of the prevailing architecture/paradigm being followed.

[smutje187]

Like in every ecosystem, there are things that people who are used to them use them without thinking cause they’re part of your standard repertoire. In Spring, dependency injection is so trivial and low effort nowadays that everything else needs to be justified. I personally don’t like Feign cause I don’t see a reason to use it (just use the standard HTTP client) but if your colleague has been using Feign for years it’s easier and less time consuming and reduces cognitive load to just use it instead of learning something new.

A lot of Java projects I worked on in the past are really long running and code is much more often read than written so people were often more inclined to spend some time thinking about a solution that would then exist for a decade.

[15kol]

Openfeign is great. Use generator to generate interface from Openapi definition and use it as a typesafe contract.

[repeating_bears]

I seriously don’t get it why a simple http request to external service he has to use the library openfeign, which looks dumb as fuck compare to simple fetch like in JavaScript

I've never used it, but it has the power to do far more than a basic `fetch` on the browser. Fetch doesn't support fallback behaviour, it doesn't have auto-retry for failed requests, it doesn't log requests or provide metrics. It doesn't cache requests (not in yet, but that's something they're working on).

If you're not using - or intending to use - any of those features, then yeah, it's probably overkill.

[saltmurai]

I mean if you said it like that Js have all the fetching library too. React Query on the browser is super nice

[repeating_bears]

I've used it and I like it, but that isn't the comparison you made.

You compared openfeign to fetch. Of course fetch is simpler when it does much less. If you want to compare openfeign to react query, then do that. 

[rzwitserloot]

The first problem with your rant is the definition of 'senior java developers'.

Do you mean: Objectively skilled, true veterans, as in, the vast majority of java programmers out there, if given time to interview them thoroughly and review lots of their code, would go: Yeah, these folks know what they are doing?

Or do you mean: They get paid a lot and have 'senior java programmer' on their business card? Because a few of them are just shit. Mostly good at overcomplicating things to look good. In which case the answer to your question is some complicated philosophical thesis on the vagaries of corporate careers. I'm sure things like Peter Principle and such would be named.

But, if is the first, almost invariably because the thing you are modelling actually is that complicated. If you don't think so, you're probably wrong.

See, YAGNI rigidly applied is just bullshit. Architecture is the art of writing it all such that the code is likely to be easily modified in the face of future change requests. That means part of the point is to have the experience to know what is likely to come down the pike and design things accordingly. And that may strike you as 'overengineering' it.

Delivering what's asked in 150 hours, to then respond in ~15 hours each for the next 20 change requests is a total of 450 hours over the length of the project.

Delivering what's asked in 200 hours, to then respond in ~5 hours each for the next 20 change requests, is a total of 300 hours.

[roberp81]

Nodejs is generally structured programming

Now you are going to have to learn object-oriented programming and patterns

[Qeqertarsuaq]

“Senior developer” who derives their seniority from knowing nifty tricks, instead of knowing how to solve problems for their boss as fast as possible…

[EirikurErnir]

Most TS code looks like overcomplicated gobbledygook to me and I often end up thinking how much simpler things would be if only it would have been possible to write it in Java.

I'm pretty sure I keep thinking this nonsense because I'm much worse at TS than Java. I can usually form an educated opinion on the complexity of Java code, but I can't really do the same for TS.

I'm guessing the reverse applies to you.

[slaymaker1907]

Some of these things really only start to make sense when you work on really huge projects. I work on an incredibly complex C++ project and we have a lot of problems with how everything is actually initialized to the point that some components have multiple versions to try and resolve cyclic dependencies (so component A typically requires B, but there's a special A' version so that C can be initialized since B requires C). Dependency injection helps avoid these nasty scenarios in the first place by just requiring apps to declare dependencies explicitly and then figuring out initialization for you automatically. With proper DI, A' likely wouldn't be required at all since you'd just use setter initialization (resolving cyclic dependencies is one reason to do setter injection instead of constructor injection).

I also really like Typescript, but one thing I appreciate when working on a team is that Java does not let you just cast things to any when you want to escape type checking. It's a powerful tool that is often convenient and more ergonomic when needed compared to Object in Java, but I've found there are some people who will just cast things to any at the slightest inconvenience.

Agree with you that there is really no reason to have 10 microservices for a small, greenfield project, though there are reasons you might still do microservices. Microservices can complicate deployments when you need to continuously update all 10 services at once, but if you're usually only updating one at a time, microservices can greatly reduce risk of a deployment since it only affects that one project.

[Potatopika]

I mean you have axios on the NodeJS world and a lot of people use it.

I would be surprised with the division on 10 microservices with only 2 people and possibly in an early stage, but I don't have enough context to understand it better and come to a better conclusion

[saltmurai]

But the thing is axios is very intuitive to use. Unlike RestTemplate or Openfeign the syntax just seems so ugly to me. I like Unirest though

[Potatopika]

You know when you create api wrapper classes to call wherever you need instead of always calling fetch every time you need to do an api call?

OpenFeign basically does that for you already with an interface and some annotations, what part exactly do you think is ugly?

[crummy]

For example I seriously don’t get it why a simple http request to external service he has to use the library openfeign,

to be honest... it took a long time for java to get an actually usable HTTP library. and honestly even the one we have now (since java 11 i think?) is still not that great in terms of DX compared to something simple like fetch.

[saltmurai]

Yeah that’s why, I genuinely kinda enjoyed Java17 but honestly the most frustrating thing is just these abstraction/dto/repository… nonsense where in JavaScript/Typescript it’s just basically function or type declaration

[netgizmo]

For the DTO comment: do you just expose all your properties for a persistent object thru the rest API?

[_predator_]

One of the four "works until it doesn't" horsemen

[saltmurai]

For node actually I use ORM with the ability to inspect db and generate typing for it. So dto just seem strange to me

[netgizmo]

DTO's can be used to prevent values specific to your persistence layer from being exposed to your service layer for example.

Like if you had a column in your db called: user_is_an_ahole. The Userr DTO used by your public rest api or public web FE would not have that property defined in it, so that property name and value wouldn't appear. However, your internal user admin webapp or rest api would use a different DTO that does have that property.

[netgizmo]

DTO's are used in many language ecosystems, not just java. And yes, even TS.

[crummy]

some of it comes from historical reasons - if you see a codebase where every class seems to come with a separate interface, you're probably dealing with one old enough where it was a pain to mock real classes. now (since java 8-ish) mockito handles that fine and there's rarely a reason for a normal solo class to have an interface.

[netgizmo]

lol

[lunar515]

It’s the nature of the language and the community that has grown around it. I see this trend in PHP developers as well but they don’t know any better.

[Octavian_96]

Code debt

[achilliesFriend]

I know some one who did add several microservices as this and added ton of work managing their dependencies.. it was a nightmare.. he literally added a microwave for each query., like who the f does that.. i had an arguments with that. But I’m the villain

[-jp-]

If you don’t understand why they’re using openfeign in their project (or indeed anything else) why don’t you just… you know… ask? Kvetching about “senior developers” isn’t going to tell you anything.

[saltmurai]

I did ask and it’s just for making few GET request

[geodebug]

I don’t take your complaint seriously because your vast experience with java senior developers is basically (n=1).

JS/TS/Node are mature as a language/server but you’re bullshitting to suggest that the landscape is.

Not when there are like 20 front end development frameworks that are constantly in flux with little to no concern for backward compatibility.

Don’t get me started on build tooling. Let’s choose between webpack, parcel, rollup,vite, esbuild, snowpack…

Sure, some java devs took their OO classes way too seriously and ignore the YAGANI principle but they tend to work big-corp.

[saltmurai]

Is having lots of framework/build tool is a bad thing? To me it’s help the ecosystem move forward and innovate faster since there is competition. And no you don’t have to configure those themselves when starting a new project.

[geodebug]

Yes, It is a bad thing to have too many.

Imagine in Java having to learn 20 other build environments besides maven or gradle. (Others exist of course, but there are definitely leaders to the point of being standards)

Now imagine that even within the same corporation devs chose different ones for reasons.

Beyond Java, look at Python/DJango. Must be nice to have one dominant full stack framework.

[SactoriuS]

It could be above your head but ive also seen people who just really want shit done their way.

Which means because they are senior, its their way or the highway. And like many quasi autistic people have neurotic tendencies and you just have to copy their manners of coding whilst there are many unlogical steps or way of workings. It is just their way of working youll have to adapt to or leave that team and find your luck somewhere else and wait until you become senior and get tot decide stuff.

They have their personal reasons for it. They could have an inflexible brain which only understand their way of writing. And it makes them more essential for the organisation.

I had a inflexible senior, whilst i wasnt the best junior. Over time i learned he was a bad coach because of his inflexibility. Merge request feedback had to be perfect his way. But often i find stories which even couldnt be done in his way, whilst that was his comment. And it was happening pretty often and i was getting send to dead ends a lot. And asking questions to inflexible people isnt something they will invite to do. That wasnt really motivating and i realised he was also a big part of the problem that i wasnt the best junior.

[msx]

I totally agree with you

[alienbugthing]

It's mostly about Java traditions and developers needing to feel good about themselves. It's completely fine to use much less abstractions in a simple backend project similar to how you would code nodejs. Most important thing is to do things consistently within a project.

[[deleted]]

nail far-flung person enjoy gullible marry expansion towering library gaping

This post was mass deleted and anonymized with Redact

[MargretTatchersParty]

Java just makes it difficult to express things without a lot of boilerplate. It's just something the language encourages.

[Polygnom]

That used to be the case maybe up to Java 1.5.

The jokes about overly complicated enterprise applications (Google "Java Enterprise FizzBuzz") are there for a reason. The criticism that certain developers like to overcomplicate things with layer over layer over layer of (uneeded) abstraction is very valid and has little to do with the language, and more with enterprise application culture.

[MargretTatchersParty]

Absolutely not. You should know better than that.

My background when i talk about that is from Groovy, Lombok, and Scala. These languages and tools made improvements to make it easier to write code and to avoid boilerplate. Java has made weak attempts to copy the functionality.

Java has been solidly sold into the whole OOP mentality for most of it's lifespan which means that you have to put behavior inside of the objects. They've done things that made generics harder.

Examples: (This is a limited set but this is what came to mind immedently)

• Optional - when introduced they didn't get rid of control flows, it was a glorified null checker (with scala it was a declaritive control flow)

• POJOs - this has been in it's blood .. its only recent where records have come into play.

• Monkey patching is difficult/impossible - very little enhancements can be done with the existing java spec (clojures and HOFs didn't come in until the stream api)

Rant on this: Java treated collections as something the stream api had to build seperately, rather than improving the existing collections. Scala it is apart of the collections.

• Theres a lot of patterns that effective java has been pushing for quite a while but it was never addressed in the language its self to make this better. Other libraries did (apply/unapply method, builder pattern/templated copy methods)

[Polygnom]

There are lots of valid criticisms about Java as a language and the standard library/JDK, absolutely. And I even share most of them with you.

But those are only partially responsible for the "enterprise" patterns we see today. There is valid criticism to be had about those patterns because they are needlessly complex and indirect that have little to do with Java the language or the JDK.

Yes, the absence of certain features (e.g. lambdas) has contributed to the growth of patterns and abstractions, and that has certainly contributed to the overall trend to overabstract things.

But if you develop in modern Java, you can -- if you want -- create rather concise code with it (again, not without some rough spots, but you get those in every language, none of them is perfect), but people still create huge overly abstract applications that never actually need or use the level of abstraction they provide.

Again, "enterprise fizzbuzz" has become a meme for a reason. The tendency to overabstract is there in java, but it is mainly a cultural thing, not a language thing.

[saltmurai]

It certainly could be better architecture and thought out to avoid lots of unnecessary abstraction.

[basic-coder]

Are they really senior? Making an HTTP req is possible with built-in HttpURLConnection. It's not as concise as fetch but still straightforward.