Does the stream.spliterator() close the stream?

Terminal operations never close the stream. Closing has to be done manually. The only place where automatic closing happens is within the flatMap operation, where manual closing of the substreams usually created on-the-fly would be somewhere between hard and impossible.

This also applies to the Stream.spliterator() method. In your examples, it makes no difference because the streams created via Stream.of(…) do not need to be closed and have no onClose() operation registered by default.

You have to consult the documentation of the factory methods to find out when a stream need to be closed. E.g. like Files#lines(Path, Charset).

See also Does collect operation on Stream close the stream and underlying resources? or Does Java 8 Stream.iterator() auto-close the stream when it's done?

The call to spliterator() method returns a Spliterator for the elements of this stream and its a terminal operation.

To answer your question - No, the spliterator method or for that sake none of the other terminal operations also does not close the stream.

This stands documented for terminal operations as -

After the terminal operation is performed, the stream pipeline is considered consumed, and can no longer be used.... In almost all cases, terminal operations are eager, completing their traversal of the data source and processing of the pipeline before returning. Only the terminal operations iterator() and spliterator() are not; these are provided as an "escape hatch" to enable arbitrary client-controlled pipeline traversals in the event that the existing operations are not sufficient to the task.

Over closing the Stream on another hand the docs state that:-

Most stream instances do not actually need to be closed after use, as they are backed by collections, arrays, or generating functions, which require no special resource management. Generally, only streams whose source is an IO channel, such as those returned by Files.lines(Path), will require closing.

---

The AutoCloseable states to match to it-

It is possible, and in fact common, for a base class to implement AutoCloseable even though not all of its subclasses or instances will hold releasable resources.

which is how the BaseStream extends it and the close() doesn't impact far more than the streams over the ones using the resources such as Files.lines(...).

However, when using facilities such as Stream that support both I/O-based and non-I/O-based forms, try-with-resources blocks are in general unnecessary when using non-I/O-based forms.

Nothing changed concerning the closing of Streams in Java 9. You still need to manually do it if the underlying resource should be freed. You should never rely on the garbage collector to do it. The docs still say:

Streams have a BaseStream.close() method and implement AutoCloseable. Operating on a stream after it has been closed will throw IllegalStateException. Most stream instances do not actually need to be closed after use, as they are backed by collections, arrays, or generating functions, which require no special resource management. Generally, only streams whose source is an IO channel, such as those returned by Files.lines(Path), will require closing. If a stream does require closing, it must be opened as a resource within a try-with-resources statement or similar control structure to ensure that it is closed promptly after its operations have completed.