NX Open Programmer's Guide > synthesis across What Is NX Open, Available Toolkits, Interoperation between the Common API and Open C, Wrappers

UF (Open C) vs. NXOpen — when a developer needs to drop to UF

This is a synthesis across four pages already in this knowledge base (what-is-nxopen.md, available-toolkits.md, interop_c_common.md, wrappers.md), organized to directly answer: when should a developer stay in NXOpen, and when do they need to drop to UF (the older Open C API)?

The two API families

NXOpen (the "Common API") — the object-oriented wrapper. NX requires developers to expose new features/functions to a common object model, so all Common API languages (.NET, Java, C++, Python) share the same objects, properties, methods, and class hierarchy. This is the same object model used internally by NX developers, so new NX features/functions are available for automation immediately — no lag behind interactive capability. All Common API languages are functionally equal; pick your implementation language freely.
UF / Open C (a "Classic API") — the older, direct C programming interface to NX. Over 5,000 functions ("User Functions"), naming convention UF_<application_area>_<function>, e.g. UF_MODL_create_plane(). Represents NX objects as opaque tags rather than OO objects. Classic APIs predate the Common API, are still maintained, but are no longer actively enhanced.

When to stay in NXOpen

Any time the functionality you need exists in the Common API — it is the actively developed surface and gets new NX capability first.
When you want language freedom (.NET/Java/C++/Python) without losing functionality.
When working with Block Styler dialogs, journals, or anything driven by the shared object model, since those all sit on top of NXOpen.

When you need to drop to UF

The Common API doesn't yet expose a given capability. Because Open C has ~5,000 functions accumulated over decades, some low-level or legacy functionality has no NXOpen equivalent yet.
You're maintaining/extending an existing Open C or Open C++ application — Interoperability is built in specifically for this case (see below).
Certain Open C callback functions — these are "not fully supported by the .NET UFWrapper," so if you need that kind of callback, calling the underlying UF function directly (in C++) may be unavoidable.

How NXOpen calls into UF: the Wrapper layer

The Common API guarantees access to full Open C coverage by auto-generating .NET, Java, and Python wrappers for Open C functions:

Open C modules map to classes in the Common API; functions within a module map to methods on the corresponding class.
Namespace/module structure:
- .NET: wrapped classes live in the NXOpen.UF assembly (NXOpen.UF.dll), namespace NXOpen.UF.
- Java: NXOpenUF.jar, package nxopen.uf.
- Python: NXOpen_UF.pvd extension module, NXOpen.UF module.
UFSession is the entry point to access wrapped classes. Get a UFSession instance first; each Open C module's wrapper class is exposed as a method on UFSession — e.g. .curve() returns a UFCurve instance, whose methods wrap the UF_CURVE_* functions.
NX Open for C++ can call Open C / Open C++ directly — no wrapper needed, since C++ interops natively.

Bridging tags and objects

Tag property (.NET/Python) or tag method (Java/C++) — every NX Open tagged object exposes its underlying UF tag, for passing into a wrapped (or raw, in C++) UF function.
Going the other direction (raw tag → NX Open object): use TaggedObjectManager (Java: Get method; Python: TaggedObjectManager.GetTaggedObject) or NXObjectManager (.NET: Get method).

Practical gotchas when mixing UF and NXOpen

Not every Open C function has a wrapper — see "Non-wrapped NX Open C functions" in the source book for the list of gaps.
Memory management differs: UF_free / UF_free_string_array are not needed in wrapped languages — garbage collection reclaims memory (e.g. char* results are copied into the binding's memory).
Allocating UF-wrapped structs in .NET requires explicit allocation (not an NX-Open-style constructor), e.g.:
```
point_data(i) = New UFCurve.PtSlopeCrvatr
point_data(i).point = New Double(3) {}
```
Teamcenter Integration part-name encoding: when calling a UFWrapper method for an Open C subroutine while running under Teamcenter Integration, part names must use the internal TC Integration part-name format — e.g. UFWave.CopyComponentAs (wrapping UF_WAVE_copy_component) needs both source and new part names encoded via UFUgmgr.EncodePartFilename (wraps UF_UGMGR_encode_part_filename), decoded via UF_UGMGR_decode_part_filename.
See the InteropNXOpenWithUFWrap sample at %UGII_BASE_DIR%\ugopen\SampleNXOpenApplications for worked language-specific examples.

Calling your own legacy C code (not just Open C)

If you have your own custom C program's functions you want to call from NX Open for .NET or Java (not Open C itself), the .NET Framework and JNI (Java Native Interface) both support this — you write your own wrappers for your legacy APIs, using .NET interop or JNI, exactly the same pattern NX itself uses for Open C. This interoperability approach is not recommended for NX Open Python programs outside of the Python-wrapped NX Open API itself.

Bottom line

Default to NXOpen. Drop to UF (via the generated NXOpen.UF / nxopen.uf wrapper classes accessed through UFSession, or directly in C++) only when the specific function you need has no Common API equivalent, or you must interoperate with existing Open C/legacy-C code. Bridge between the two worlds using the object's Tag and TaggedObjectManager/NXObjectManager.