5

I have been reading about the Panama Project recently.

I understand that it will be the next generation replacement to JNI - it will allow java developers to code on the native layer using Java (which is amazing IMHO).

The usage is simple from what I can tell looking at jnr-posix, for example:

public class FileTest {
    private static POSIX posix;

    @BeforeClass
    public static void setUpClass() throws Exception {
        posix = POSIXFactory.getPOSIX(new DummyPOSIXHandler(), true);
    }

    @Test
    public void utimesTest() throws Throwable {
        // FIXME: On Windows this is working but providing wrong numbers and therefore getting wrong results.
        if (!Platform.IS_WINDOWS) {
            File f = File.createTempFile("utimes", null);

            int rval = posix.utimes(f.getAbsolutePath(), new long[]{800, 200}, new long[]{900, 300});
            assertEquals("utimes did not return 0", 0, rval);

            FileStat stat = posix.stat(f.getAbsolutePath());

            assertEquals("atime seconds failed", 800, stat.atime());
            assertEquals("mtime seconds failed", 900, stat.mtime());

            // The nano secs part is available in other stat implementations. We really just want to verify that the
            // nsec portion of the timeval is passed through to the POSIX call.
            // Mac seems to fail this test sporadically.
            if (stat instanceof NanosecondFileStat && !Platform.IS_MAC) {
                NanosecondFileStat linuxStat = (NanosecondFileStat) stat;

                assertEquals("atime useconds failed", 200000, linuxStat.aTimeNanoSecs());
                assertEquals("mtime useconds failed", 300000, linuxStat.mTimeNanoSecs());
            }

            f.delete();
        }
    }
// ....
// ....
// ....
}

My question is this - having worked with JNI, and knowing how cumbersome it is, will there be a solution for porting existing JNI solutions to the Panama format?

IE - go over the generated (via the deprecated javah) C header file and given implementation in C of the header file, identify functions which can be replaced by the Panama API, then generate a java output file?

Or will existing JNI solutions need to be refactored by hand?

Additional links :

Jorn Vernee
  • 31,735
  • 4
  • 76
  • 93
Rann Lifshitz
  • 4,040
  • 4
  • 22
  • 42

1 Answers1

5

The JNI format is as follows:

Java -> JNI glue-code library -> Native code

One of the goals of project panama is to remove this middle layer and get:

Java -> Native code

The idea is that you can use a command line tool to process a native header (.h) file to generate a Java interface for calling the native code, and the JDK code will do the rest at runtime as far as connecting the 2 together goes.

If your current JNI code does a lot of stuff in this glue-code layer, then that might have to be re-written on the Java side when porting to panama. (this depends on how much could be done automatically by the used interface extraction tool).

But if you are using something like JNA or JNR then moving to panama should be relatively easy, since those 2 have very similar APIs, where you bind an interface to a native library as well.

But questions like:

will there be a solution for porting existing JNI solutions to the Panama format?

Are difficult to answer, since nobody can predict the future. I feel that there are enough differences between panama and JNI that an automatic 1-to-1 conversion between the 2 will probably not be possible. Though if your glue-code is not doing much besides forwarding arguments then the interface extraction tool will probably be able to do all the work for you.

If you're interested you could take a look at the early access builds of panama that started shipping recently: https://jdk.java.net/panama/

Or watch a recent talk about it: https://youtu.be/cfxBrYud9KM

Jorn Vernee
  • 31,735
  • 4
  • 76
  • 93