A tree instance represents a snapshot of the {@link ContentRepository}tree at the time the instance was acquired from a {@link ContentSession}. Tree instances may become invalid over time due to garbage collection of old content, at which point an outdated snapshot will start throwing {@code IllegalStateException}s to indicate that the snapshot is no longer available.
Order and orderability
The children of a {@code Tree} are generally unordered. That is, thesequence of the children returned by {@link #getChildren()} may change overtime as this {@code Tree} is modified either directly or through some othersession. Calling {@link #orderBefore(String)} will persist the current orderand maintain the order as new children are added or removed. In this case a new child will be inserted after the last child as seen by {@link #getChildren()}.
State and state transitions
A tree instance belongs to the client and its state is only modified in response to method calls made by the client. The various accessors on this interface mirror these of the underlying {@code NodeState}interface. However, since instances of this class are mutable return values may change between invocations.
All tree instances created in the context of a content session become invalid after the content session is closed. Any method called on an invalid tree instance will throw an {@code InvalidStateException}.
{@link Tree} instances may become non existing after a call to{@link Root#refresh()}, {@link Root#rebase()} or {@link Root#commit()}. Any write access to non existing {@code Tree} instances will cause an{@code InvalidStateException}.
Thread safety
Tree instances are not thread-safe for write access, so writing clients need to ensure that they are not accessed concurrently from multiple threads. Instances are however thread-safe for read access, so implementations need to ensure that all reading clients see a coherent state.
Visibility and access control
The data returned by this class and intermediary objects such as are access controlled governed by the {@code ContentSession} instance from whichthe containing {@code Root} was obtained.
Existence and iterability of trees
The {@link #getChild(String)} method is special in that it neverreturns a {@code null} value, even if the named tree does not exist.Instead a client should use the {@link #exists()} method on the returnedtree to check whether that tree exists.
The iterability of a tree is a related to existence. A node state is iterable if it is included in the return values of the {@link #getChildrenCount(long)} and {@link #getChildren()} methods. An iterablenode is guaranteed to exist, though not all existing nodes are necessarily iterable.
Furthermore, a non-existing node is guaranteed to contain no properties or iterable child nodes. It can, however contain non-iterable children. Such scenarios are typically the result of access control restrictions.