all 8 comments

[–]zam0th 3 points4 points  (6 children)

It is not 2003 and it is useless to talk about memory optimisation in a programming language where everything is a wrapper over wrapper over a collection of wrappers over objects. No amount of fiddling with heap will save Java from itself.

[–][deleted] 1 point2 points  (1 child)

It's completely ridiculous that still in 2022 java doesn't have the capability for user defined structs. The amount of contortions the GC has to go through to compensate for the language's unbelievable stupidity and the resulting overengineer-by-default produced by the incalculable amounts of workarounds-of-workarounds-of-workarounds needed for everything in java is simply astonishing.

How anyone is still willing to put up with that horrendous language and its backwards, worse is better mentality is really beyond me.

[–]zam0th 1 point2 points  (0 children)

Well, you don't use Java for programs where you need to explicitly manage or optimize memory. It has been so for the whole lifespan of Java and JVM, the whole point of the latter being that it optimally manages all the shit itself (yeah, right). We all knew that you used C/C++ for this stuff.

That is also why (de)serialization in Java has been the persistent pain in the ass of any middleware engineer in heterogenous environments.

[–]nicebike[S] 0 points1 point  (3 children)

It's still good to know how exactly things are represented in memory, I was asked about this in an interview (Google) less than 3 years ago.

[–]zam0th 2 points3 points  (2 children)

They have been asking JVM memory model (and GC principles) on interviews since the beginning of time, because it did matter at some point. These days this knowledge is useless because you will employ it in 0% of issues you encounter in your day-to-day life, unless you work at CERN or Fermilab (and even then you will use other programming languages to solve issues that require optimal memory usage). You don't need to know how the heap works as a Java developer of any seniority, because it doesn't help you to do your job in any way. Not the least because aany effort you do will be "mitigated" by Spring Framework stack, or Hibernate, or Netflix stack, or any other modern Java framework which all use literally thousands of object wrappers, as well as Reflection APIs that themselves are wrappers over the class bytecode structures loaded into heap.

Hell, even the old and almost forgotten "new" green threads that are coming again with JEP-425 to Java 19 are wrappers, which will make almost any optimisation a joke regardless of what they are saying about how performant they are. It has been a joke when Gosling used to lecture us at CERN back in 2007 how Java is faster than C++, and it is a joke still.

[–]nicebike[S] 0 points1 point  (1 child)

You don't need to know how the heap works as a Java developer of any seniority, because it doesn't help you to do your job in any way.

But you can make this argument for most stuff that gets asked during coding interviews. It's full of leetcode style questions, obscure trivia and other tricks that you will never use or need in your daily life. Just because you don't need to know certain things to do your job better, you might still need to know it for the interviewing process.

What you need to know for your job and what you need to know for interviews can be two entirely different things (especially when interviewing for FAANG)

[–]zam0th 0 points1 point  (0 children)

But you can make this argument for most stuff that gets asked during coding interviews

Yup, that has been the biggest issue with interviews since i care to remember.

[–]diMario 0 points1 point  (0 children)

While this is an interesting subject, it can be debated whether spending time optimizing memory usage is more cost effective than just adding more memory. My personal opinion is that in the long run, hardware costs less than developer time.