[ravirajx7]

I’ve been working as a backend developer for close to six years now, but reading this brought me right back to college.

Like many others, I started with C. It taught me the basics - memory, pointers, writing data structures from scratch - but most of the time it felt like I was just trying not to break things. Solving problems became more about handling the language than understanding the logic.

Then I came across Java, and something just clicked. It felt structured, readable, and intentional. Almost like reading good English. For the first time, I could focus on the actual problem instead of building the tools to solve it. Collections, built-in libraries, and a reliable runtime made coding feel productive, not just painful.

Even now, years later, Java still feels like home. It’s not perfect, but it gave me the space to learn, grow, and build things that last. I really appreciated this article - it captures that quiet strength Java has, and the care so many people have put into making it better over time. It reminded me why I still enjoy writing Java after all these years.

[jajko]

Similar story - did half the university courses in C or C++, then picked up this new language called Java for next semestral project. I made 3D map of my home country from a set of 3D points in something called Java3D, long-abandoned effort that could make 3D objects and interactions ie in desktop UI but also on web via applets (I told ya long time ago, this was early 21st century).

Working under it, apart from usual initial pains was marvelous - the language itself somehow forced me to make much cleaner code compared to C, which as a beginner became horrible mess pretty quickly. Suffice to say, debugging was trivial, no pointers just easy life.

25 years later, Its close to 100% of all work I ever done professionally and I don't mind surfing that wave till retirement, Java is so spread into corporate sphere that there will be enough work especially for seasoned experts for decades to come.

Stuff juniors often complain - OO bloat, EE megabloat etc become invisible pretty quickly, and you just work with the code, however you like it. Its a great platform to see that premature optimization is really not something to worry about during initial implementation (unless you do N-th rewrite of some performance-critical app, which most of us rarely if ever do). It doesn't mean any spaghetti code is fine, just that following normal design principles is normally good enough and one can focus on things like security, clustering and actual features.

[rapsey]

Funny I had the exact opposite reaction to Java when I needed to use it in college. So many abstractions, forced design patterns and boilerplate. Absolute soul sucking joyless development.

[happymellon]

Abstract objects are optional. I haven't seen a codebase that really uses them (outside of going into the Spring Framework)

Design patterns are optional, but are applicable across languages. Their purpose is to communicate effectively.

[jjav]

> So many abstractions, forced design patterns and boilerplate.

Important to remember none of that is part of Java.

There was a period of time (and it goes in waves) when extreme complexity was the thing, and one peak of this mania coincided with the rise of Java, so a lot of people on this high horse of complexity latched on to Java because it was the place to be.

None of that is related to the language Java though, nor its fault! I've been writing java since 1996 (including many years at Sun) and not once have I worked on those silly Method­Helper­Container­Parameter­Event­Principal­Getter­Bean-style codebases.

That's purely a choice and one best avoided. Just use java as a very fast very scalable memory-safe language, keep the code simple.

(class name courtesy of https://projects.haykranen.nl/java/)

[chii]

may be it was the way you were taught java.

It had abstractions but you were never forced to use them. Ditto with design patterns - you could use them, but none were forced, unless you _had_ to use a framework (like spring), but that's a choice! May be it wasn't your choice, but it was a choice someone made.

If you used java like you used C, java is much easier and less mentally demanding, and therefore less prone to mistakes.

[rapsey]

> Ditto with design patterns - you could use them, but none were forced, unless you _had_ to use a framework (like spring), but that's a choice! May be it wasn't your choice, but it was a choice someone made.

Every language has a koolaid aspect to it. Java drinks the OOP+design patterns koolaid, so it was standard to use it incessantly. Yeah in theory there is a choice, not really in practice though. I find the typical over abstracted, one line functions everywhere java codebase revolting.

[piva00]

> Yeah in theory there is a choice, not really in practice though. I find the typical over abstracted java codebase revolting.

It has gone extremely out of fashion to try to use abstractions over abstractions in Java the past 10-ish years. It used to be The Thing to do in the early 2000s, over time people got fed up with such obtuse way of programming, everything hidden under abstractions of abstractions, fucking nightmare.

Of course, there are still large remnants of this era, and folks who were trained in this still trying to apply the same bullshit design patterns to overcomplicate simple stuff, but in my experience it's been a pretty big shift away from that to more readable and simple code.

I still dread the years I worked in Java codebases with their factories of factories, registries of delegates, all the JEE bullshit, and extremely glad I haven't had to deal with this kind of stuff for at least the past 10 years or so...

[high_na_euv]

I had same experience with c#

You focus on algorithms and solving problems instead of fighting with language, building systems, linker errors, solved problems being annoying, etc

In general the joke is real:

How much c# is faster than cpp?

By a few months at least

[happymellon]

> Solving problems became more about handling the language than understanding the logic.

I've worked with Java for 25 years and have a love/hate relationship.

Java garbage collection is both great, and terrible. Sometimes objects are instantiated in a method, and should be marked for GC when you leave the method but aren't. There isn't logic or reason, and it trips up juniors hard and reworking "new" features like streams into basic for loops fixes it, even though there isn't any really good reason why.

When it works first time you never even need to think about it, and its awesome. When it doesn't, there is no escape hatch to fix it. Its probably for the best, I would probably prefer someone switched a stream to a loop to fix a GC bug than to keep the stream and add additional code for flagging objects.

[jabiko]

> Java garbage collection is both great, and terrible. Sometimes objects are instantiated in a method, and should be marked for GC when you leave the method but aren't.

In the last decade of writing Java software I didn't ever come across a genuine GC bug where a unreferenced object wasn't collected. I'm not disputing that they exist, but if you regularly hit such "bugs" I'm wondering if your understanding of Java GC might be flawed.

Do you expect objects to be immediately collected when they are not reachable anymore?

[happymellon]

No its not regularly, I think just once in at least 10 years, probably longer. And it could easily be either a Spring bug, or bad configuration through misunderstanding.

My point was more that it can be opaque when it doesn't act as expected. Sometimes heap inspection is helpful, but if you use Kafka or Spring Data, etc, it can easily just appear to be a char or int array.

[lucianbr]

So you hit this bug about one and a half times in your entire career, you're not sure Java caused it or even if it was really a bug, but due to it you have a love/hate relationship and garbage collection is terrible?

[lucianbr]

> Sometimes objects are instantiated in a method, and should be marked for GC when you leave the method but aren't.

Can you give more details, and/or an example?

[lolive]

Apart from the comment of happymellon (blaming Spring for doing things behind your back), it happens that a factory , building objects for you , will have a “bug” and retain a reference to them for whatever reason. That is sometimes tricky to figure out. Nothing Java can be blamed for, as these kind of tricks can happen in any language. ([newbie at C but] I suppose in C, the consumer of the object can force its deallocation, which may lead to other nasty side effect]

[lucianbr]

> I've worked with Java for 25 years and have a love/hate relationship.

> Java garbage collection is both great, and terrible.

> Nothing Java can be blamed for

I mean, it's not like we're discussing Java or anything. So they hate java because of something that can happen in any language?

[lolive]

They expected not to have to deal with memory at all, I presume ;)

[to go a bit off topic, the debugging of those issues is reasonably tool-assisted in Java, whereas I honestly don’t know how to solve them in, let’s say, Javascript/TS).