[
https://issues.apache.org/jira/browse/COMPRESS-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15432962#comment-15432962
]
Gary Gregory commented on COMPRESS-365:
---------------------------------------
Instead of a big-bang patch for the whole component, I would suggest to create
a subtask for each file type and see if this can be done is smaller chunks.
> Use java.nio.file.Path instead of java.io.File
> ----------------------------------------------
>
> Key: COMPRESS-365
> URL: https://issues.apache.org/jira/browse/COMPRESS-365
> Project: Commons Compress
> Issue Type: Improvement
> Reporter: Ben Butler-Cole
>
> When testing code that does file I/O it is faster and provides better
> isolation to use an in-memory filesystem. The standard way of doing that is
> to use the java.nio.file package for all file I/O and provide an in-memory
> implementation of java.nio.file.FileSystem (for example Jimfs
> (https://mvnrepository.com/artifact/com.google.jimfs/jimfs)).
> Unfortunately it's impossible to do this if code anywhere in the stack
> converts back to java.io.File. So it's currently impossible to use Commons
> Compress with an in-memory filesystem. To enable this there would need to be
> java.io.file.Path versions of all API methods that currently take
> java.io.File objects and the implementation would need to be changed to use
> java.nio.file classes throughout.
> I can see that this is a fair bit of work (although when I've done similar
> conversions it's been fairly easy to drive by leaning on the IDE and type
> system). But you would get big implementation advantages from doing this
> because java.nio.file makes lots of things easy that are tedious with java.io
> and provides more safety around fallible operations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
