Created attachment 546 [details] gluegen debug output We have a customer that have installed our game in the I:\#SPIELE\ folder on his windows computer. Our game is not able to load the joal native libraries because of this exception (it's the same for the other native libraries): java.lang.IllegalArgumentException: URI has a fragment component at java.io.File.<init>(Unknown Source) at com.jogamp.common.util.IOUtil.toURL(IOUtil.java:534) at com.jogamp.common.util.JarUtil.getJarFile(JarUtil.java:454) at com.jogamp.common.util.cache.TempJarCache.addNativeLibs(TempJarCache.java:211) at com.jogamp.common.jvm.JNILibLoaderBase.addNativeJarLibsImpl(JNILibLoaderBase.java:196) at com.jogamp.common.jvm.JNILibLoaderBase.addNativeJarLibs(JNILibLoaderBase.java:368) at com.jogamp.common.os.Platform$1.run(Platform.java:197) at java.security.AccessController.doPrivileged(Native Method) at com.jogamp.common.os.Platform.<clinit>(Platform.java:173) at com.jogamp.openal.ALFactory.<clinit>(ALFactory.java:67) at com.daysofwonder.gamelib.OpenALSoundEngine.initOpenAL(OpenALSoundEngine.java:133) at com.daysofwonder.gamelib.OpenALSoundEngine.init(OpenALSoundEngine.java:217) at com.daysofwonder.application.GameApplication.startAudio(GameApplication.java:150) at com.daysofwonder.tt.application.TTApplication.start(TTApplication.java:306) at com.daysofwonder.tt.application.TTApplication.main(TTApplication.java:752) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.exe4j.runtime.LauncherEngine.launch(Unknown Source) at com.exe4j.runtime.WinLauncher.main(Unknown Source) at com.install4j.runtime.launcher.WinLauncher.main(Unknown Source) We might be missing a kind of urlencode somewhere. I've added the whole gluegen debug output, too.
Evaluated behavior on GNU/Linux and WIndows. - 'new File(path_with_#)' fails on both platforms - 'new URL(path_with_#)' and subsequent JARFile loading: - UNIX OK - Windows ERROR gluegen commit 4c835f0337674a0181c43f448d44d961e27b2f54 uses uri.getPath() and decodes it explicitly leading to a unified behavior, i.e.: - UNIX ERROR - Windows ERROR In short: We cannot support a '#' in URI/URL since it denominates a fragment and using such fails within the URI/URL implementation itself. Iff we fix this - we would need to overhaul all URI usage, probably utilizing a different implementation, e.g. <http://jena.sourceforge.net/iri/documentation.html>.
We had problems with these characters: $ ^ ~ # [ ] I'm checking about the specifics of them, whether they were the same issue, etc.
Specifically, we had the jar files in directories named "R$", "R^", "R#", "R[", and "R]". I don't know whether there are other combinations of these that would be bad. Just that someone tested installing into directories with these characters in the name, and had problems.
0b07f9107c5b033913f5c4cbeb906ae6dafc2d77 Fix URI/URL double encoding, ensuring encoded/decoded variants are used properly (Added unit test) Bug 908 was caused by confusing URI encoded parts (e.g. scheme-specific-part) and it's decoded variant. This especially happened due to: - the fact, that the encoded and unencoded variant uses the same String type, - the URI/URL decoding differs, is not complete (e.g. %20 .. SPACE remains in decoded part), - and does not comply w/ RFC 2396 and RFC 3986 (encoding), e.g. not all RESERVED chars are encoded. In branch 'v2.3.0_branch', we will introduce our own Uri and Uri.Encoded class to solve above issue by replacing all URI usage w/ Uri, see Bug 1063 - Backporting results of own Uri class introduction in branch 'v2.3.0_branch' - Ensure the encoded URI parts are used where required, i.e. IOUtil.compose(..) etc - TestNetIOURIReservedCharsBug908: Automated test, launching GlueGen jar file from an <i>odd pathname</i>.