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 a day ago | parent | next [-]

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 a day ago | parent [-]

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 19 hours ago | parent [-]

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 17 hours ago \| parent [-]
		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 a day ago | parent | prev [-]

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 a day ago | parent [-]

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 a day ago | parent | next [-]

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 a day ago \| parent [-]
		Indeed, it is likely some naive kludge like RTSJ Tend to deprecate Java services for a number of other reasons =3

▲

Yoric a day ago | parent | prev [-]

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 a day ago \| parent [-]
		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