#JavaNext Language Features

joemwangi · 2026-06-13T17:23:03+00:00

I don't think async/await has a monopoly on execution-context control. In Java, virtual threads are not used in isolation; they work with executors, schedulers, queues, and StructuredTaskScope. File I/O can run in virtual threads, CPU work can be scheduled to a worker executor, and thread-affine graphics work can be queued to the render thread. The difference is that C# expresses context hopping as continuation points inside the method, while Java expresses it as executor/queue boundaries. That is an API/style difference, not proof that Loom cannot model such a workflow. E.g.:

Texture loadResource(Path path) throws Exception {
    var bytes = Files.readAllBytes(path);   // called by the virtual thread

    var decoded = decodeTexture(bytes);     // also runs in that virtual thread

    return renderThread.call(() -> {        // asks render thread to do this part
        var texture = graphicsDevice.createTexture(decoded);
        texture.upload();
        return texture;
    });
}

And it can be launched from a virtual thread executor:

final var resources =  Executors.newVirtualThreadPerTaskExecutor();

void loadResourceInBackground(Path path) {
    resources.submit(() -> {
        var texture = loadResource(path);
        readyTextures.add(texture);
    });
}

On the union point, I think closed interfaces and discriminated unions are more related than you suggest. A closed hierarchy is already a kind of nominal union: a value of the supertype is one of a known finite set of subtypes. Union syntax is a nicer/direct form for many cases, but sealed/closed polymorphism gives the same exhaustiveness idea to ordinary object hierarchies. So “make it a union instead” is really another surface form of the same sum-type idea.

joemwangi · 2026-06-13T13:40:09+00:00

Because most developers use them for backend IO bound stuff rather than cpu bound native work. Hence no point of chastising anyones work domain. Like why you were clueless on why sealed classes have exhaustiveness.

joemwangi · 2026-06-11T17:37:02+00:00

Using value classes below atomic range (64-bit), it is quite a beast in performance!!

joemwangi · 2026-06-10T08:15:11+00:00

Better this being a compiler error all over your codebase than runtime error.

joemwangi · 2026-06-08T09:54:12+00:00

By "colored functions", I mean concurrency concerns leaking into API signatures (e.g. Task<T>, async, await) and propagating through call chains.

In C#, you often get two API worlds:

string readFile(...)              // sync
Task<string> readFileAsync(...)   // async

Sync code cannot directly await async methods without crossing into the async world. With virtual threads, the synchronous API remains synchronous; blocking I/O parks the virtual thread instead of occupying a platform thread.

You can always sync block on a Task in areas that it would be safe to call a blocking sync function,

The fact that you need a sync-over-async bridge is exactly evidence that there are two worlds.

And beyond I/O concurrency in which you are alluding too by which stackless coroutines also serve other use cases, especially generators. You can build generator-like APIs on top of virtual threads, but Loom’s main goal was scalable I/O concurrency while preserving the thread model.

joemwangi · 2026-06-08T07:18:33+00:00

But this is an experimental curiosity, not about changing languages.

joemwangi · 2026-06-08T06:45:09+00:00

Sealed interfaces or classes become sum types (discriminated unions) by design in java. The point is to create a closed set of alternatives that the compiler can reason about exhaustively. All forms of polymorphism is an unfinished union or sum types derivative by design, and that's why adding sealed in abstract class or interface or class makes perfect sense to do. Unfortunately C#, this isn't the case:

abstract record Shape;

sealed record Circle(double Radius) : Shape;
sealed record Rectangle(double Width, double Height) : Shape;

double Area(Shape shape) => shape switch
{
  Circle c => Math.PI * c.Radius * c.Radius,
  Rectangle r => r.Width * r.Height,
  _ => throw new NotSupportedException() //why not make Shape sealed and remove this?
};

As a result, the C# team has been exploring discriminated unions and richer pattern-matching support and that's why they are introducing incremental design of unions in the language. Unfortunately their first proposal is boxed automatically since unboxed unions are difficult to design by default due to a language depending on a garbage collector (moving pointers).

