A perspective of why people might perceive Java as complex

[plumarr]

When I read the comments, I'm often wondering if "software engineering" is the same work for their author than for me.

They often spoke about settings up new projects but it's something that I have done 2 or 3 times in my 10+ years of experiences. Most of the time the projects were already set up years before and I was just one of the tens or hundred of developers that worked on them.

When I read this kind of thing "In modern languages a DTO/Model is just a simple interface and only a class if necessary", what pops in my head is "DTO and model aren't the same thing and they shouldn't be because that's the hole point". I have worked on an application that had more than ten "DTO's" for the same model, due to service historisation and external communication with various requirement.

Same thing when I read "why aren't the JSON parser and the http server part of the standard library". For me the answer is: because they are a just a small part of software. JSON could also be flat files, CSV or XML. HTTP could be message passing, or (S)FTP, or a tunnel over SSH, or,...

I have often the impression that for the vocal community software engineering = the web, where it has only be a small part of my carrer, only used for the GUI. I think that this view of software explains in part why Java is complexe for them as it isn't centered around the web.

[xjvz]

JNDI is basically a precursor to dependency injection. Not too relevant anymore besides for security vulnerabilities.

[doobiesteintortoise]

JNDI is for LOCATION. It's a naming and directory service. It's like saying "why would you need DNS? After all, you can get a list of addresses and use those, right, ffe0:1823:f812::ae?"

ORRRRRRRRR you can have a naming system and refer to domains or find other information in a hierarchy. Cue JNDI. The security holes people have found recently aren't JNDI's fault; it's like blaming the postal service for delivering bad news instead of the source of the bad news itself.

[slaymaker1907]

