In Blueprints, we used to have CloseableIterable, which allowed users to release resources that might have been held by the underlying graph database. We didn't port that interface to TinkerPop 3.x for some reason. Graphs like OrientDB require a close() method for iterators returned from methods like Graph.vertices() and Graph.edges(). In addition, allowing close() from those iterators would make the close() on Traversal (non-remote) more useful and meaningful (right now it is an empty method by default).
In Blueprints, Graph.getVertices() and Graph.getEdges() returned a Iterable and the Graph could choose to return CloseableIterator. Users who wanted to write provider agnostic code would then have to do:
I'm not sure why we didn't simply return CloseableIterable from those methods. Any reason we shouldn't do that now? Perhaps the approach is to introduce CloseableIterator to 3.2.4, but keep the return type of edges/vertices() as Iterator and then for 3.3.0 change the return type to CloseableIterator. In this way, the feature can be available in next release of 3.2.4 without any API changes and users can do the instanceof check above if they need to. Then for 3.3.0 when we allow API changes we can just make it more convenient with a CloseableIterator return type.