OpenJDK Java 22 Rolls Into GA With New Features

[mSparks]

But it didn't use io_uring 20 years ago.

didn't hold Jeffrey Dean and Sanjay Ghemawat back.

[bug77]

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

Fair enough. But that was just about the files, the first step. Async servlets, http clients came years later.

[bug77]

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.

I prune docker images regularly, I haven't seen that behavior. But I am aware that, since Go's GC is non-configurable, it's totally possible to stumble upon scenarios that will tank performance. Maybe I've been lucky, but I haven't seen that so far.

[mSparks]

http clients came years later.

Still 20+ year old battle tested jars

https://hc.apache.org/httpclient-legacy/index.html

HttpClient was started in 2001 as a subproject of the Jakarta Commons, based on code developed by the Jakarta Slide project. It was promoted out of the Commons in 2004, graduating to a separate Jakarta project. In 2005, the HttpComponents project at Jakarta was created, with the task of developing a successor to HttpClient 3.x and to maintain the existing codebase until the new one is ready to take over. The Commons project, cradle of HttpClient, left Jakarta in 2007 to become an independent Top Level Project. Later in the same year, the HttpComponents project also left Jakarta to become an independent Top Level Project, taking the responsibility for maintaining HttpClient with it.

https://jakarta.apache.org/

Meanwhile, the whole point of his golang post was you can't even set timeouts in GO......

And that's before you get into frameworks like mission control and Jakarta Faces/JSF that date back to 2001, power pretty much every large website and have no Golang equivalents.

[bug77]

Still 20+ year old battle tested jars

https://hc.apache.org/httpclient-legacy/index.html

HttpClient was started in 2001 as a subproject of the Jakarta Commons, based on code developed by the Jakarta Slide project. It was promoted out of the Commons in 2004, graduating to a separate Jakarta project. In 2005, the HttpComponents project at Jakarta was created, with the task of developing a successor to HttpClient 3.x and to maintain the existing codebase until the new one is ready to take over. The Commons project, cradle of HttpClient, left Jakarta in 2007 to become an independent Top Level Project. Later in the same year, the HttpComponents project also left Jakarta to become an independent Top Level Project, taking the responsibility for maintaining HttpClient with it.

https://jakarta.apache.org/

Well, just because the project was started 20 years ago, that doesn't mean we get 20yo battle hardened jar. Http client today has little in common with the initial versions. (Thank God for them anyway. Thank God for most Apache projects actually.)

Meanwhile, the whole point of his golang post was you can't even set timeouts in GO......

Yes, totally unsupported: https://blog.cloudflare.com/the-comp...-http-timeouts

And that's before you get into frameworks like mission control and Jakarta Faces/JSF that date back to 2001, power pretty much every large website and have no Golang equivalents.

JSF powers what? https://www.statista.com/statistics/...rameworks-web/
That thing has no business in a REST/GraphQL world.

[mSparks]

Yes, totally unsupported: https://blog.cloudflare.com/the-comp...-http-timeouts

That was his point, it sets deadlines not timeouts, so the connection gets killed even while it is actively transferring data....

Well, just because the project was started 20 years ago, that doesn't mean we get 20yo battle hardened jar.

pretty much does tho.

JSF powers what?

Not something startups will use because it's not "cool", but it was very successful on the enterprise scene for a very long time and will stay so for the foreseeable future.

That thing has no business in a REST/GraphQL world.

And GraphQL/Node has no place in the JSF/Java EE world, completely different audiences.

[juarezr]

I have a 3 year old high end phone and it's starting to slow down.

Try to remove Java from the phone and maybe you would solve that.

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.

In my last Java app, the fat JAR has almost 1GB. How could It get this big? It was because each one of the Java libraries included a divergent version of other libraries/jars. So it ended with many versions of the same lib.

You can't really avoid that with any language these days.

Maybe not. But some languages excel in the bloat factor and Java does for sure.

[mSparks]

How could It get this big?

jar is just zip with some additional meta data, sounds more like you bundled the entire project including git history into it, or maybe a massively bloated framework like electron that ships a copy of chromium for every OS alongside the install.

even a large java application like say datacamp is only 16.75MB.

[caligula]

In my last Java app, the fat JAR has almost 1GB. How could It get this big? It was because each one of the Java libraries included a divergent version of other libraries/jars. So it ended with many versions of the same lib.

What build system did you use? At least Maven just picks one version per library.

[darkonix]

In my last Java app, the fat JAR has almost 1GB. How could It get this big? It was because each one of the Java libraries included a divergent version of other libraries/jars. So it ended with many versions of the same lib.

I'm guessing that is a problem of how the application is built. Java applications can not load multiple versions of the same class unless they are loaded with different classloaders and not visible to each other.

Maven or Gradle projects would usually select onlyone version of each dependency.