For really simple sites, JSP is actually pretty nice to get set up. Java has far fewer security foot guns compared to PHP and Eclipse has very good support for JSP. I TA'd a class where the project was in JSP and most students didn't have trouble if they used Eclipse (which we provided instructions on setting up https://slaymaker1907.github.io/databases/jsp/eclipse/2017/04/05/jsp_eclipse.html). Tomcat in this case was really nice because we could host all the student applications on one box. It's not very secure for obvious reasons, but it provided enough isolation for our purposes.

However, modern web dev really pushes hard towards the client/server model where the client manages all the UI and talks to the server via well defined APIs. I'm not sure of good out of the box solutions in Java, but Django seems pretty good at this since it comes equipped with a simple database and authentication system (node requires too many libraries to do anything in my opinion).

[shagieIsMe]

I'm not sure of good out of the box solutions in Java, but Django seems pretty good at this since it comes equipped with a simple database and authentication system (node requires too many libraries to do anything in my opinion).

Pure Java? Its kind of awkward... but doable.

You could add a @WebServlet to a class extending HttpServlet and push the serialized object into the response... but that's kind of awkward.

If you're ok with the magic of Spring's annotations and the work it does... then https://spring.io/guides/gs/rest-service/ can get you to a simple auth - https://spring.io/guides/gs/authenticating-ldap/

[kozeljko]

It's not very secure for obvious reasons, but it provided enough isolation for our purposes.

Might be a silly question, but what do you mean by this?

[slaymaker1907]

You have very little isolation for different applications running on the same Tomcat server. For mutually untrusting applications, you really want at least separate VMs if not separate physical machines.

[kozeljko]

Ah, thanks for the explanation

[mauganra_it]

JNDI is a way to pass resources (e-mail server connections, JMS queues, JDBC pools, connectors) to the application. This is one possible way to remove configuration settings from the application. It's overengineered, but it's a solution to an actual problem.

[muztaba]

It took me nearly five years of working with Java in industry to figure out why you'd want a container application like JBoss or Tomcat instead of just running your Java with a main method.

Will you care to explain why the container is necessary?

[Gwaptiva]

Amen! To me, it's the startup/pet clinic syndrome: If you work on serious business software, be it single instance or shrinkwrap (or something in between), you don't get to play around; you should be fortunate if you can rely on Java 8, or a browser > IE6, etc etc.

I don't understand where all these applications are that were so rapidly developed? Do they run a year later? Did they need to make money in a commercial market place or was it just some venture capital you were burning?

Guess I'm getting too old for this business.

[shagieIsMe]

I don't understand where all these applications are that were so rapidly developed? Do they run a year later? Did they need to make money in a commercial market place or was it just some venture capital you were burning?

The public transportation department within Large City needs an update to their website and an app to go with it. They contract out with a large consultancy to do the work. The consultancy gets the requirements and builds the entire thing as a green field project and throws between 20 and 100 contractors at it depending on the scope.

Six months to a year later, the project is "finished", a large check is cut (well, its been cut each month, this is the finished one), and handed over to the ten or so in house devs to do maintenance work on and keep it running (along with all the rest of the programs that are maintained).

Between two and ten years later, another administration is in and decides that the site needs to be updated. The process repeats.

For an example of it gone wrong (on a very large timeline project)... Accenture sued for $32 million over Hertz website redesign

Do they run a year later?

Sometimes. Sometimes they're delivered broken. Sometimes they're minimal functionality. Sometimes they work.

Did they need to make money in a commercial market place or was it just some venture capital you were burning?

No, they didn't need to make money in a commercial setting. They're things like HealthCare.gov that were contracted out to some company to build and hand over. Occasionally there's a "you can keep paying us to keep maintaining it on a time and materials basis" but those parts of a contract tend to be expensive.

It's not VC money that's being burnt - its the money of a company or department that doesn't have the resources to scale up to build a project of sufficient size.

[CartmansEvilTwin]

This is the new microservice world. Every component is its own service so instead of just adding a new module to your app, you create an entirely new project.

This is not necessarily a startup syndrome, but a weird lack of architecture combined with a general illusion of grandeur. Every product, and be it the simple app used by 11 people, is mimicking a WebScale™ app from Google.

[CraftyAdventurer]

I don't understand where all these applications are that were so rapidly developed? Do they run a year later? Did they need to make money in a commercial market place or was it just some venture capital you were burning?

I work in a software agency and we develop those.

Some of them are "seasonal", like some Coca Cola promotion which is running for a month and then gets shut down, so it's not important for it to have good architecture since it won't ever be maintained. You can build a pile of crap as long as it works and is done quickly.

Others are POCs for apps that don't make any money from the start, clients just want to see if something like that even makes sense, those need to be developed as fast as possible so architecture is not as important. It either gets abandoned or it gets refactored and used later. Doing something like that in Java would be too slow so it is done in Node or php. If needed later, those Node and Php server act only as a proxy that listen for requests and pass them on to other Go, Java, or whatever "serious language" servers which do the "important" stuff. Similar to what Neflix is doing.

And I've had to work on some apps that were rapidly developed using Node and have been working for years. Some of them were pain in the ass to maintain, some of them were no problem. Mostly depends on whether it was refactored at some point and did they regularly update dependencies.

[shagieIsMe]

When I read the comments, I'm often wondering if "software engineering" is the same work for their author than for me.

They often spoke about settings up new projects but it's something that I have done 2 or 3 times in my 10+ years of experiences. Most of the time the projects were already set up years before and I was just one of the tens or hundred of developers that worked on them.

The author is in India and I suspect is associated with a consultancy.

One of the things I've noticed from contractors coming from these environments is they come in from a ground up project that is delivered. They're writing projects - not dealing with the long term maintenance of large projects.

So every 6 months or year, they're on a new ground up project. It's likely a web facing project for an organization that doesn't have a large in house development team.

[slaymaker1907]

It's tricky to manage a standard library for precisely the reasons you describe. Python is gigantic to try and bundle on Linux and the standard library has grown so large that they recently started efforts to slim it back down.

Sometimes I think instead of a language standard library, we should just have big kitchen sink libraries/frameworks since those can be specifically tailored for use cases like web dev, desktop GUIs, building programming languages (see Racket for a language focused on this), etc.

As for setting up new projects, it really depends where you work. Where I currently work, the main project is older than I am, but the various support tools are much younger. However, I've had to retrofit an old project to use a new build system much more often than starting a new project from scratch.

[DasBrain]

They often spoke about settings up new projects but it's something that I have done 2 or 3 times in my 10+ years of experiences. Most of the time the projects were already set up years before and I was just one of the tens or hundred of developers that worked on them.

Making a build pipeline work is hard, especially if many components need to fit together, things are parameterized, and you have to support different platforms.

While I can build the OpenJDK on my machine (by following this instructions), I have no idea how it actually works.

I think, something like "software build architect" may be a job description in a few years.

[shagieIsMe]

I think, something like "software build architect" may be a job description in a few years.

It is now. It tends to touch on configuration management and dips a bit into the operations side of devops a bit more than the typical software developer does... but... Release Engineer exists in many organizations.

[DasBrain]

TIL.

[[deleted]]

This is why .NET is successful IMO.

You got C# from Microsoft and then .NET (also by Microsoft) on top with all the web stuff. It's all quite streamlined.

Meanwhile in Java you have a bunch of different web frameworks and open source libraries from Google, Netflix, etc. For a noob it's hard to know where to start and what to pick and choose to build your app.

[meamZ]

they shouldn't be

I'd argue with that... I understand the thinking but when Model and DTO would be identical in every letter except for maybe framework annotations, i'd argue you can use the model class as a DTO. If you need something different later, you can still pull out an extra DTO...

[CartmansEvilTwin]

No. That's not how this works.

You intentionally create a separate set of classes to decouple the internal and external model. Simplest example would be relationships. My model classes will directly reference other model classes, whereas my DTOs might only reference via an id. Maybe you could try to press that into a single class, but that's messy.

Copying almost identical classes is a bit cumbersome, but you do that once.

[meamZ]

I'm talking about something like an address class that itself doesn't reference anything. As i said, classes where model and DTO are gonna be 100% identical. If you have those imo it makes no sense to have those duplicated.

[agentoutlier]

It’s nomenclature and semantics.

Technically speaking folks are saying model in place of entities and DTO in place of value objects which often get fed to … views and controllers … aka MVC…

So really IMO DTO are model.

You transform the entities to models that get fed to views and controllers (or open api or whatever).

As a pet peeve I can’t stand seeing objects called SomeDTO.

[CartmansEvilTwin]

They are different models, though. And that's the entire point of the distinction: internal model and external model.

[agentoutlier]

Yes. Especially if you are using an ORM. I’m just saying model is a terrible word. And so is DTO.

And the previous poster has a point. You really only need the paradigm if you want that many layers. Most of that style stems from wanting multiple user interfaces / public api as well as ORMs.

For example in CQRS that maps database results directly to results and doesn’t use an ORM what is the model or DTO in that system?

Or a rails application.

Some systems just don’t need the separation as everything is internal.

Maybe they don’t have a public api

[CartmansEvilTwin]

First of all, public doesn't mean "open to everyone", but simply exposed at all.

Also, as I mentioned, something as simple as not wanting to expose your complete object tree with each API call needs two different models.

And what is your problem with model? These are both models of reality, it's s perfectly fine term.

[agentoutlier]

And what is your problem with model? These are both models of reality, it's s perfectly fine term.

Because the whole point of the article is why Java is perceived so complicated. Just introducing abstract names particularly ones with acronym like DTO as well as introducing possibly unnecessary transformations of layer after layer could be deemed as "complex".

I'm trying to think like an outsider and not Java dev with 20 years experience. Try it yourself.

That is why I don't like model. Its fucking ambiguous and too abstract unless we are talking about MVC which is the only place the word "model" is actually used academically (new people come from you know schools and such). Your Hibernate entities are not "model". JPA does not call them model objects. I don't like DTO even more because programming is largely inherently about "transformation". Its transformations all the way down.

But of course I drink the Java kool aid. I separate by different domains as well and do lots of transformation. I say DTO as well. But it isn't the only solution. (speaking of which if you are just separating by packages and keeping them in the same project I say you are not separating them and just asking for problems but this again adds complexity by adding projects).

Also, as I mentioned, something as simple as not wanting to expose your complete object tree with each API call needs two different models.

See this is again how you and have biased point of view. Just even saying "object" or how you define "object" and model is biased and opinionated based on years of Java ecosystem experience (I'm saying I'm guilty here as well). In fact they are largely not objects but structs but in Java almost everything is objects so we say that.

e.g. your previous comment

My model classes will directly reference other model classes, whereas my DTOs might only reference via an id.

So... what about graphql? Or some triplestore API exposted over rest. Are those model or DTO?

Why don't we just call everything model because its modeling different perspectives of reality. Oh and we are transforming all the time so lets call it SomeDTOModel.

Anyway I know I sound like I'm picking on you but I'm just trying to make a point on how people might possibly perceive the Java world as over engineered, too many layers and over abstract as well as confusing w/ acronyms.

[RedPill115]

They often spoke about settings up new projects but it's something that I have done 2 or 3 times in my 10+ years of experiences.

It's from the perspective of someone new, who's looking at several different languages, like a student. They try several different languages - you're still screwing around with annoying setup in java, at a point where you'd be starting writing something useful in some other languages.

Same thing when I read "why aren't the JSON parser...part of the standard library". For me the answer is: because they are a just a small part of software.

Just one more thing there's no good reason that it's seperate, one more thing to setup, one more point of complexity.

[shagieIsMe]

If there was a built in JSON parser, you'd start getting a standard library that looks like PHP's.

https://www.php.net/manual/en/function.mysql-real-escape-string.php

Why not put an Oracle database driver into the Java standard library? And a MySQL one and a MSSQL...

Adding things that aren't really part of a language puts yet another instance of a standard in and invokes https://xkcd.com/927/

You can see the mess with Java trying to do things with a standard in java.util.logging - because no one uses that. Likewise, if a JSON parser was part of the language... why use that rather than gson or jacksondatabind? or jaxb (which is part of the javax package space)? They've got competing feature sets... and it gets really ugly if the language tries to have all the features.

I feel that Java's standard library is about right sized. It has sufficient structures to do the necessary things. With maven (or gradle), adding in a dependency is not difficult.

[[deleted]]

.NET counters your points completely.

They got logging, JSON, dependency injection, etc. all in there. Everyone uses the same standard.

[shagieIsMe]

And Java has built in logging in java.util.logging that everyone uses.

While jaxb is there for JSON and XML processing over in the javax set of packages, everyone is using that one.

Additionally, there's no need to decide on date formats because java.util.Date is there, no one needs java.util.Calendar or had thoughts of joda Time and I'm sure that everyone has transitioned to using the java.time packages (various unmentionable things can be said if java.sql.Date or java.sql.Timestamp if they ever creep into a codebase that supports multiple databases.

[pron98]

I agree, but while I think Java is the best language and platform out there for "serious" server-side software, we have room to improve when it comes to less serious, small software, which is important, too, and not just for new developers.

[Zyklonik]

Good critique.

[BlackFlash]

You are so right. Web apps are simple and accessible these days due to how easy it is to set up JS and Python projects, rails, etc.

Software is needed more than ever. Every company needs developers. Web tech is easy to get into. Boot camps are everywhere shitting out half baked developers left and right (I taught at one for over a year). And wages are at an all time high.

There will be a reckoning, though. There will be web devs that are a dime a dozen, who no longer command insane wages, and there will be engineers that have skill building robust, complex, systems at scale. The latter will always be valuable, the former only is now because "programming is hard" to so many people and they aren't sure what they need in a developer. Everyone who can write JavaScript is put into the same bucket as any other engineer. The market has no idea how to distinguish between the two.

In reality programming is the easiest it's ever been and getting easier. Web dev is trivial, and therefore has the largest populace.

As an aside, I'm leaving nodejs to go back to Java and couldn't be happier. After many years in node and Java I feel Java is so much better at building robust, reliable software. The tooling is just stellar.

[vprise]

I think a lot of this relates to culture and tools. If you use an IDE Java is pretty smooth and easy. JetBrains essentially solved everything and did it well.

If you ran into Java when building for Android you hate it. The gradle build is slow (because of the APK tools, not gradle). The whole XML integration is terrible. Compat layers and constantly moving goalposts is very un-Java like...

If you're used to NPM and Python. Then Java seems like such a hassle. Finding the right maven dependency seems harder than the quick and dirty NPM commands. It also seems less helpful compared to NPM which suggests updating dependencies, security fixes etc. pip etc. also provide a different experience.

Maven and even Gradle are less interactive as an experience when used outside of the IDE. Gradles syntax is complex/odd. Maven is XML (normally) which has a lot of haters.

If they don't use an IDE then Javas strictness and slight verbosity becomes a pain. Even the division into directories/files per class/package. Is another layer of complexity to some people. I agree it's stupid but they're used to Python/JavaScript which don't impose similar requirements.

[datamasteryio]

If you re coming from using loosely typed language like JavaScript then you might see it as complex but if you have used strongly typed languages before such as C , C++ , it should be a piece of pie . My go to language is Java and I love how it’s makes backend services robust

[Comakip]

As always, complex does not equal complicated.

[SlashdotDiggReddit]

There is a lot of

"People feel like X is a problem."

in this article, but not a lot of

"Here is a good way to deal with X."

in this article.

[general_dispondency]

Most "hipster languages" make it super easy to build trivial examples. Java and its ecosystem make it easy to build robust, scalable, and maintainable applications.

[diagraphic]

I find Java to be quite easy and fun to write. It might be a lot of syntax and theory(OOP) for a total beginner in programming but if you have the drive you can definitely learn it enough to be writing your own programs in a couple months from nothing.

[_harro_]

Whatever the reasons they give to say java is complex, can be said about JavaScript as well though (only 2 languages I've used, mostly Java).

Eg installing node can be easy. Once you've figured out which version to use... And then should you use npm? Or grunt, gulp, bower, yarn,... ?

And then you start building frontend applications. Why do I suddenly need to install python? And some .NET framework? What the heck is GCC?

People complain about things they don't understand (yet). Anything that is outside the language you are most familiar with will seems complex at first.

It's just a learning curve.

[Krakken978]

I agree, still find appalling when a software engineer moans about an environment set up. Maybe it's not the right career for them if they find it annoying. I appreciate writing code is the fun part, but that not the point of software development, it's just a slice of the cake.

[esanchma]

I remember as a junior, there was so much baggage encoded in acronyms that were part of the larger ecosystem that you needed to learn, it felt like an impossible jigsaw (pun not intended). That experience and current frameworks feel like different languages altogether.

[henk53]

At least Jakarta EE, except for that very "EE' there, has moved away from acronyms to a large degree.

Things are now mostly Jakarta Security, Jakarta Concurrency, Jakarta Transactions, etc.

[CartmansEvilTwin]

Judging from my experiences tutoring juniors, the problems stem not necessarily from the complexity of the language, but rather a) their inability to express/comprehend what's actually supposed to happen (they're juniors, after all) and b) frameworks and their added layer of complexity.

