Editing Comparison of C Sharp and Java (section)

=== Native interoperability ===
{| class="wikitable" style="width:80%;"
|-
! style="width:40%;"| Native interoperability !! style="width:30%;"|Java !! style="width:30%;"|C#
|-
|[[Cross-language interoperability]] || {{yes}} (with [[GraalVM]], [[Nashorn (JavaScript engine)|Nashorn]], [[CORBA]], [[JNI]] or [[Java Native Access|JNA]])<ref name="cross-plattform" /> || {{yes}}; C# was designed for it<ref name="cross-plattform">{{cite web |url=http://www.25hoursaday.com/ |title=A Comparison of Microsoft's C# Programming Language to Sun Microsystems' Java Programming Language: C. An Ever So Slight Feeling of Dèjà Vu: 15. Cross Language Interoperability |author=Dare Obasanjo |year=2007 |publisher=Dare Obasanjo |archive-url=https://web.archive.org/web/20120919093308/http://25hoursaday.com/ |archive-date=19 September 2012 |quote=There are a number of ways cross language interoperability works in Java. First of all, there is the Java Native Interface (JNI) … Java also has the ability to interact with distributed objects that use the common object request broker architecture (CORBA) via Java IDL. … C# and the .NET runtime were created with seamless cross-language interoperability as a design goal. |access-date=10 September 2012 |url-status=dead |df=dmy-all}}</ref>
|-
|External/native methods || {{yes}} || {{yes}}
|-
|[[Marshalling (computer science)|Marshalling]] || {{no|External glue code needed}} || {{yes}}; metadata controlled
|-
|[[Pointer (computer programming)|Pointers]] and arithmetics || {{no}}; but see [http://mishadoff.com/blog/java-magic-part-4-sun-dot-misc-dot-unsafe/ sun.misc.Unsafe] || {{yes}}
|-
|Native types || {{yes}}<ref>{{cite web |url=https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/types.html |title=JNI Types and Data Structures |publisher=Docs.oracle.com |access-date=9 April 2020}}</ref> || {{yes}}
|-
|Fixed-size buffers || {{no}} || {{yes}}
|-
|Explicit stack allocation || {{no}} || {{yes}}
|-
|Address-of || {{no}} || {{yes}}
|-
|[[Object pinning#Moving vs. non-moving|Object pinning (fix variable to address)]] || {{no}} || {{yes}}
|-
|Function pointers || {{no}} || {{yes}}<ref>{{cite web |url=https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-9#performance-and-interop |title=Function pointers in C# 9 |publisher=docs.microsoft.com |access-date=27 February 2021}}</ref>
|-
|Unions || {{no}} || {{yes}}<ref>{{cite web |url=https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/attributes/how-to-create-a-c-cpp-union-by-using-attributes |title=Creating C/C++ unions in C# |publisher=docs.microsoft.com |access-date=27 February 2021}}</ref>
|}

The [[Java Native Interface]] (JNI) feature allows Java programs to call non-Java code. However, JNI does require the code being called to follow several conventions and imposes restrictions on types and names used. This means that an extra adaption layer between legacy code and Java is often needed. This adaption code must be coded in a non-Java language, often C or C++. [[Java Native Access]] (JNA) allows easier calling of native code that only requires writing Java code, but comes at a performance cost.

In addition, third party [[Library (computing)|libraries]] provide Java-[[Component Object Model]] (COM) bridging, e.g., JACOB ([[Free software|free]]), and J-Integra for COM ([[Proprietary software|proprietary]]).

.NET Platform Invoke ([[Platform Invocation Services|P/Invoke]]) offers the same ability by allowing calls from C# to what Microsoft terms un[[managed code]]. Through metadata attributes the programmer can control exactly how the parameters and results are [[Marshalling (computer science)|marshalled]], thus avoiding the external glue code needed by the equivalent JNI in Java. P/Invoke allows almost complete access to procedural APIs (such as Win32 or POSIX), but limited access to C++ class libraries.

In addition, .NET Framework also provides a .NET-COM bridge, allowing access to COM components as, if they were first-class .NET objects.

C# also allows the programmer to disable the normal type-checking and other safety features of the [[Common Language Runtime|CLR]], which then enables the use of [[Pointer (computer programming)|pointer variables]]. When using this feature, the programmer must mark the code using the {{mono|unsafe}} keyword. JNI, P/Invoke, and "unsafe" code are equally risky features, exposing possible security holes and application instability. An advantage of unsafe, managed code over P/Invoke or JNI is that it allows the programmer to continue to work in the familiar C# environment to accomplish some tasks that otherwise would require calling out to unmanaged code. An assembly (program or library) using unsafe code must be compiled with a special switch and will be marked as such. This enables runtime environments to take special precautions before executing potentially harmful code.