[Joel_Mckay]

In general, Java made OO design trivial to implement, but due to a clear specification standard requirement a lot more planning/time is needed.

Thus, many sub-optimal project coordination approaches ended up fighting the design patterns. Java is a good student language, but there are so many better options now... with fewer footguns, and without Oracles farts. =3

[znpy]

Java is essentially open source enough that you can ignore oracle. All the development of java happen in openjdk, of which oracle is a contributor (along with red hat and many others). Oracle’s java is just an openjdk distribution, with some additional proprietary bits.

Pulling the oracle card when java is mentioned is a useless stunt.

[Joel_Mckay]

The OpenJDK has come a long way, but is still less than ideal.

Do you actually use that option at enterprise scale? =3

[fiddlerwoaroof]

Everywhere I’ve worked has used Eclipse Temurin or another open source release: the Oracle JVM isn’t used all that often because of license issues.

[Tostino]

Ditto. Even things like Java flight recorder are open source now and work with any JDK distribution.

[Joel_Mckay]

YOLO =3

https://openjdk.org/groups/vulnerability/advisories/

https://app.opencve.io/cve/?product=openjdk&vendor=oracle

[znpy]

I’ve always used openjdk or amazon’s flavour (i think it’s called “corretto”?).

It’s much better than ideal.

[Joel_Mckay]

If it spans your use-cases, than that is great. =3

[vkazanov]

None of the Java and OOP problems were created ar Oracle.

As much as I love hating Oracle, they pushed the language forward much more than Sun ever did.

[Joel_Mckay]

Interesting opinion, but that is only applicable for enterprise clients. The public gets a NERF'd legacy option full of known problems, limitations, and legal submarines.

The only reason Java is still somewhat relevant is ironically Android/Kotlin, and SAP/heinous-dual-stack-blobs product lines.

Best regards, =3

[vkazanov]

It is not "an interesting opinion". It is an opinion of a mid-level engineering manager who spent the last decade hiring and building teams across various parts of the industry.

Java/JVM is literally everywhere. And let me get this clear: not a fan of both java-the-language and java-the-culture.

[Joel_Mckay]

Interesting perspective, the exact same argument was made for COBOL and Fortran.

Most Enterprise level Java I saw was not clean OOP, but rather a heinous kludge sitting next to a half-baked design pattern. The 3.6B Android OS users in the world probably are more relevant in terms of development projects, and keeping your team staffed. Good luck =3

[vkazanov]

I am not speaking of some legacy systems, java is THE language right now, the same way Fortran was the only one in the first couple of decades of existance.

Besides, what is "clean OOP" even?

[Joel_Mckay]

In my opinion, ideally a well-planned/templated object structure focused around well documented design-patterns without bodged-on/polyglot binary objects.

Thus, people that actually leveraged the OO paradigm properly, and in a way that may be sustainably regression-tested/maintained over many continuous integration cycles. That kind of "clean" code tree usually only needs juniors to study around <5 files to understand even the most complex modules operation, helps mitigate bugs, and team-leads can weed out quality "issues" in minutes.

People that churn teams usually discover a YOLO and OO paradigm are fundamentally incompatible concepts. People won't know everything they need in the first release, and they will have stuff they don't need but now have to live with by the third release.

This is not a Java specific problem... but it does make it easy.

Nothing integration "teams" do will likely matter much compared to a 3.6B user-base policy change. Have a great day =3

"Nor would a wise man, seeing that he was in a hole, go to work and blindly dig it deeper..." ( The Washington Post dated 25 October 1911 )

[ludovicianul]

While Android/Kotlin keeps Java in the spotlight, Java also powers financial services, high--frequency trading systems, payment gateways, logistics platforms, and even modern microservice deployments. These are not all “legacy”,they’re mission-critical platforms handling billions of transactions daily.

[Joel_Mckay]

The exact same argument could be said for COBOL and Fortran.

>high--frequency trading systems

Probably not the Java stack itself, given GC latency and precision timing skew would translate into millions of lost dollars a second. However, people do silly things in the wrong languages all the time. =3

[npstr]

It looks like you're not up-to-date, ZGC has pauses on the microsecond dimension. Even since before ZGC was added, there are open source libs for HFT that optimize allocations to avoid GC: https://github.com/openhft =3

[Joel_Mckay]

Indeed, it is likely some naive kludge like RTSJ

Tend to deprecate Java services for a number of other reasons =3

[Yoric]

FWIW, I've seen job ads for Java developers in HFT.

It did look weird, of course, but they're also using Go (which iiuc has worse GC latency) or other garbage-collected languages (OCaml being a famous example).

[Joel_Mckay]

The "heinous-dual-stack-blobs" joke refers to loading native binary objects in the JVM, but its probably some newer naive kludge like RTSJ.

I guess it is like using a Fiat Coupe as a gravel dump-truck. lol =3

[mfru]

So tell us what the better options are in your opinion?

[Joel_Mckay]

A lot of folks prefer Scala or Kotlin even on a janky JVM.

Depends on the use-case, but I also like Elixir/Erlang, Julia, and Go.

Not all are very popular, yet each offer something uniquely beautiful. =3

[mfru]

Yet the only ecosystem with a mature library for every use case under the sun and that is not riddled with footguns is Java.

(One might argue Go comes close, though)

Javas selling point is that it can do everything reasonably well and has a huge talent pool.