Rather than reimplementing a flatmap here (next we'll be implementing map and filter), why not user StreamSupport and the Iterable interface to convert the Iterator into a Stream?

Iterators::transform and Iterators::filter already exist.

1. Iterable implies that we can produce multiple iterators by calling Iterable::iterator several times. We don't want to make that claim.
2. Stream is considerably heavier than Iterator. I'm very much in favor of Stream becoming more common in our code, but when we need only a very tight set of operations (and the majority of uses of flatMap are either alone or with a filter or two) it's not clear to me that it's worth the overhead in code or execution.

I'm not saying we shouldn't ever make Streams at a low level, but I am saying that we shouldn't always make Streams at a low level. Fundamentally, Stream represents a computation, but Iterator represents a flow of elements, and that's really what we have here.

The history for this class has been lost. Instead, you should use:
git mv

I do not believe that git mv will preserve the history of this class. Git uses its own heuristic for determining whether a file has been deleted and added somewhere else (e.g. a simple "move") or whether a newly added file is a truly different thing (e.g. a delete and an unrelated addition). If you look at the implementation of SkolemNodeRdfContext, it shares very few similar lines with BlankNodeRdfContext. So, even with git mv, that history is not necessarily going to be saved. The only sure way to keep that history is to rename the file but keep the implementation basically intact (as much as possible) in one commit. In a subsequent commit (that does not get squashed) the implementation can be changed to reflect the Java8 idioms as expressed here.

Personally, I'm not convinced that doing this simply to preserve the history (first a rename with minimal changes to the file followed by a subsequent, more substantive reimplementation) is worth the effort.

I would be very surprised (although happy to be proven wrong) to see that git mv did not save the history in this case. Have you tested your theory, @acoburn?

I have encountered similar issues at other times, when a file is renamed and changed substantially. The issue is this: git tracks content, not files.

Thanks for the link, @acoburn.
http://article.gmane.org/gmane.comp.version-control.git/217