Java Turns 25 – Whats Next? [pdf]

In high-traffic environments, that ignorance punishes you. I've always felt Java and the JVM are of the mindset that you need a Ph.D. to even understand how it works or how to configure it, and if you can't get it, then you're just a bad programmer.

You need to know if you're blocking threads, if there's memory contention, and if libraries you pull in are using the forkjoin common pool (which you're likely using as a default threadpool). And when something blows up, finding the reason (even for any of the above issues) is really tough. You can use flight recorder, heap dumps and gc logs all day, but good luck navigating it all unless you're a genius. I've seen too many devs end up shrugging and hoping the issues are transient.

Even figuring out proper threadpool usage isn't straightforward. Look at the number of concurrency abstractions just to model concurrency in your system: https://www.youtube.com/watch?v=yhguOt863nw. It's ridiculous.

Lots of large tech companies "seem" to "make it work." But if my experience is at all similar, they're just relying on a handful of Ph.D.'s to hold the hands of the rest of the company when it comes to troubleshooting.

Part of the reason I fell in love with Elixir/Erlang and the BEAM is that it provides a simple (actor) concurrency model (with a single concurrency primitive, a process) and guardrails (time-slice scheduling) to prevent libraries from shooting you in the foot. OTP's observer makes finding bottlenecks a breeze.

For the web, taming concurrency feels way more important than any cpu-crunching perf gains the JVM can give you. I'm too stupid for the JVM; I'll stick to tools that take away numerous categories of complexity and get me closer to mastering my system.

Yes. As others have said, 'java is stable' which means the old stuff still works. Which in turn means that a lot of people are still using it and still writing blog posts about it. That still makes these old things often obsolete, or needlessly complex and just 'lesser than'. They don't support certain nice features or support them very badly, or have other significant downsides - 25 years of experience does lead to insights, after all.

20 years ago, you loaded your JDBC driver with `Class.forName`. You _STILL_ see this in many examples (and it hasn't been necessary for 15+ years).

These days, you:

* Use a load balancer like hikari * Consider raw JDBC as basically nuts as far as an API goes, and you use JOOQ or JDBI. Or JPA/Hibernate of course, if you don't want SQL/want DB independence and don't think you'll need to performance-tweak queries too much. * You use serializable transaction levels and toss _all_ the code that interacts with DBs into a lambda so that the framework can handle retries for you.

And that's just DBs. As a general trend:

Libraries tend to wax and wane. Right now spring is _very_ popular. JSP is the kind of outdated crud that is just a straight up 'do not use this right now' (even if it still kinda works). For date stuff, use java.time. Libraries in general are more focussed on configure-via-java-code, and dip more into code generation and annotations (example: JOOQ). You don't use The JSONObject API, you use jackson or gson. The list is very long.

I have no particular advice on how to know all this stuff as someone not familiar with the (modern) java ecosystem, though. Just pointing out that 'stable' doesn't translate to 'not much new in the past 15 years'.

Reactive is probably a mistake with loom looming around the corner.

As for guice, my preference for reflective runtime injection is Weld since it's the standard reference implementation.

Here's an example of two far less antiquated technology companies using a PDF for something that could also have been a web page, but was found to make more sense as a print-style publication: https://blog.google/documents/73/Exposure_Notification_-_FAQ...