How feasible is it for all native code to be ported to Panama?

[Maurizio Cimadamore]

Hi Julian.

This is an interesting question and one we've been pondering on our own 
for a good while (as you can imagine).

The short answer is "yes with a but". In general it is possible to use 
FFM to replace existing pieces of JNI code. The devil is in the details. 
Some of them are listed below.

First, not all libraries are created equal - for instance 
UnixNativeDispatcher "screams" to use FFM, but it's used very early in 
bootstrap, so there are issues with that (we hope Leyden can address 
those at some point). As a rule of thumb, the further away a library is 
from java.base, the higher are the chances of success with FFM adoption.

In that sense, the client area is indeed a nice playground for 
FFM/jextract as it's relatively immune to bootstrap issues. We started 
some work (see [1]). But migrating _all_ Swing/AWT to use FFM, while 
possible, is a very big ask (in the sense that the amount of resources 
we'd need to throw at the problem might not make it worth it in the end).

Lastly, while JNI is very integrated in the JDK build system (to the 
point you can drop a C file in the right place and it "just works"), FFM 
is not yet there. Adoption of FFM in the JDK requires coming up with a 
JDK source layout that can accommodate for extracted code, and deciding 
whether jextract should be ran as part of the build, or offline, and 
check in the corresponding sources.

None of these problems are unsormountable though. It's just "work". And 
the good news is, we have started to chip away at this problem, so you 
can expect more FFM-ization in the months to come.

Cheers
Maurizio

[1] - https://git.openjdk.org/jdk/pull/15476

On 31/05/2024 13:50, Julian Waters wrote:
> Hi all,
>
> Just a quick question: Is a future where everything is based on Panama
> and written in pure Java farfetched, or is it actually deceptively
> more realistic than it seems? I just had this thought today when I
> found out that lible had been removed and replaced entirely with a
> Panama rewrite while fixing a rebase conflict earlier. The only C++ in
> the JDK would just be HotSpot, and the only other native code would be
> hsdis, the launcher exes and the jsvml and SLEEF(?) sources. It sounds
> almost too good to be true, so I'll risk sounding like an idiot and
> ask: Is it? I'm admittedly asking because I maintain a port of the
> JDK, and it would be significantly easier to maintain if the only
> native code was HotSpot and small portions of C and Assembly code
> scattered around the repository. I definitely would be happy to see
> awt.dll go, that's for sure!
>
> best regards,
> Julian