After seeing this post I started looking at the Java Portable Launcher and discovered that if I Drag&Dropped a .jar file to JavaPortableLauncher.exe it would work perfectly, but if I told C.A.F.E. Mod aka eXpresso to open .jar files with the Java Portable Launcher then double clicked on one, it would tell me that the file couldn't be found.
So I checked what was different about how the Drag&Drop method worked, how CAFE ran it. I found that when Drag&Dropping It was running "X:\PortableApps\JavaPortableLauncher\JavaPortableLauncher.exe" P:\ath\to\file.jar, and when using CAFE It was running "X:\PortableApps\JavaPortableLauncher\JavaPortableLauncher.exe" "P:\ath\to\file.jar".
Looking into the JavaPortableLauncher.nsi file I thought I found the culprit:
Line 121: Exec `"$PortableAppsPath\CommonFiles\Java\bin\javaw.exe" -Duser.home="$EXEDIR\Data\AppData" -jar "$JarPath"`
Now, normally this is what you want, but when your $JarPath already includes quotes they double up, so it was trying to execute "X:\PortableApps\CommonFiles\Java\bin\javaw.exe" -Duser.home="X:\PortableApps\JavaPortableLauncher\Data\AppData" -jar ""P:\ath\to\file.jar"", now it makes sense that it's not working.
So, the problem now is how to fix this?
Should there be a check to see if there are quotes in $JarPath or not, add/delete them, then run it, or should the launcher try it with quotes, and if it doesn't work try it without quotes (or vice versa), any other suggestions?
I later discovered the issue is that ${FileExists} can't handle quotes, and have posted proper information including a fix in This Comment
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
Double quotes shouldn't be passed to the launcher. Windows does not pass them, so a utility should not either. Sounds like a CAFE bug. I've added it to the todo list for the Java Portable Launcher to double-check, but we have a lot of other updates that take priority.
Sometimes, the impossible can become possible, if you're awesome!
While Windows does not always pass them (e.g. the example I gave previously) the launcher should still be able to handle them, as Windows will pass them if there is a space in the directory.
For example, if I move my file.jar from
"P:\ath\to\file.jar"to"C:\Documents and Settings\3D1T0R\Desktop\file.jar"then it launches as"X:\PortableApps\JavaPortableLauncher\JavaPortableLauncher.exe" "C:\Documents and Settings\3D1T0R\Desktop\file.jar"which also produces the problem.I am glad to hear that it has been added to the todo list, but I think the Community at large (at least those who are able) should attempt to help out in cases like this, and unfortunately I haven't found a solution that works yet, so maybe others can make suggestions or do some testing.
Thank You.
~3D1T0R
I've looked into this more and it appears that I was wrong, JavaPortableLauncher is not trying to run it with a doubley double quoted
$JarPath, I think the error is in the way it checks to see if the file exists (i.e.${FileExists}) and the easiest way to fix it is to trim off the double quotes if they're there.I found a nice function called GetInQuotes on the NSIS Wiki and it works if you paste the function at the end of
JavaPortableLauncher.nsiand inPush $JarPath Call GetInQuotes Pop $R0 ; = quotes ${If} $R0 != "" StrCpy $JarPath $R0 ${EndIf}between lines
112&113But looking at other PortableApps launcher sources I see that this kind of function is generally put in a seperate
.nshfile and given a macro so it can be used like${GetInQuotes} $JarPath, so I'm going to see if I can do something like that.~3D1T0R
This is fixed in jPortable Launcher 2.0. The app can now handle paths with and without quotes and will properly pass that onto the JRE.
Sometimes, the impossible can become possible, if you're awesome!
Man, I sat down last night and put the
GetInQuotesfunction into a.nshfile with!macros and!defines and everything to call it the way everything else is, and I made a.difffile so it'd be easy for you to just drop in my changes and have it work, then while I was writing the comment to post it in (and changes to my Opening Post) I noticed it was almost1:30AM& decided it could wait a day, then I login tonight, and you've already done it … & you did it in a more efficient manner as well.I don't know whether to be displeased that my fix that I worked on will never see the light of day,
or happy to see a better fix reach the public.
Either way it's fixed, and that's a good thing.
Thank You John.
~3D1T0R