R: @chamikaramj Can you take a look?

Run JavaPortabilityApi PreCommit

Heyo -- just a quick question after thinking about this. Should I refactor the existing Read/read() transform to use this proposed ReadFiles/readFiles() ? I see that some other FileIOs do this.

If yes, how do you feel about the read().withHintMatchesManyFiles() to switch between the original read() and new readFiles() technique? I see TextIO and AvroIO do this, but I'm not sure whether this is "best practices".

It's weird to me to refactor the original read() to require a "hint" to use the new implementation, when the new implement is ... just right there below it! WDYT?

R: @pabloem

Sorry about the delay here. Pablo agreed to take over this review so passing to him.

Usually, the difference between Read and ReadFiles transforms is that, ReadFiles currently does not support dynamic work rebalancing while Read does (this will change with SDF).

I see that, for TFRecordIO, we do not support dynamic work rebalancing anyways, so refactoring Read transform to use proposed ReadFiles should be fine.

I don't think we need the hint if we use ReadFiles for both implementations.

Thanks Cham. It's useful to get your advice here : )

I've looked at the implementation, and it LGTM. @RyanSkraba let me know if you'd like to do any refactoring, or if you'd just like me to merge this.

Thanks for the review! Please go ahead and merge it -- before doing any additional internal refactoring (which wouldn't make much difference here), I'd like to take a tour around the existing file-based IOs to identify where they're consistent or different.