optimal java experience

You need to me careful about benchmarking to find performance problems after the fact. You can get stuck in a local maxima where there is no particular cost center buts it’s all just slow.

If performance specifically is a goal there should probably at least be a theory of how it will be achieved and then that can be refined with benchmarks and profiling.

Writing the code in a natural and readable way should be number one.

I mean, even there it depends what you're doing. A small matrix multiplication library should be fast even if it makes the code uglier. For most coders you're right, though.

In my experience we all go through a stage at the Designed-Developer level of, having discovered things like Design Patterns, overengineering the design of the software to the point of making it near unmaintainable (for others or for ourselves 6 months down the line).

The next stage is to discover the joys of KISS and, like you described, refraining from premature optimization.

I think a lot of academic oop adds inheritance for the heck of it. Like they're more interested in creating a tree of life for programming than they are in creating a maintainable understandable program.

That’s the problem, a lot of CS professors never worked in the industry or did anything outside academia so they never learned those lessons…or the last time they did work was back in the 90s lol.

Doesn’t help that most universities don’t seem to offer “software engineering” degrees and so everyone takes “computer science” even if they don’t want to be a computer scientist.

The Design Patterns book itself (for many an OO-Bible) spends the first 70 something pages going all about general good OO programming advice, including (repeatedly emphasised) that OO design should favour delegation over inheritance.

Personally for me (who started programming professionally in the 90s), that first part of the book is at least as important the rest of it.

However a lot of people seemed to have learned Patterns as fad (popularized by oh-so-many people who never read a proper book about it and seem to be at the end of a long chinese-whispers chain on what those things are all about), rather than as a set of tools to use if and when it's appropriate.

(Ditto for Agile, where so many seem to have learned loose practices from it as recipes, without understanding their actual purpose and applicability)

I'll stop ranting now ;)

Atomic instructions are quite slow and if they run a lot... Rust has two types of reference counted pointer for that reason. One that has atomic reference counting for multithreaded code and one non-atomic for single threaded. Reference counting is usually overkill in the first place and can be a sign that your code doesn't have proper ownership.

Learn kotlin, it's awesome and runs on literally everything.

"They said"

You've obviously never been in the military, because it's definitely "females".

Nah. In the military, you aren't "men and women" you are "soldiers" (or sailors, Marines, or airmen). If you are referring specifically to a specific gender such as a "female" soldier, then that's what you call them.

No one says "women soldiers" except maybe a civilian.

In French, the literal translation of female and male, are only used for animals in the common language, but I have been taught that in English it is ok to use those for humans in common language. Is it not the case in your region?

Whatever.

Factories can be good in moderation. If you make factories for every class, maybe you need to rethink your practices.

I've worked with Java for decades (kid you not: learned it from reading the Java Language Specification 1.0 back when it came out) and there's definitivelly a stage (often a long one) in one's career when one thinks him/herself so great at OO and just overengineers every single software design way (way, WAY) beyond the actual objective of behind the whole OO design concept (maintenability and bug reduction), actually achieving the opposite objectives (an unmaintainable POS, riddled with hard to track bugs because of way too many unnessary details having overwhelmed the developer's ability to keep track of it all).

Eventually you learn KISS design and Refactoring as a sort of housekeeping practice for code and design.

But yeah, as a freelancer I've very commonly landed in the middle of maintenance-stage projects with existing code bases that were clearly done by somebody at that oh-so-special stage in their career, and often it's better to just reverse engineer the business requirements from the application and redo the whole thing (in the process cutting the codebase size to a small fraction of what it was).

I was part of a fun era at my university where they switched from C++, which is what I took in intro to programming, to java. So by the time I was doing some group projects senior year, I was working in C# with people who had only done Java.

They wanted to abstract everything. Everything had to be a class. Any time they repeated 2 lines of code it got put into a helper class.

We ran into an issue where the code just would not run no matter how hard we tried and of course no one on the project but me bothered to use git (they would literally send me the zipped up project on discord and I had to copy and paste everything into the actual code). I ended up rewriting the entire project overnight. It actually wasn't that bad once I got into the flow of things. Turns out none of them knew how to program without being explicitly told how.

Still not the worst college group project though. Maybe top 5.

This may be an unpopular opinion, but I like some of the ideas behind functional programming.

An excellent example would be where you have a stream of data that you need to process. With streams, filters, maps, and (to a lesser extent) reduction functions, you're encouraged to write maintainable code. As long as everything isn't horribly coupled and lambdas are replaced with named functions, you end up with a nicely readable pipeline that describes what happens at each stage. Having a bunch of smaller functions is great for unit testing, too!

But in Java... yeah, no. Java, the JVM and Java bytecode is not optimized for that style of programming.

As far as the language itself goes, the lack of suffix functions hurts readability. If we have code to do some specific, common operation over streams, we're stuck with nesting. For instance,

var result = sortAndSumEveryNthValue(2, 
                 data.stream()
                     .map(parseData)
                     .filter(ParsedData::isValid)
                     .map(ParsedData::getValue)
                )
                .map(value -> value / 2)
                ...

That would be much easier to read at a glance if we had a pipeline operator or something like Kotlin extension functions.

var result = data.stream()
                .map(parseData)
                .filter(ParsedData::isValid)
                .map(ParsedData::getValue)
                .sortAndSumEveryNthValue(2) // suffix form
                .map(value -> value / 2)
                ...

Even JavaScript added a pipeline operator to solve this kind of nesting problem.

And then we have the issues caused by the implementation of the language. Everything except primitives are an object, and only objects can be passed into generic functions.

Lambda functions? Short-lived instances of anonymous classes that implement some interface.

Generics over a primitive type (e.g. HashMap<Integer, String>)? Short-lived boxed primitives that automatically desugar to the primitive type.

If I wanted my functional code to be as fast as writing everything in an imperative style, I would have to trust that the JIT performs appropriate optimizations. Unfortunately, I don't. There's a lot that needs to be optimized:

• Inlining lambdas and small functions.
• Recognizing boxed primitives and replacing them with raw primitives.
• Escape analysis and avoiding heap memory allocations for temporary objects.
• Avoiding unnecessary copying by constructing object fields in-place.
• Converting the stream to a loop.

I'm sure some of those are implemented, but as far as benchmarks have shown, Streams are still slower in Java 17. That's not to say that Java's functional programming APIs should be avoided at all costs—that's premature optimization. But in hot loops or places where performance is critical, they are not the optimal choice.

Outside of Java but still within the JVM ecosystem, Kotlin actually has the capability to inline functions passed to higher-order functions at compile time.

/rant