LazyInputStream

[cmhulbert]

concept for generating lazy input streams for ReadData that don't require materializing the backing ReadData until the first read is called

[cmhulbert]

@tpietzsch this was an attempt to avoid the need to materialize() when calling inputStream() for LazyReadData. I'd stil like to avoid that if possible. It would need some work before merging, since this is a bit outdated now (e.g. doesn't handle slice() either). but let me know your thoughts before I put more time into it.

It works by returning a Lazy InputStream that is backed by the ReadData as a delegate, and materializes only when you read from he IputStream, instead of when you create it

[tpietzsch]

I think it is a good idea, but I'm not sure where it would be actually useful currently. Do you have a concrete scenario in mind?

In terms of code, I would make the LazyInputStream independent of ReadData. I think you could just pass a Supplier<InputStream> to the LazyInputStream constructor instead. (This would make it more re-usable which we probably don't need, but the coupling to ReadData seems artificial).

[cmhulbert]

Not a specific example, I just generally think that materializing the data when we request the input stream is unintuitive for the API contract of an InputStream. Practically, It will benefi in cases where input streams are requested, but never read (though I'm not sure if that's a common use case in the current code).

I like the Supplier idea. I'll take a stab at it

[cmhulbert]

@tpietzsch it's fairly small but I'm happy to merge this whenever you get a chance to look.