Project Panama - the JNI Replacement (slidedeck)

General Discussions
#1

Hey guys,

Last week I gave a talk on Project Panama which is supposed to replace most JNI use case and adds some more on top of it (like a Vector API running on CPU SIMD opcodes). For people interested I’ve uploaded the slidedeck to slideshare.

The timeline for Project Panama is “definitely maybe Java 10 or later”, which results in “it’s done when it’s done” Smiley

I’d be interested what you guys (especially the ones to use JNI for lib integration with Java) think about the proposed APIs (some of them are still very early drafts) and please see the external links on the last slide and watch the videos from JVMLS!

Thanks,
Chris

#2

I don’t care about the API at all. I will use it even if it’s 10 times harder to use than JNI, as long as it eliminates the performance overhead. We can hide the ugliness in libraries like LWJGL.

My real worries:

  1. No matter how good Panama is, there is a strong dependency to Project Valhalla and value types. If that gets delayed (and it very much looks like it will), Panama won’t see the light of day, or will have crippled performance. Panama is simple compared to value types. The latter requires serious research and engineering work and there are a lot of open questions. Afaik their priority is on the Java side of things and haven’t even touched the fixed/native layout issues yet. Which is expected tbh, there are very few people inside Oracle that actually care about native interop.

  2. I doubt we’ll be able to use the full power of Panama in user code (custom intrinsics etc). My expectation is that it will be highly restricted for JVM internals (security concerns, Jigsaw bullshit, etc) and we’ll again be stuck waiting for Oracle to release the right set of public APIs. What I would prefer instead is that Oracle lays the JVM foundations and the community builds everything else.

  3. I’m afraid it’s going to be too late for Panama when it is released. Panama, AOT, value types, it will all be great, but when? Even Jigsaw hasn’t been released yet (and most people I know hate it already). Meanwhile, projects like Scala Native and Kotlin Native will get the job done.

#3

Hi

At first, the Project Panama will be usable in production in several years and we’ll have to wait for some more years for Android support. We have to go on using what already fits into our needs in the meantime.

Secondly, Project Panama might help to write Java bindings with a lot less boilerplate code and to get more contributors by lowering the difficulty (no or almost no need to code in C) but we already have GlueGen, it does the job, it supports Android, it’s fast, it’s fully tested. We need something flexible that we can adapt to our own needs. I’m not sure that Project Panama is flexible enough for us yet. If the performance of Project Panama is worse than those of GlueGen, it will be a no go.

Thirdly, I think that it might be useful for middle-level APIs targeting desktop and embedded environments but not Android. As a first step, I’d like to use it in some scenegraph APIs and 3D engines (typically to manage direct memory for textures, VBO, VAO, …). When it’s mature enough, maybe I’ll try to convince the other contributors to use it a bit :wink: