In the software development world, it’s a common thing to reuse existing bits of other programs, and libraries even if they were written in different programming languages. Java and its ecosystem aren’t the exceptions, for decades Java developers using the technology available out of the box known as Java Native Interface (JNI) - communication interfaces that bind C/C++ native code to Java applications. Despite seeing JNI too often in many software solutions based on Java and C code at the same time, it still has disadvantages like an extensive toolkit (C/C++ compiler, system header files, etc.) making Java applications fragile to C/C++ errors that may put down the whole JVM.

Project Panama aimed to be a successor to JNI by providing clear APIs that help to bind native code to Java applications without involving a native compiler. It allows Java developers to focus on writing Java code instead of dealing with C/C++ most of the time. In this talk, we will go through almost every aspect of Project Panama related to writing C applications in Java and will do a deep dive into C Application Binary Interface (C ABI) as a core technology behind Project Panama as well as JDK foreign function infrastructure components. We also will cover the first standalone JDK code-generating tool and how to build a Java library for your favorite C/C++ library.

Key takeaways for attendees:
1.    JNI is no longer the only JDK technology to build a bridge between Java and native code.
2.    JDK is capable to work with most existing OS platforms and architectures.
3.    Foreign Function & Memory API is the implementation of C ABI.
4.    Native code invocation infrastructure code in Java must be optimized for the best performance. 
5.    How jextract can speed up the development.
6.    What are the Project Panama limitations?
7.    What’s the state of C++ support?
8.    How to build, package, and release Java library out of C library.