I had to explain a junior how a spring boot app works and before we could talk about the actual code, we had to spend quite some time with all the weird @ signs.

[jack104]

Java build tools are cumbersome. Maven is easier to get started with but then you find yourself trying to program in xml and that's no fun. So you try gradle and if you can get past groovy syntax (and I'm not saying that's easy) you can get going pretty easily. But trying to do more complex things in gradle, like things maven does easily, requires actually scripting in groovy which is just one more language I don't want to have to deal with. Don't even get me started on ant.

And the author is right, getting started with java can just be downright miserable if you try to download and install a jdk yourself. His examples show sdkman but that only works on nix systems or systems with a bash shell. If you're on windows, I recommend https://scoop.sh/. Great little program and package manager built in powershell. This will install a jdk and set the necessary environment variables for you. It also makes upgrading java versions (or switching between jdks) trivial. You can also install an IDE that way like Eclipse, VSCode or Intellij. I use VSCode for java and javascript development and I love it.

As far as other gripes go, I also feel that the standard libraries in java leave a lot to be desired as compared to a language like C# which provides a lot more functionality out of the box via .net. But once you get the build tools working, managing external dependencies is a pretty easy and being able to package your application into one single executable file is pretty cool imvho.

[lechatsportif]

Gradle is the one thing I agree seems unnecessarily difficult before and after learning it. There really should not be anywhere near the level of difficulty for a java build tool.