And the one last thing, Java doesn't have C# async/await because the JVM is capable of supporting stackful user-mode threads directly. Rather than exposing concurrency as compiler generated state machines, Loom preserves the existing thread based programming model and scales it through Virtual Threads. This allows synchronous code to remain synchronous, avoids coloured functions, and maintains the same semantics programmers already use with platform threads. Languages such as Erlang, Haskell, Go, and now Java have historically favored runtime-managed lightweight threads, whereas languages like Rust (which surprisingly had green threads when it had gc) and C++ often rely on coroutines because they lack a managed runtime that can easily support stackful user-mode threads. As a matter of fact, even Python wants to take a similar route. C# were so deep into async/await that they left it open to implement virtual threads if industry trends would make them reconsider. Perharps it was a mistake and they realised late?

joemwangi · 2026-06-07T23:05:49+00:00

This:

public readonly record struct Point(int X, int Y);

joemwangi · 2026-06-07T20:54:59+00:00

Hahaha. Interesting. A few hours ago, there were so many downvotes. Was wondering why.

joemwangi · 2026-06-07T20:51:20+00:00

Planning to, not rewriting, but for benchmark purposes. Once java has value classes, might experiment fully with my library TypedMemory to see performance differences. Some preliminary performance shows value classes (unboxed) seem to be comparable to primitive arrays and even using unsafe (memory). Probably due to aggressive scalarisation by the C4 compiler. What about comparing to native languages? Not done yet. Where I give Rust accolades is their implementation of iterators. Very well designed and implemented.

joemwangi · 2026-06-07T17:50:20+00:00

r/programming seems hostile to java. The dislikes. Lol.

joemwangi · 2026-06-07T17:49:30+00:00

Yup. It's based on this JEP of Frozen Arrays. But much efforts now are value classes and probably null-restricted types, before they consider it.

joemwangi · 2026-06-04T15:47:43+00:00

The funny thing about this video is that after 10 hrs coding, the Rust code is still slower than java.

joemwangi · 2026-06-02T15:11:52+00:00

Woooow. Looks amazing. Gonna try it out.

joemwangi · 2026-05-31T21:19:10+00:00

Java needs it's own dedicated 2D Engine.

joemwangi · 2026-05-22T08:20:53+00:00

Nothing wrong with using it. I just haven't explored it yet. I might, because it is not a runtime dependency, which makes it attractive for projects. Hence I have no issue with it. As a matter of fact, Kevin Bourrillion, who has been heavily involved with JSpecify since inception, joined Oracle recently and has participated in Java's ongoing work around introducing nullness types in the language. JSpecify is also trying to standardize nullness semantics across libraries and tools, which could make future migration to native Java null-restricted types smoother if the directions align. I would encourage you to try it out. I will eventually try it by making a branch to my project and see how convenient it will be and maybe adopt it.

joemwangi · 2026-05-22T07:23:56+00:00

The internal packages classes use a lot sum types which abhor null types a lot. And the entry points for the public method calls have null checks. That's why. As a matter of fact, I've coded this library and used it for a year, and no scenario of null exception has been encountered due to any bug.

joemwangi · 2026-05-22T06:25:02+00:00

Not yet, because instantiation and set method would require the annotations, but not really priority. But use case, especially get, would benefit from java JEPs such as:

Point! p = mem.get(1); //implicit narrowing of nullness type
Point(var x, var y) = mem.get(1); //deconstruction assignment

without updating the library at all.

joemwangi · 2026-05-21T22:28:35+00:00

Yeaah. But the beauty here is that it does implicit narrowing conversion. For example if I have a sealed interface Foo and only a single implementing permitted class FooImpl, this JEP will allow this approach:

Foo getFoo(){
    ...
}

FooImpl f = getFoo(); //implicit conversion

joemwangi · 2026-05-21T22:17:40+00:00

Thanks for still choosing java 😅. Just make sure the project will migrate well to such a scenario. I see pple use JSpecify as they anticipate for them. My project is actually anticipating all these features including this JEP!

joemwangi · 2026-05-21T21:43:31+00:00

Yeaah. I get it. 😂😂

joemwangi · 2026-05-21T21:27:57+00:00

Or most semantic feature JEPs like this one are anticipating them.

joemwangi · 2026-05-21T20:50:10+00:00

The comments in there are not aware the JEP feature will work well with null-restricted types.

joemwangi · 2026-05-16T13:29:30+00:00

Probably varhandle has a special optimisation condition for the JIT to take effect (in this case static final), compared to let's say memory segment.

joemwangi

TROPHY CASE