Aforeign function interface (FFI) is a mechanism by which a program written in oneprogramming language can call routines or make use of services written or compiled in another one. An FFI is often used in contexts where calls are made into a binarydynamic-link library.

The term comes from the specification forCommon Lisp, which explicitly refers to the programming language feature enabling for inter-language calls as such;^{[1][citation needed]} the term is also often used officially by theinterpreter andcompilerdocumentation forHaskell,^[2]Rust,^[3]PHP,^[4]Python, andLuaJIT (Lua).^{[5][6]: 35 [7]} Other languages use other terminology:Ada haslanguage bindings, whileJava hasJava Native Interface (JNI),Java Native Access (JNA), or since Java 22,Foreign Function and Memory API. Foreign function interface has become generic terminology for mechanisms which provide such services.

The primary function of a foreign function interface is to mate the semantics andcalling conventions of one programming language (thehost language, or the language which defines the FFI), with the semantics and conventions of another (theguest language). This process must also take into consideration theruntime environments andapplication binary interfaces of both. This can be done in several ways:

• Requiring that guest-language functions which are to be host-language callable be specified or implemented in a particular way, often using a compatibilitylibrary of some sort.
• Use of a tool to automaticallywrap guest-language functions with appropriateglue code, which performs any necessary translation.
• Use of awrapper library
• Restricting the set of host language abilities which can be used cross-language. For example, C++ functions called from C may not (in general) include reference parameters or throw exceptions.

FFIs may be complicated by the following considerations:

• If one language supportsgarbage collection (GC) and the other does not; care must be taken that the non-GC language code does nothing to cause GC in the other to fail. In JNI, for example, C code which "holds on to" object references that it receives from Java must communicate this information successfully to theJava virtual machine orJava Runtime Environment (JRE), otherwise, Java may delete objects before C finishes with them. (The C code must also explicitly release its link to any such object once C has no further need of that object.)
• Complicated or non-trivial objects or datatypes may be difficult to map from one environment to another.
• It may not be possible for both languages to maintain references to the same instance of a mutable object, due to the mapping issue above.
• One or both languages may be running on avirtual machine (VM); moreover, if both are, these are often different VMs.
• Cross-languageinheritance and other differences, such as betweentype systems or betweenobject composition models, may be especially difficult.

Many FFIs can be generated automatically: for example,SWIG. However, in the case of anextension language a semantic inversion of the relationship of guest and host can occur, when a smaller body of extension language is the guest invoking services in the larger body of host language, such as writing a small plugin^[8] for GIMP.^[9]

Some FFIs are restricted to free standingfunctions, while others also allow calls of functions embedded in an object or class (often calledmethod calls); some even permit migration of complex datatypes or objects across the language boundary.

In most cases, an FFI is defined by ahigher-level language, so that it may employ services defined and implemented in alower-level language, typically asystem programming language likeC orC++. This is typically done to either accessoperating system (OS) services in the language in which the OS API is defined, or for performance goals.

Many FFIs also provide the means for the called language to invoke services in the host language also.

The term foreign function interface is generally not used to describe multi-lingual runtimes such as the MicrosoftCommon Language Runtime, where a commonsubstrate is provided which enables any CLR-compliant language to use services defined in any other. (However, in this case the CLR does include an FFI,P/Invoke, to call outside the runtime.) In addition, many distributed computing architectures such as theJava remote method invocation (RMI), RPC,CORBA,SOAP andD-Bus permit different services to be written in different languages; such architectures are generally not considered FFIs.

There are some special cases, in which the languages compile into the same bytecode VM, likeClojure andJava, as well asElixir andErlang. Since there is no interface, it is not an FFI, strictly speaking, while it offers the same functions to the user.

• Language interoperability
• Interface definition language
• Calling convention
• Name mangling
• Application programming interface
• Application binary interface
• Comparison of application virtual machines
• SWIG
• Remote procedure call
• libffi

• c2.com: Foreign function interface
• Haskell 98 Foreign Function Interface
• Allegro Common Lisp FFI

• Application programming interfaces
• Subroutines

• Articles with short description
• Short description matches Wikidata
• All articles with unsourced statements
• Articles with unsourced statements from December 2022