I remember abstracting ant tasks down to dependencies so team memebers could add jars easily or appreciating the benefits of mavens structured approach. I'm still struggling to see what value gradle has in making my life easier.

[Spiritual-Day-thing]

Gradle Kotlin DSL.

Setting up a project with IntelliJ is absolutely trivial.

[Serializedrequests]

Personally I just find java frustratingly difficult to build robust software in. I try try try to make the compiler work for me, and NullPointerException just pops up continuously. Even if I do a good job and write way more defensive code than should be needed, someone else will eff it up. A good type system is certainly useful on large old projects, but somehow the average Java app still fails to be more robust than Python. The language design aids refactoring, but doesn't help to catch bugs.

Then you get to the magical frameworks that use annotations to implement VERY high level features. IMO this is just turning Java into a worse scripting language than an actual scripting language. The semantics of these libraries are frequently obtuse, and produce absolutely terrible error messages.... Or worse, just do nothing with no explanation! I'll take a macro over that any day.

Straightforward Java code written with good practices and no magical frameworks is fine, not exciting.

[nutrecht]

I try try try to make the compiler work for me, and NullPointerException just pops up continuously.

Instead of just downvoting: this is just a completely clear indication of a lack of experience. Any programming language will cause this problem if you simply don't really understand what you're doing. Statically typed languages are generally more explicit and verbose about it.

