joe_mwangi

But what example would you have to demonstrate it's more powerful? As a matter of fact, Kotlin smart-cast approach can't tolerate mutability because it can't guarantee safety, yet Java guarantees.

But they should use reasoning first.

Wait, what do you mean Kotlin smart-casting is more powerful than pattern matching? Like what example?

Trust me. That's a common argument used when java introduces new features. Wait you see the same argument once value classes come to jdk 28.

Yes.. lol. The biggest argument now is Kotlin having nullness by default in the language. Just check around the comment section. Now java is planning to have them which will further help jvm to optimise for performance. Not sure what the next argument will be after.

Really? I don't thinks so. There is a reason JEP 539 is in preview. There is a reason internal annotations exists in current valhalla jdk prototype and upcoming java 28 such as @jdk.internal.vm.annotation.NullRestricted, @jdk.internal.value.ValueClass.newNullRestrictedNonAtomicArray. Also, there is a reason value classes are allowed to be null. This is because nullness types will be a key factor to the java language.

Once it gets nullness types, hackernews is gonna explode!

Typeclasses caught me by surprise. Smart move by the java team.

Also, future specialisation if it is introduced, it will enable the JIT to get enough information to ensure <T> becomes stored in cpu registeres or enable <T[]> to be flattened in memory.

Yeaaah. They are going to introduce approaches for the programmer to decide if tearability is allowed or not. Already there are internal annotations for fields and types to enable it that probably will become a language feature in future.

They are researching to have immutable arrays. Also multifields (stack allocated arrays as fields in value classes). So, there is a possibility.

I've done some tests with current value classes in latest prototype with full optimisation through annotation. Apparently, everything was being compiled to assembly code with no gc calls. It seems this old school ideology of slow java is about to end in near future. I'm actually intrigued how it will compete with Rust which can't optimise code further while running, while JVM JIT has more info which it could aggressively further optimise, especially hot paths.

Also, this will be used for future null-restricted types.

Better late than never.

This time, 30mb.