java - Encoding Path to URI behaves differently when built into JAR or not -

i have call hashmap's containskey method expect return true. returns true if compile program .class files , run that, if build jar same call returns false reasons cannot comprehend.

i've debugged both .class , jar versions (the jar using remote connection described in http://www.eclipsezone.com/eclipse/forums/t53459.html ) , in both cases hashmap appears contain key i'm trying check.

the hashmap uses uri objects keys. here contents of variables shown in each debug session:

when run .class file

hashmap key: java.net.uri = file:/e:/ssd%20app%20libraries/google%20drive/programming/bet%20matching/java%20sim/target/classes/simfiles/paytables/

uritocheck: java.net.uri = file:///e:/ssd%20app%20libraries/google%20drive/programming/bet%20matching/java%20sim/target/classes/simfiles/paytables/

result: gametreeitemsmap.containskey(uritocheck) true

when run jar

hashmap key: java.net.uri = jar:file:/e:/ssd%20app%20libraries/google%20drive/programming/bet%20matching/java%20sim/out/artifacts/javasim_jar/java%20sim.jar!/simfiles/paytables/

uritocheck: java.net.uri = jar:file:///e:/ssd%2520app%2520libraries/google%2520drive/programming/bet%2520matching/java%2520sim/out/artifacts/javasim_jar/java%2520sim.jar!/simfiles/paytables/

result: gametreeitemsmap.containskey(uritocheck) false

i expect method return true in both cases. uris somehow behave differently inside jar? what's going on?

thanks in advance help!

edit 1 pointed out me, uritocheck in jar case being double encoded (%2520 instead of %20). here's code generates uritocheck. use walkfiletree method.

        files.walkfiletree(paytablehomepath, new simplefilevisitor<path>(){             @override             public filevisitresult previsitdirectory(path dir, basicfileattributes attrs) {                  path parentpath = dir.getparent();                  uri parenturitocheck = parentpath.touri();                  boolean testcontain = gametreeitemsmap.containskey(parenturitocheck);                  return filevisitresult.continue;             } 

in jar case, uri parenturitocheck double encoded (with %5250 space there should %20) , in .class case not happen. idea why?

this has nothing hashmap. appears you've found bug in java's zip file system provider, namely converts path doubly-encoded uri.

i can't find existing bug it, i've submitted one. (there this related bug, fix suspect cause of one.) update: java bug 8131067.

here's program wrote demonstrate problem, in java 1.8.0_45-b14. pass .jar file 1 or more spaces in path first command line argument.

import java.util.map; import java.util.collections; import java.net.uri; import java.io.ioexception; import java.nio.file.filesystem; import java.nio.file.filesystems; import java.nio.file.path; import java.nio.file.paths;  public class jarpathtest {     public static void main(string[] args)     throws ioexception {          path zip = paths.get(args[0]);          uri zipuri = uri.create("jar:" + zip.touri());         system.out.println(zipuri);          map<string, string> env = collections.emptymap();          try (filesystem fs = filesystems.newfilesystem(zipuri, env)) {             path root = fs.getpath("/");             system.out.println(root.touri());         }     } } 

you can work around treating decoded uri if it's still percent encoded:

parenturitocheck = uri.create(     parenturitocheck.getscheme() + ":" +     parenturitocheck.getschemespecificpart());