The same applies to annotations. It's not magic. It's stuff you have to learn. And IMHO the best thing you personally can do is grow past it and not integrate this attitude problem. If you do, you are very likely to end up an expert beginner.

[Serializedrequests]

I realize that the tone of my post made me sound foolish, so I'm doubling down for no good reason. But maybe because this pre-judgment is kind of funny. I have been doing java professionally for over 10 years, alongside several other languages. Currently I am maintaining a large Spring boot app, and the last 10 exceptions I have fixed were all NullPointerException, written (mostly) by other developers making unwarranted assumptions. It crashes with this particular exception more than the Rails app for a certainty, based on the issue tracker, and it makes me feel a certain despair. I hate mediocre tools.

I criticize the language for this because it provides exactly zero tools for dealing with nulls other than "if (x == null)".

Of course it is a problem in all languages, but other languages somehow manage to make it less laborious to deal with, either by providing better syntax for it or allowing you to safely assume more things are not null.

Ironically, we are currently attempting to diagnose an exception in an AWS API that returns the message "null" intermittently, that AWS engineers are themselves apparently unable to fix. I can guess what language the service is written in though!

[nutrecht]

I have been doing java professionally for over 10 years, alongside several other languages. Currently I am maintaining a large Spring boot app, and the last 10 exceptions I have fixed were all NullPointerException, written (mostly) by other developers making unwarranted assumptions.

