Package nxopen.features (Java)

Java counterpart of NXOpen::Features (C++) — read nxopen-cpp-reference/features-namespace.md for the full Feature+Builder pattern explanation, sub-package list, and builder catalog. This file records only what is Java-specific.

Verification

The Java nxopen.features package page confirms the same object model: Feature (base interface), ExtrudeBuilder, RevolveBuilder, FeatureCollection, and the full Hole family — Hole, HoleFeatureBuilder (with nested HoleFeatureBuilder.HoleSubtype), HolePackage / HolePackageBuilder (with nested CounterBoreDepthLimitOptions, HoleDepthLimitOptions, HoleDepthOptions, HoleForms, Holesize, Holetype), FillHole / FillHoleBuilder (nested BorderContinuity, ContinuityTypes, ShapeControlTypes), and ResizeHole / ResizeHoleBuilder — all present and matching the C++ reference's class set. The package page itself is large (2200+ linked members counting nested types and cross-references), consistent with the 751-759-class scale reported in the other language bindings.

Java-specific idiom: nested option/enum types

Where C++ often uses separate top-level enum types, Java's Javadoc nests many builder option enums directly inside their owning builder interface (e.g. HoleFeatureBuilder.HoleSubtype, HolePackageBuilder.Holetype). This is consistent with the nested-callback-interface pattern documented in blockstyler-namespace.md in this folder — Java favors nesting tightly-scoped types inside their owner rather than a flat namespace.

Java interfaces vs. C++/.NET classes

As with nxopen.blockstyler, the Java binding declares Feature, builders, and collections as interfaces rather than concrete classes (the implementing classes are internal to the NXOpen Java runtime). Code always programs against the interface type (e.g. nxopen.features.ExtrudeBuilder), obtained via factory methods on FeatureCollection or a domain-specific collection — same acquisition pattern as C++/.NET.