OpenJDK Java 22 Rolls Into GA With New Features

[stormcrow]

JRE vs JDK has nothing to do regarding licensing or Oracle: JDK = JRE + Development Tool

How many concurrency concepts provided by which platforms did you evaluate, to come to such a bold conclusion?

RE JRE vs JDK, true that the JDK and JRE are just super/subsets of each other.

A bit of expansion and explanation:
The reason the Sun JVM v8 is still supported is legacy compatibility. It's not entirely a license issue. There's legacy software out there, that for whatever reason is good for the entities in question (expense, still 'just works', lack of interest, deaths), "stuck" on Java v8. It will not function correctly on any JVM past version 8. The companies that use it, people that write it, etc. have no intentions to make it track the subsequent releases. Because of the security exposure for systems using the end user JRE, Oracle still puts out regular security fixes. Even if they didn't, it likely wouldn't budge those Sun JVM v.8 users.

There's a lot of JVMs out there. Some are made by Oracle (Sun), IBM, Bellsoft, etc. and there's the opensource OpenJDK with the feature exceptions. They all have different feature sets and they track the reference implementations at their own paces. Java the language in theory is separate from the Java Virtual Machine, in practice is just rarely seen as anything other than dependent on a given VM.

[caligula]

.NET languages are generally more modern and are more feature rich. Like concurency, async on .NET is excellent and probably the best concurency from all platforms everywhere nad the most matured one. NET core lacks some features on linux.

Um so Java contains project Loom's lightweight threads now. I don't think .NET is any better at that. Loom is actually more recent addition. There are also the executors and other APIs for concurrency. What's missing? Maybe borrow checker and restricting access from other threads. Also the structured concurrency is coming soon.

Also the collections are pretty solid. They've added some bridge methods later. E.g. now you can just call toList to convert a stream to a list. The sequenced collections addition also improved the collection structure a bit.

I also think .NET have a prettier and easier and more well-designed API than Java for things like files and collections. .NET also have some nice language features like properties, file-scoped namespaces

There are new APIs for IO/Files in recent Java versions. Not exactly sure what's missing.

I’m a little unclear on modern Java. Why is it the JDK is rapidly developing through versions but JRE remains at v8. Is the JRE versioning just a compatibility thing and it can run code from the latest JDK?

This discussion has been active since Java 6 or so. Some obsolete legacy apps stuck with Java 6-8. They were originally planning to release Project Jigsaw earlier but postponed it to Java 9. Now for some reason many legacy projects can't update their stuff. Lack of money / developers? The new APIs and libraries and safer and faster. Apparently companies don't care about CVEs or performance at all. Just recently Netflix told upgrading Java improved their CPU usage by 20%. See https://www.reddit.com/r/java/commen...mment/ksbb99n/

[Timeus]

Java still doesn't have null type. I doubt that it would get it in the near future due to backward compatibility. Good luck dealing with NPEs.

And most modern programming languages support named parameters with default values but Java doesn't.

[usta]

I’m a little unclear on modern Java. Why is it the JDK is rapidly developing through versions but JRE remains at v8. Is the JRE versioning just a compatibility thing and it can run code from the latest JDK?

There are/were a couple of things why jre 8 is stuck nowadays systems:
- JavaFx : It was decoupled from jre/jdk with java 11 and most of java desktop apps were using it for their gui needs
- Applets : It was an ancient system which were so popular in old times.
- Oracle's licensing : Most of people confused about oracle's licensing things and avoid to upgrade
- Compatibility : After java8 there were lots of things have changed ( package names , ... ) and thus created a barrier to upgrade their codebase for companies
- Resistance of users : Most of users ( windows users ) dont want to upgrade their current system with something not have enough eco system/

On the other hand there are a couple of nice things happend and forcing users also companies to upgrade to newer versions such as :
- Minecraft : Lets face it for most of home users java is generally only exist on their system for this beauty. Which requires java17+ with recent versions [ so users needs to upgrade if they want to continue with newly made mods and newer servers ]
- Spring/Spring boot : With starting version 3.x ( Springboot ) / 6.x ( Spring ) users/developers/devops needs to use java17+
- openJavaFx (aka openjfx) : Which were rebraned after javafx and with its version 20+ it needs java 17+ ( current LTS version is 21 )[it will have version 22 within 2 weeks ]
- End of support by browsers : With dead of IE and also end of support of applets by all browsers ( chrome , firefox , edge , ... ) which will ended need of jre 8 for this thing
- EOL : java/jdk/jre 8( oracle ) will have eol at 31 Dec 2030. Probably most of users dev will act within 2 years to recode/upgrade their current source before they hit this time
- ...

[browseria]

I’m a little unclear on modern Java. Why is it the JDK is rapidly developing through versions but JRE remains at v8. Is the JRE versioning just a compatibility thing and it can run code from the latest JDK?

After Java 8, a JRE is no longer required or desired. All versions of Java 9+ come with the jlink tool, which you use to create just enough of the JDK around your application to run your java app. You never have to worry about if you have the right version installed, the version you need is bundled with your app, typically much smaller than even the JRE alone.

[juarezr]

I think I would rather use .NET instead of Java.

As .NET came some years later, it avoided some pitfalls that bloated Java and will be in the language forever:

- Type Erasure

- No need to pass Type.class to constructor and functions
- Class.forName(className).getConstructor(String.cla ss).newInstance(arg);

- All methods as virtual

- This imploded direct jumps in runtime execution requiring that any method call go through a "vtable" lookup
- Although newer JVMs with the latest JIT technology can get back something from the performance it was something that should be solved during compilation, not execution.

- System-starving memory requirements due to huge object size

- 8 bytes + value for any object ( I don't remember exactly )
- 34 bytes + content for any string

Also as the language was stagnant for years, everybody implemented their "commons" libraries that are included many times with many versions in the jars dependencies for anything useful.

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.

[partcyborg]

.NET languages are generally more modern and are more feature rich. Like concurency, async on .NET is excellent and probably the best concurency from all platforms everywhere nad the most matured one.

Sorry, this isn't remotely true. Go's concurrency/async model is light-years beyond .NET

[cynic]

.NET languages are generally more modern and are more feature rich. Like concurency, async on .NET is excellent and probably the best concurency from all platforms everywhere nad the most matured one. NET core lacks some features on linux.

I think you never looked at Go

[bug77]

Sorry, this isn't remotely true. Go's concurrency/async model is light-years beyond .NET

I think you never looked at Go

Go simplifies a lot by not offering user-facing thread groups or priorities. But yes, it makes working with threads almost as fearless as Rust.

[cynic]

Go simplifies a lot by not offering user-facing thread groups or priorities. But yes, it makes working with threads almost as fearless as Rust.

that's my personal perception of fear, when it comes to concurrency:

Go: fearless to write / a bit less fearless when running (there's a lot of errors you can make that could explode at runtime)
Rust: definitely not fearless when writing (!!!) / absolutely fearless to run once you get it to compile 🙂
Java: a good balance of the two