> 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.
> 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?
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.
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?
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]
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).
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.