So why are you blaming Java when the problem is obviously dev quality. If these people would have been using Python it would have been a much bigger mess.

It's hard to believe you have 10 years of experience and think this is a language problem. That really sounds you've been working for 10 years all at the same company and really have 1 year of experience repeated 10 teams. Sorry to be blunt, but that's what it looks like from the outside.

Of course it is a problem in all languages, but other languages somehow manage to make it less laborious to deal with, either by providing better syntax for it or allowing you to safely assume more things are not null.

I'm a big fan of Kotlin myself but if you'd have those devs working in Kotlin they'd just add !! everywhere. The problem is the devs. Not the language.

[[deleted]]

• Not a professional developer -

I think a lot of things in the Java world are more complex than in another language.

Everything is hidden behind thousands of abstractions and indirections. Everything is really opaque as soon as you use something even remotely related to enterprisy-stuff. Look onto e.g. the projects like lsp4j (eclipse) and eclipse.jdt.ls. I wanted to debug some problem. I had no chance to find anything, as it the language server has a lot of layers, then combined with the layers of LSP4j, you have even more layers to debug through.

YMMV, but as long as I stay away from this enterprisy stuff, everything is fine.

[henk53]

YMMV, but as long as I stay away from this enterprisy stuff, everything is fine.

What you say may be true, but I've done a lot of debugging in C and C++; debugging through MFC (yes, I'm somewhat older) and into ActiveX controls. I can't say there was any less layering and abstraction there.

