OpenJDK Java 22 Rolls Into GA With New Features

[bug77]

Feb 28, 2020 with an April 2022 Update, its also not what it says.


That wasn't really the key take aways, that would be:

"making the result "production-ready" is left as an exercise to the writer. Big companies that have adopted it have developed tons of tooling around it, use all available linters, do code generation, check the disassembly, and regularly pay the engineering cost of just using Go at all."

He's just venting. Paths are messed up because paths are messed up, not because of Go. Http servers are messed up because they're messed up, not because of Go.
And then he finishes with the lame "number of dependencies" argument. Normally, more dependencies are better, it means they're fine grained and you're pulling just what you need. But guess what? For a language like Go that compiles to executable code and links everything statically by default, it doesn't matter if you have a few big dependencies or a lot of smaller one: you're still including just what you use.

[QUOTE=mSparks;n1451566]
and
"Or rather, it's a half-truth that conveniently covers up the fact that, when you make something simple, you move complexity elsewhere."

Both of which are where java shines (you shift the complexity to a self contained jar), and are pretty much essential to getting software to the point it actually pays the bills (aka production ready).

Meh, simple solutions to complex problems are really just facades, water is wet... What else is new?

[mSparks]

He's just venting.

Sure, but everything hes venting about were solved problems in java 20 years ago, and its only got better since....
soooo...

Meh, simple solutions to complex problems are really just facades, water is wet... What else is new?

What he said was go is not ready to solve complex problems or for bringing products to market .....

meanwhile java very much is, and has been for a long time.

It will probably be 20 years before go has its log4j moment.

[bug77]

Sure, but everything hes venting about were solved problems in java 20 years ago, and its only got better since....
soooo...

Solved how? You still have to take care to set timeouts for various parts of a http call, just as you would in Go.

What he said was go is not ready to solve complex problems or for bringing products to market .....

meanwhile java very much is, and has been for a long time.

It will probably be 20 years before go has its log4j moment.

Yeah, that's the hole Go dug for itself. It will be forever confined to niche projects like Docker, Kubernetes, Prometheus or InfluxDB. It's clearly not suited for anything but the most basic of tasks

[juarezr]

There is the project Lilliput [url]<https://openjdk.org/projects/lilliput/[/url>]

The goal of this Project is to explore techniques to downsize Java object headers in the Hotspot JVM
from 128 bits to 64 bits or less, reducing Java's memory footprint. Improved performance across most,
if not all, workloads is also expected.

Wow! It is worse than I remember!

[mSparks]

Solved how? You still have to take care to set timeouts for various parts of a http call, just as you would in Go.:

No you don't, there are 20+ year old battle hardened jars for that, and pretty much every complex task you can imagine.

Yeah, that's the hole Go dug for itself. It will be forever confined to niche projects like Docker, Kubernetes, Prometheus or InfluxDB. It's clearly not suited for anything but the most basic of tasks

I was refering more to

https://go.dev/wiki/Mobile

[bug77]

No you don't, there are 20+ year old battle hardened jars for that, and pretty much every complex task you can imagine.[/URL]

You don't really know what you're talking about, do you? I'm a Java developer, I've personally had to patch up Java programs that were getting stuck at various stages of a http connection, just because whoever wrote the code use the default timeouts and they were usually "just wait till it happens". And "20+ year old battle hardened jars"? 20 years ago Java didn't have non-blocking I/O, what kind of libraries are you using?

[mSparks]

20 years ago Java didn't have non-blocking I/O

Bullshit

2001 is 23 years ago

https://web.archive.org/web/20010609052851/http://java.sun.com/j2se/1.4/docs/guide/nio/index.html

The NIO APIs include the following features:

• Buffers for data of primitive types
• Character-set encoders and decoders
• A pattern-matching facility based on Perl-style regular expressions
• Channels, a new primitive I/O abstraction
• A file interface that supports locks and memory mapping
• A multiplexed, non-blocking I/O facility for writing scalable servers

[caligula]

Yeah, that's the hole Go dug for itself. It will be forever confined to niche projects like Docker, Kubernetes, Prometheus or InfluxDB. It's clearly not suited for anything but the most basic of tasks

Ever tried pruning images from local Docker db? I noticed my system had 200 GB of "dangling images" not visible in docker images list. Pruning them took 4 hours. Yes. The performance is abysmal. The system has PCIe 5.0 SSD, 64 gigs of RAM, and 16 cores. Just wiping the Docker directories with rm would have taken milliseconds. Also I've implemented a container runtime system in bash. Yes Docker is more extensive but writing something like that is not rocket science.

[caligula]

A multiplexed, non-blocking I/O facility for writing scalable servers

But it didn't use io_uring 20 years ago.

[caligula]

Every 2-3 years I have to get back to programming Java because of some project and every time I get scared because the memory always goes to the sky and the performance is sluggish even with the huge increase in processing power and memory we got through the years.

You can't really avoid that with any language these days. I guess GNOME is a combination of C, Vala, and JS. I just rebooted my system and checked the memory use after a clean login. 1,7 GB of RAM used by GNOME desktop + terminal + htop. I don't have that many background processes. Mainly syncthing, mergerfs, and sshd. JS is slow as hell. I have a 3 year old high end phone and it's starting to slow down. Web sites are just too heavy for such legacy hardware.

It's the same with disk space usage. My Linux installation is now at 25 GB. 20 years ago something like 3 GB was sufficient.