Project Panama: Interconnecting JVM and native code
We are improving and enriching the connections between the Java TM virtual machine and well-defined but “foreign” (non-Java) APIs, including many interfaces commonly used by C programmers.
To this end, Project Panama will include most or all of these components:
- native function calling from JVM (C, C++), specifically per JEP 191
- native data access from JVM or inside JVM heap
- new data layouts in JVM heap
- native metadata definition for JVM
- header file API extraction tools (see below)
- native library management APIs
- native-oriented interpreter and runtime “hooks”
- class and method resolution “hooks”
- native-oriented JIT optimizations
- tooling or wrapper interposition for safety
- exploratory work with difficult-to-integrate native libraries
This Project is sponsored by the Hotspot Group.
- Mailing lists
Project Panama is designed to incubate a series of components for eventual inclusion in the JDK, via curated merge. Following the experience of Project Lambda, we have our own tree of repositories that parallel the structure of JDK 9. Although this process is local and subject to change, we expect that typical moves will be as follows:
- Commit rough changesets to JDK and/or JVM code, with ad hoc review, change set format, and testing. (Rough changeset example from Project Lambda)
- Frequently (goal is nightly), perform private regression tests.
- Periodically (goal is weekly), resync from JDK 9 master and rebase pending (incubated) changes. (Resync example from Project Lambda)
- Periodically (goal is weekly), make private builds, marking
with distinguished tags like
- Create and update JIRA sub-issues to informally manage features
by parts, using labels like
9-repo-panamaas needed to mark private changes to incubated code.
- Infrequently, create a “curated” change set targeted at JDK; properly review, test, integrate. (Curated changeset example from Project Lambda)