Any solution intercepting the terminal operations except flatMap -based solution (as proposed by @Holger) would be fragile to the following code:

Stream<String> stream = getAutoCloseableStream(); if(stream.iterator().hasNext()) { // do something if stream is non-empty }

Such usage is absolutely legal by the specification. Do not forget that iterator() and spliterator() are terminal stream operations, but after their execution you still need an access to the stream source. Also it's perfectly valid to abandon the Iterator or Spliterator in any state, so you just cannot know whether it will be used further or not.

You may consider advicing users not to use iterator() and spliterator() , but what about this code?

Stream<String> stream = getAutoCloseableStream(); Stream.concat(stream, Stream.of("xyz")).findFirst();

This internally uses spliterator().tryAdvance() for the first stream, then abandons it (though closes if the resulting stream close() is called explicitly). You will need to ask your users not to use Stream.concat as well. And as far as I know internally in your library you are using iterator() / spliterator() pretty often, so you will need to revisit all these places for possible problems. And, of course there are plenty of other libraries which also use iterator() / spliterator() and may short-circuit after that: all of them would become incompatible with your feature.

Why flatMap -based solution works here? Because upon the first call of the hasNext() or tryAdvance() it dumps the entire stream content into the intermediate buffer and closes the original stream source. So depending on the stream size you may waste much intermediate memory or even have OutOfMemoryError .

You may also consider keeping the PhantomReference s to the Stream objects and monitoring the ReferenceQueue . In this case the completion will be triggered by garbage collector (which also has some drawbacks).

In conclusion my advice is to stay with try-with-resources.