RFR: 8173970: jar tool should have a way to extract to a directory

Jaikiran Pai jai.forums2013 at gmail.com
Thu Mar 4 02:40:40 UTC 2021


Hello Lance,

On 03/03/21 9:14 pm, Lance Andersen wrote:
>
>
> Some other things needed to be defined and agreed upon in order to 
> move forward
>
>   * The behavior if the path does not exist
>   * If the option is specified more than once on the command line
>   * Clarify the behavior if any of the files exist in the specified
>     target directory.
>
One of my previous reply included the details of how I think it should 
behave for 2 of the above cases. I'll paste that here again for easier 
visibility. As for how it should behave if the option is specified more 
than once, I'll spend some time today to see how the jar tool currently 
behaves for some of the other options in this aspect and send back my 
response. Thank you for your help so far. Pasting below my proposal from 
a previous reply for the other 2 cases:


>
> There are other discussion points around the behavior when the target 
> directory exists or does not exist, to ensure there is some 
> consistency with main stream tools.

I'm guessing you mean the behaviour of creating a directory (or a 
hierarchy of directories) if the target directory is not present? My 
testing with the tar tool (both on MacOS and CentOS) shows that if the 
specified target directory doesn't exist, then the extract fails. The 
tar extract command doesn't create the target directory during extract. 
On the other hand, the unzip tool, does create the directory if it 
doesn't exist. However, interestingly, the unzip tool creates only one 
level of that directory if it doesn't exist. Specifically, if you specify:

unzip foo.zip -d /tmp/blah/

and if "blah/" isn't a directory inside /tmp/ directory, then it creates 
the "blah/" directory inside /tmp/ and then extracts the contents of the 
zip into it.

However,

unzip foo.zip -d /tmp/blah/hello/

and if "blah/" isn't a directory inside /tmp/ directory, then this 
command fails with an error and it doesn't create the hierarchy of the 
target directories.

Coming to the jimage and the jmod commands, both these commands create 
the entire directory hierarchy if the target directory specified during 
extract, using --dir, doesn't exist. So a command like:

jimage extract --dir /tmp/blah/foo/bar/ jdkmodules

will create the blah/foo/bar/ directory hierarchy if blah doesn't exist 
in /tmp/, while extracting the "jdkmodules" image.

 From the user point of view, I think this behaviour of creating the 
directories if the target directory doesn't exist, is probably the most 
intuitive and useful and if we did decide to use this approach for this 
new option for jar extract command, then it would align with what we 
already do in jimage and jmod commands.

One another minor detail, while we are at this, is that, IMO we should 
let the jar extract command to continue to behave the way it currently 
does when it comes to overwriting existing files. If the jar being 
extracted contains a file by the same name, in the target directory 
(hierarchy) then it should continue to overwrite that file. In other 
words, I don't think we should change the way the jar extract command 
currently behaves where it overwrites existing files when extracting.

-Jaikiran



More information about the core-libs-dev mailing list