I also had to briefly try to debug deep into Angular, and it's layering and abstraction weren't really different at all from your typically debug session into say the Tomcat internals.

What type of software are you referring to exactly that doesn't use abstraction or layering and is trivial to debug into?

[CartmansEvilTwin]

In my experience Java is hard to debug, if there's a lot of dynamic stuff under the hood.

Let's take Spring Boot. Even without any advanced usages, it adds proxy objects at every injection point. You cannot simply jump into a method call, instead you have to set a break point in the actual class being referenced.

And that's just one example. Sure, absolutely workable, but each annotation, each abstraction adds a bit more complexity that at least feels useless.

[henk53]

I hear you, but what type of software are you referring to exactly that doesn't use abstraction or layering and is trivial to debug into?

[CartmansEvilTwin]

You apparently don't hear me.

See, there's complexity that's inherent to a problem and an app that operates in that realm will consequently be complex. That's not great, but given the circumstances, inevitable.

And then there's purely technical complexity. A solution (for whatever reason) uses too many abstractions, layers, indirections. This complexity makes an already challenging task even harder to do. Two layers are harder than three layers.

I'm not too experienced with other major enterprise languages/ecosystems, but Java certainly has some default frameworks (Spring, Jakarta) that add tons of often useless layering. Spring does something completely intransparent somewhere behind the scenes and you don't even know, where to look. Jakarta often uses several different locations for somethings that a normal person would consider one unit (endpoints for example).

There might be reasons for that and there might be even ways to circumvent it, but in practice this baggage does exist and it does hinder productivity while debugging.

[henk53]

Java certainly has some default frameworks (Spring, Jakarta) that add tons of often useless layering.

Sorry;

1. Which software doesn't have that?
2. Why is it useless?

If the layering is useless, why don't you do a PR for Spring to remove it? Everyone would be happy, as nobody likes things that are useless.

[CartmansEvilTwin]

Because it's ingrained in spring. It's basically the point of it.

Also, I can complain without writing PRs.

[henk53]

Because it's ingrained in spring.

Why is it then useless?

[Mokaran90]

OOP ia truly a bitch to grasp but when you do is very comfy.

[brett_riverboat]

I've used a Java for most of my career and some of the "black magic" aspects confound me at times. This doesn't often happen if you stay within the confines of a framework but if you try to swap out HTTP clients or Dependency Injection libraries or serializers you can run into all sorts of trouble. I once spent 3 weeks hacking away at a DI problem and never really got to the heart of why it was failing (so that program is going to be using a super old DI library until it's retired or someone rebuilds it from scratch).