6. excessive configurabilty leads to fragility at runtime - the overuse of annotations, xml/yaml/whatever configurations and late-binding (effectively assembling the app at runtime) eliminates quite a lot of advantages of a statically typed language and brings us back to string coding: runtime-errors due to typos, jpa strings in annotations, typo in an xml file leads to non-functioning software at runtime. Classloader horrors due to deeply nested library dependencies that use different versions of libraries, fueled by the insanity called maven.

> overuse of annotations, xml/yaml/whatever configurations and late-binding (effectively assembling the app at runtime) eliminates quite a lot of advantages of a statically typed language

Just avoid Spring. That's been my motto and I've been Spring free for 7 years now. Doctors say I should live out a happy life.

I work mostly with Java and am a bit blind to other languages, at least in a professional setting. Which languages / ecosystems do it differently? I'm looking for something new.

I'd recommend Elixir as a nice introduction to functional programming while not being too arcane.

Somehow Java attracted more than its fair share -- way more -- of programmers who wanted to believe that software development had all been figured out, the right answers were known, and the only thing that remained for the profession was to be faithful to the true answers and priggish towards anyone who had doubts. That was a really weird time, especially in retrospect when we think about what the "right" answers were back then.

That’s a side effect of enterprise software development, because politically it’s all about posturing to make non-technical management more comfortable. “Wow they’re really confident they must know what they’re doing”

The same attitude existed in C++ programmers in that space that sneered at Java’s intrusion.

I see the same attitude in new teams using Golang in the enterprise.

Yes, excellent observation. I've seen that attitude a ton in the "design patterns" discussion. e.g.:

"Why are we doing a Factory for Singleton Factory design pattern here?"

"Because this design pattern is made for this scenario"

This. Exactly this. It wasn't that Java was a "different" way of doing things in business software that had pros and cons, it was that its adherents thought it was THE way of doing things in business software.

1) those layers of abstractions are often the result of some smart guy in the team, reading some design patterns book and then desperately applying them whenever feeling the chance. Typical building his little cathedral story.

Its pretty horrible, but by no mean java-specific. It can be achieved in any object-oriented language, and to some extent also in others.

Patterns aren't always bad When used correctly they can greatly simplify code.

OMG! Thank you for this. I've disliked Java for years but really couldn't put into words exactly why. Reading you comment I started thinking about all the time I wasted chasing down error messages that were spread across 7 different classes. And working with TLS in Java? Nightmares abound!

Gradle is only a thing in Android circles, thankfully.

Legacy code is everywhere on the world, only a selected few get to work on shiny things from scratch. Even cool startups eventually turn into legacy.

I wonder what technology used at enterprise level, doesn't suffer from those bullet points.

If I have to work with legacy code I actually prefer code written in a non-object oriented language. Badly written OOP code is often worse.

Yeah, navigating overly-architected OOP is like playing super mario brothers. The princess is always in another castle.

> Gradle is only a thing in Android circles, thankfully.

It's the standard Java build tool at this point. I don't know of anything better.

I don't know about "better" but Maven has been the standard in my company. Personally, I like it better, call me crazy.

For Android developers and ex-Ant users only.

I really don't see it anywhere else to make it standard, besides it depends on Maven Central.

Maven is the standard build tool and has been on every project I've worked on outside of play/sbt hell.

> Gradle is only a thing in Android circles, thankfully.

Wish that were the case, but unfortunately Gradle builds showed up in server-side, SpringBoot-heavy FinTech startup code I worked with not too recently. I guess it's due to the copy/paste nature of Spring development, like other choices in those code bases.

I don't do Spring, so I am spared from that.

That is to be expected, given how Spring is now hyping Kotlin as they did previously with Groovy, Scala and Clojure support, and Kotlin folks tend to push for Gradle due to its use on Android.

"Enterprise" is a hard term for me to use productively in software context, because it feels so synonymous with bad software.

Lots of fine pieces of software are used in small and big companies that do only one thing and do it well.

As for in house line-of-business apps, it's an elusive species because if it does what it needs to cost effectively and is not a marketing case for a fat software company like Oracle nobody often gets told about it. But I've seen and heard of LOB apps built thereupon that don't suffer from those bullet points, except for 5.

Gradle at least gave incremental builds... Even though javac is fast, practical java builds are sloooooww (maven)..

Indeed, thanks to a background daemon that needs at least 2 GB ram and an SSD to be competitive with Maven.

Agree, strongly. I always think it’s funny when people complain about the verbosity of Java, because most of it is self-imposed. Even more funny is that the same Java programmers will migrate to something like Groovy and then reproduce all of the same verbosity there (e.g., “Don’t use implicit ‘it’ variables! Name it theImportantThingFromTheImportantThingArray!”)

I’m really with you. The culture around it feels borderline developer-hostile. It’s exhausting and feels like I’m participating in some strange, elaborate religious ceremony.