9 ms·
JEP 419: Foreign Function and Memory API
- mothsonasloth 5y agoAnyone have real world examples of what JNI and this proposal could do? I am guessing this is for more sophisticated things than just sending data to Microsoft Excel application?
- pilif 5y agoThis is about calling into any native operating system APIs, as long as they are callable via C or C++ (which these days means "all" operating system APIs). Think native UI controls, native hardware driver access, native access to OS services, etc. JNI is somewhat harder to use, because you need custom glue on both sides of the border: Some custom classes in Java and some custom code on the C (and C++) side. This proposal would remove the need for the glue on the C side and would allow a pure java solution. Something like this has existed in third-party form for a while as JNA (https://github.com/java-native-access/jna https://github.com/java-native-access/jna), but now it's going to be built into the JRE itself (if the proposal passes through review)
- p2detar 5y agoI wrote a tiny article with a couple of examples 3 years ago. [1] Having worked with JNI in the past, I find the FF concept convenient but still somewhat verbose. In any case, my experience is 3 years old. A lot may have changed since then. 1 - https://dev.to/petarov/java-and-native-code-in-openjdk-13-18em https://dev.to/petarov/java-and-native-code-in-openjdk-13-18...
- merb 5y agonetty uses jni https://github.com/netty/netty-tcnative https://github.com/netty/netty-tcnative for example
- kryptiskt 5y agoThat seems like a pretty clunky interface. But I assume from the way that everything is spelled out explicitly that it's made to be performant. And obviously it's a big improvement over JNI.
- lichtenberger 5y agoI think the main point is accessing the foreign memory safely.
- _old_dude_ 5y agoThis is the runtime API, that uses the JITs to generate the trampoline codes necessary to go from the Java calling convention to the C calling convention (upcall and downcall), a kind of like libffi for Java. If you have a typed langages like Scala, Kotlin, Java, you can use jextract [1] which is a more high level API. jextract uses clang to parse C headers files and generates a jar file with all the C function seen as Java methods with all the glue generated for you (the downside is i believe that this jar is OS specific). This API is more for dynamic languages like Clojure, Groovy, JRuby, where you want to do dynamic runtime calls and still get performance (as far as i understand, the JIT generates the adapter code once per call and you can reuse it). [1] https://github.com/openjdk/jextract https://github.com/openjdk/jextract
- sanxiyn 5y agoYou could say this is P/Invoke for Java, which .NET had for more than a decade now. Better late than never I guess.
- royjacobs 5y agoHas P/Invoke been cross-platform for a decade? Additionally, does it parse C headers to create native type wrappers automatically? Last I checked (a long time ago), P/Invoke required you to annotate manually written prototypes?
- sanxiyn 5y agoYes, P/Invoke has been working cross-platform for a decade with Mono. Have you heard of this thing called Gtk#? P/Invoke does not parse C headers, but neither does this proposal.
- juliangamble 5y agoThis time of new Java features under Oracle is such a great contrast compared to the days of Sun as the Java Steward with no funding for features. (I understand why people might have issues with Oracle, but they provide some funding).
- cryptos 5y agoI really think that Oracle does a great job with Java! It looks like they'd have a pretty clear roadmap with what is really important for Java in the long run. Just think about virtual threads (project Loom), or values types (project Valhalla) or GraalVM. They invested many man years in each of it and take care of considering all relevant aspects. If it is done you can trust to have a proper solution. That is the kind of technology you want to build products on!
- lichtenberger 5y agoYes,the new memory model for instance for "immutable classes" for instance will be one of the biggest improvements for some applications as you can finally build cache line optimized data structures, which are for instance nowadays common in in-memory database systems. I think first considerations regarding this have been made already 10 years ago. The new upcoming (or even already in preview) language and platform features also support each other very well. I think they are heading in a clear direction with the different projects.
- adgjlsfhk1 5y agoI honestly can't tell if this is a joke or not. Valhalla is one where it was an obvious deficiency from Java 1.0, that has taken oracle about 2 decades to fix. for comparison, Microsoft was able to fix this by making "our version of Java but not completely broken" (aka C#) in less than half the time.
- pjmlp 5y agoExcept that they fully didn't, since C# 7.0, Microsoft keeps adding the System C# features into C# as means to make it more competitive with C++ workloads. Span, safe stackalloc, readonly structs, bittlable structs, native delegates,....
- vbezhenar 5y agoWhy would I use it over JNI? I used JNI few times and it was very easy and straightforward. Can I use it to call any WinAPI without C glue?
- throwawayninja 5y agoJNI => "I write C code & after compilation java can access it as com.package.ClassName" JNA => "I write java code & load libsomething at runtime, asking for FuncName(int, int) which java can then call into native code." You want JNA for your use case.
- geokon 5y agoSo what is the difference between this and JNA? I assume it's not the same since it's taking a while to be added to the language
- pie_flavor 5y agoJNI is the only escape hatch in the JRE. JNA leverages JNI and so has a better API while still keeping the terrible performance. This is like JNA, but more robust, and while also being an escape hatch of its own so that you can finally get performance similar to P/Invoke when making native calls.
- chakkepolja 5y agoThis is apparently focused on efficiently accessing off-heap memory. In Jni lot of things require copies. Only JNI API that's reliably copy-free is ByteBuffer API.
- danhau 5y agoRead under `Motivation`, I think it answers your question. Of course you can still use JNI.
- chrisseaton 5y agoJNI requires you to write your own C code to call into. I generally want to do that as little as possible, for many reasons (I’d have to build it and ship it myself.)
- ivanche 5y agoPlease note that this is only second incubator. After that will probably be third incubator, preview, second preview, maybe third preview. This will not land before Java 23 or so.
- lichtenberger 5y agoThey'll move the classes to the final packages in Java 19 :-)
- marginalia_nu 5y agoThis can't come soon enough as far as I'm concerned. Being constrained to only memory map 2 Gb chunks of memory, with no control over their lifecycle, is extremely cumbersome and arguably one of the biggest problem with Java right now.
- lichtenberger 5y agoI'll have to check how to call `madvise` to set MADV_RANDOM as index accesses in my use case are rather random, though. But the 2Gb chunks at most have been a really big issue. Luckily, the Foreign Memory API is getting to it's final version I think. The latest changes aren't that big IMHO :-)
- marginalia_nu 5y agoYeah, tell me about it. I've built a search engine index including an on-disk hash table off MappedByteBuffers. Like chopping down a tree with a pasta sieve.
- zylepe 5y agoI recently found this approach: https://github.com/onthegomap/planetiler/blob/main/planetiler-core/src/main/java/com/onthegomap/planetiler/util/Madvise.java https://github.com/onthegomap/planetiler/blob/main/planetile... but I’m hoping this api will eventually let you do that without an external dependency or writing/compiling C connectors.
- exabrial 5y agoIs that the limitation of arrays being addressed by an int instead of a long in java?
- marginalia_nu 5y agoThat is a part of it, but large arrays are also sliced up behind the scenes rather than kept as one contiguous segment of memory. This causes a fair bit of memory overhead, as there needs to be GC book-keeping for all the slices.
- deleted 5y ago[deleted]
- pie_flavor 5y agoI cannot understand why they think it is a good idea to require you to pass on the command-line the name of every module allowed to access native code. You can already do unsafe things with JNI today, that hasn't gone anywhere. And while it's much more performant than JNI was, it's still not performant enough for them to write all the syscalls in the standard library in it, unlike P/Invoke is for .NET.
- shellac 5y ago> it's still not performant enough for them to write all the syscalls in the standard library in it I'm not sure why you are inferring that. They aren't replacing openjdk vm intrinsics using this immediately, but that's hardly surprising for a brand new feature.
- pie_flavor 5y agoThe biggest features since Java 8 have been made specifically to reimplement the JRE in them, like Jigsaw. It's not unreasonable to expect it.
- samus 5y agoJNI will probably never truly die, but it's reasonable to assume that it will eventually become restricted in similar ways. The motivation is simple: applications should become the arbiters that decide which modules get to invoke native code. Libraries don't get to nilly-willy call non-Java code anymore. If, say, a dependency upgrade introduces changes that involve a new native call, it will be very noticeable.
- dehrmann 5y agoAs painful as JNI is, it means Java has Java implementations of most things (in order to avoid JNI), so builds and distribution are a lot simpler. It's pretty common for things to just work across architectures and OSes.
- resoluteteeth 5y agoOn the other hand the relative difficulty of interfacing with native code may be one factor that has, for example, allowed python and go to become much more popular than java in certain areas over the last 10 years despite java arguably being a better language.
- dehrmann 5y agoIs cython any easier than JNI?
- The_rationalist 5y ago[dead]
- gavinray 5y agoI'm waiting for Graal to release their own version of jextract that autogenerates GraalVM "@CFunction" annotations. That would be so killer. My immediate thought was it'd be cool to write something like a Postgres native extension in a JVM language, using the Graal C FFI primitives and have Graal compile it to a native shared lib.