Concise File mapping handling with FileUtils.map()

[leventov]

In three places (now):

• https://github.com/metamx/java-util/blob/3c7b49c91ae178825965694111ab846d459c0d7c/src/main/java/com/metamx/common/io/smoosh/FileSmoosher.java#L301
• https://github.com/druid-io/druid/blob/078de4fcf9402c5cc13c0aabf2753b5712e84ddf/indexing-hadoop/src/test/java/io/druid/indexer/updater/HadoopConverterJobTest.java#L367
• https://github.com/druid-io/druid/blob/76e77cb61030fa78ef47e5e47f67751a73ffed1c/processing/src/main/java/io/druid/segment/StringDimensionMergerV9.java#L297

Take advantage of metamx/java-util#51

This task is blocked by #3479 or until java-util is merged into Druid.

/cc @cheddar

[Shimi]

@leventov Is this ticket still relevant?

[leventov]

There are still some places in tests and benchmarks where Files.map() call could be replaced with FileUtils.map().

[Shimi]

thanks @leventov
I made the changes to VSizeSerdeBenchmark. Except for the benchmarks, all places require write access and FileUtils.map() map the files as read-only.
If I understand it right the main motivation for this ticket (according to metamx/java-util#50 (comment)) is to control the release of the memory and not leave it for the GC. I wonder if it's important for the benchmarks since the GC will release the memory when the benchmark ends.

[Shimi]

hi @leventov
just making sure you saw the comment above

[leventov]

Feel free to submit a PR.

I don't think it's very important for the benchmark performance, but I think it's a good idea to follow the right pattern everywhere, including tests, in the spirit of the broken windows theory.

[Shimi]

Hi @leventov
I submitted PR for all the readonly cases #6692