R.D. wrote:
I still don't care much about loading time. Not for 10kb image or anything. IOUtils sure is fast but... I load anything on startup anyway.
I agree with Nitram on loading speeds -- we should be as efficient as possible, and try to make Slick usable for "big games."
As for IOUtils, it is no faster than the current implementation in AngelCodeFont/PackedSpriteSheet/HieroSettings -- it uses the same file reading method, and would only exist for a design perspective. In that sense I agree with Nitram -- it makes more sense to have a "single source of responsibility" which is why I originally brought up the idea of IOUtils.
Nitram, my reasoning for your IOUtils being "overkill"...
Methods like "copyLarge" or "closeQuietly" are user-specific and not needed by Slick. Simply because we have an IOUtils class doesn't mean we should try to encompass everything the user may potentially desire; e.g. for the same reason that we don't include a StringUtils class in Slick. Users can easily implement these on their own, and using their own methods (e.g.
Java 7 file IO).
I also don't agree with unnecessary method overloading, IMO this falls under "trying to encompass every possible need of the user":
Code:
public static String toString(final URI input, final String charsetName)
throws IOException {
return toString(input.toURL(), charsetName);
}
I'm not trying to attack you Nitram -- I just don't agree on all points.

I would be in favour of a small IOUtils class that is consistent with Slick's "baby Java" coding style and creates a single point of responsibility for file reading.