Project Panama

[javster101]

Is there a plan to migrate the existing native accessto Project Panama with JDK 16?

[octylFractal]

Yes, not with JDK 16 as they're still incubating modules, but you can search the LWJGL forums and the issue tracker here with the keyword "panama" to see some of the rough ideas.

[apostolos]

Quoting @Spasi

Project Panama consists of two projects: the Foreign-Memory Access API (https://openjdk.java.net/jeps/370) and the Vector API (https://openjdk.java.net/jeps/338). 370 has been incubating since JDK 14, 338 is being introduced in JDK 16 (also incubating). I've been tracking the progress of both projects for several years and the plan is to migrate LWJGL to 370 when the API stabilizes and we're closer to a non-incubating release. It's not going to be LWJGL 3 anymore though, since we're talking about a massive breaking change (e.g. all NIO buffers are being replaced with 370's MemorySegment type). For a while, LWJGL 3 (current API) and LWJGL 4 (Panama-based API) will be maintained in parallel.

I'm not in a rush to start LWJGL 4 though, for a few reasons:

• The Panama API is still a work-in-progress, it changes quite often.
• Performance is not quite there yet. There are several reasons for that, but they're actively working on it on the JVM side. I'm looking for at least performance parity with JNI.
• Panama is designed to have strong synergy with Project Valhalla (https://openjdk.java.net/projects/valhalla/), i.e. value types. Valhalla is another major project under development for several years, but that one is extremely complicated, with major technical difficulties. Ideally, when LWJGL 4 is released, we'll have both Panama and Valhalla available.

[Glavo]

How about now? Panama has now been moved to the java.base module. Although it is still in the preview state, it is easier to use than the incubator state.

At present, Panama is still not perfect, it needs more feedback from real world use cases. If we can start to explore LWJGL4 before Panama is officially finalized, I believe it can help Panama find some design defects, so that the design of Panama can be closer to perfection before the API is frozen.

[Spasi]

Hey @Glavo,

See this reply. The first item is done already, now working on getting everything ready for the 3.3.2 release.

[Glavo]

Latest progress:

https://mail.openjdk.org/pipermail/panama-dev/2023-July/019510.html

Foreign Function & Memory API will exit preview in Java 22.

[theoparis]

Java 22 is out now 👀

[dustContributor]

Does anybody knows if the new interfaces provided in JEP 370 and in JEP 338 are going to be switched to value types once they come out?

They look like it since they all mention being "value based", like the "new" time API.

[octylFractal]

They should be, see https://openjdk.java.net/jeps/390 which warns on any @ValueBased class.

[dustContributor]

I see. Yeah it'd make total sense to do it. Same with the vectorization
API. As is currently it depends in too much JIT magic to avoid silly heap
allocations.

[ws909]

Just for reference, JEP 438 (5th Vector incubator) specifically states that the Vector API is now only being held back by the lack of Valhalla support:

This JEP proposes to re-incubate the API in JDK 20, with no changes in the API relative to JDK 19. The implementation includes small set of bug fixes and performance enhancements. This JEP also clarifies that alignment with Project Valhalla is a critical part of completing the Vector API.