Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (741)
Games in Android Showcase (225)
games submitted by our members
Games in WIP (823)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Project Panama - the JNI Replacement (slidedeck)  (Read 1126 times)
0 Members and 1 Guest are viewing this topic.
Offline noctarius

JGO Knight


Medals: 61


Manager Developer Relations @Hazelcast


« Posted 2017-04-05 06:39:43 »

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

Offline Spasi
« Reply #1 - Posted 2017-04-05 07:55:32 »

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.
Offline gouessej
« Reply #2 - Posted 2017-04-21 09:10:30 »

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

Julien Gouesse | Personal blog | Website | Jogamp
Pages: [1]
  ignore  |  Print  
 
 

 
Ecumene (110 views)
2017-09-30 02:57:34

theagentd (136 views)
2017-09-26 18:23:31

cybrmynd (245 views)
2017-08-02 12:28:51

cybrmynd (241 views)
2017-08-02 12:19:43

cybrmynd (240 views)
2017-08-02 12:18:09

Sralse (254 views)
2017-07-25 17:13:48

Archive (864 views)
2017-04-27 17:45:51

buddyBro (1008 views)
2017-04-05 03:38:00

CopyableCougar4 (1568 views)
2017-03-24 15:39:42

theagentd (1373 views)
2017-03-24 15:32:08
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!