As a general rule, when there are no constructors, look for static factory methods, most IDEs show them when writing the class name (or typically you autocomplete it after few letters) and then a dot. Most of the “newer stuff” in the SDK uses static factory methods, whenever possible (I have forgotten it a few times).

Instances of UaNodeId are obtained via static factory methods. The methods for converting NodeIds and ExpandedNodeIds are:

UaNodeId.fromLocal(ExpandedNodeId)
UaNodeId.fromLocal(ExpandedNodeId, NamespaceTable)
UaNodeId.fromLocal(NodeId, NamespaceTable)

Get the NamespaceTable via client.getNamespaceTable(). The version without it is only for cases where the ExpandedNodeId has the uri and not the index.

UaNodeId.fromStandard(NodeId) works only for NodeIds of the base, standard, namespace (with index 0, as it’s uri is known and it is always index 0).

The “intended to be used” method … could maybe do some improvements, but is:

UaNodeId from(String namespaceUri, Object value)

It behaves like UaNodeId from(String namespaceUri, Object value) constructor does, i.e. value must be UnsignedInteger, String, UUID or ByteString. We probably should add some helpers in some future version like UaNodeId.numeric etc. to fix the type in the signature.

P.S.

For reasons, see e.g. https://www.baeldung.com/java-constructors-vs-static-factory-methods

So basically the static factory methods might return an existing instance (if it is equal to the given data) and/or a subtype of UaNodeId (we could save memory e.g. via https://refactoring.guru/design-patterns/flyweight, but I will skip details) . Like technically for the most parts that is not yet used, but we can do so in the future without breaking the API (could not do that with constructors, as they must always return a new instances and instance of that exact class).

P.S.2
And SDK-reasons (prev was “java-reasons”) is that NodeId should “never be used”, as the index is only constant for an NamespaceUri within a scope of a single Session (e.g. server can change it at will on e.g. a restart). ExpandedNodeId has the problem that it can be local or remote and have uri or index, so it is impossible to properly .equals it, without the context of NamespaceTable (since other could have index and other could have uri), so ExpandedNodeId should also not be used. OK, local ExpandedNodeIds should not have uri, but back in the days we ended up needing to use the uri-form in e.g. our Codegen (as NodeIds obiviously could not be used). Thus, to solve this issue we made UaNodeId (and UaExpandedNodeId and UaQualifiedName) as a better alternative that wont suffer from this problem (always local, always has uri). Thus most “new API” tries to use UaNodeId+UaQualifiedName as much as possible (this is more seen in PubSub configuration API)