Cannot pass strings with spaces to JVM arguments

[markwoon]

I've tried all manner of escapes in an effort to use spaces in parameters passed to JVM Options and nothing seems to work.

Example:

<key>JVMOptions</key>
<array>
<string>-Dcom.apple.mrj.application.apple.menu.about.name=&quot;Hello World&quot;</string>
</array>

Which just leads to Error: Could not find or load main class Hello.

Everything works as expected if I just remove or replace the space between Hello and World.

[tofi86]

yep, you're right, that's not working at the moment. sorry.

however, for this specific option, you can set

<key>CFBundleName</key>
<string>Hello World</string>

in your Info.plist file.

[tofi86]

Probably related to changes made in 9587c16 following #1
Will investigate...

[Artoria2e5]

            ${JVMOptions:+$JVMOptions }\
            ${JVMDefaultOptions:+$JVMDefaultOptions }\
            ${JVMMainClass}\
            ${JVMArguments:+ $JVMArguments}

This sloppy quoting breaks things. Consider switching to #!/bin/bash and using arrays.
Actually this script is already using bash things like [[ -- it should be #!/bin/bash anyway.

For this particular example,

yourstr='-Dcom.apple.mrj.application.apple.menu.about.name="Hello World"'
frag(){
  printf 'We got a fragment: %q\n' "$@"
}
frag ${yourstr:+$yourstr }

[tofi86]

@Arthur2e5 you're right with #!/bin/bash, thanks for the hint!

However, I need to digg deeper in the quote escaping issue with your example function, so give me some time for this...
Pull requests are welcome at any time as well ;-)

[Artoria2e5]

Yeah, I am not actually sure about how the stub actually parses JVMOptions. My current guess is something like string joining (with "<array elem>"?) and system, which would be eval in shell script… (I don't think they want to use some shell tokenizers to deal with things like $JAVA_HOME manually)

I don't have access to any OS X systems unfortunately, and I am currently too lazy to pick up anything like Hopper. May I ask @markwoon to actually try it with Oracle's Stub, with and w/o "?

A fake java executable that prints out all the arguments might be useful:

#!/bin/bash
printf '%q \\\n' "$0" "$@" >&2
# exec original-java-path "$@"

[karlvr]

This issue also occurs if the application bundle lives in a folder containing a space in it. This occurs for me when trying to launch from the disk image, which contains a space in the name.

I'm investigating a solution.

[karlvr]

I've confirmed that this is exactly the same problem; just the JVMOptions, which are problematic as they contain an $APP_PACKAGE replacement. It appears that the expected ways of escaping those isn't working for me. I've tried \ing the spaces, and sticking the $APP_PACKAGE in ""s...

[tofi86]

@Azhrei came up with a quick 'n dirty solution for this in #40:

I have a Plist file in which the $JAVAROOT value will contain spaces. Unfortunately, when the properties are eval'd to replace variable values, they don't have the correct quotes added around them so they'll work on the eventual command line.

Thinking about this, I decided adding double quotes was the wrong solution anyway (well, thinking about it AND doing some testing). What if the user put double quotes in their pathname to the app? Yeah, I know they shouldn't, but USERS don't know they shouldn't. (Sigh.)

So I came up with the following snippet for the JVMOptions variable, around line 171 in the latest version.
JVMOptions=`$PL -c "print ${JavaKey}:Properties" "${InfoPlistFile}" 2> /dev/null | while read a b c; do [[ "$b" == '=' ]] && echo -n "-D$a=$(eval printf "%q" "$c") " ; done`

Since that code contains the eval, be sure to comment out the following line that does eval echo ... (it's no longer needed).

Closed #40 as duplicate in favor of this thread but cross-posted his solution for easier handling over here...

Sorry guys for not finding a good solution to solve this with 2.0 lately. Will take another attempt soon...

[Azhrei]

Well, the better solution is to define shell functions to accomplish some of this so that the code isn't inlined, thus making the script easier to read and modify, but also allowing individual functions to be tested separately. I'll do that at some point. In fact, my immediate deadline is past, so I might work on this more today and tomorrow...

What I appreciate most, @tofi86, is the work you did to ferret out the issues involved in making this work in the first place! That's been my stumbling block for a long time. Now it's just a matter of implementing the solution in the best possible way, and that kind of coding is my forté. 😄

What are your feelings about updating working code to use newer idioms? Like changing out backtics to use $() instead? If I make those changes and put them in a pull request, would that be acceptable?

Thanks again!

[tofi86]

What I appreciate most, @tofi86, is the work you did to ferret out the issues involved in making this work in the first place!

Thanks! 😊

What are your feelings about updating working code to use newer idioms? Like changing out backtics to use $() instead? If I make those changes and put them in a pull request, would that be acceptable?

Yeah, sure, sounds very good! We should use whatever bash has to offer in the meantime. However, we should keep an eye on older Mac OS X versions as we probably have users running Java 6 apps on older systems. So we should check for Bash compatibility up to - let's say - OS X 10.6 (Snow Leopard)...

[Azhrei]

Ah, good point. Stuff like $() is POSIX (and has been for a long time) so I can't imagine a problem there, but the [[ ]] stuff wasn't POSIX, then it was, and then it wasn't again! Probably best not to change that one without plenty of testing. :)

I'll see about creating a VM with Snow Leopard to test against, since I don't have any machines in my office that old that are still running...

[rambaut]

Hi, I see this issue is still open and it is causing me a few problems. I wish to include JAVAROOT as the java.library.path property (I have some JNI libs there).

JarBundler creates:

      <dict>
        <key>java.library.path</key>
        <string>$JAVAROOT</string>
        <key>apple.laf.useScreenMenuBar</key>
        <string>true</string>
      </dict>

Which then comes up against the issue with the spaces in the path.

If I edit universalJavaApplicationStub to have:

	exec "$JAVACMD" \
			-cp "${JVMClassPath}" \
			-splash:"${ResourcesFolder}/${JVMSplashFile}" \
			-Xdock:icon="${ResourcesFolder}/${CFBundleIconFile}" \
			-Xdock:name="${CFBundleName}" \
			${JVMOptions:+$JVMOptions }\
			-Djava.library.path="${JAVAROOT}" \
			${JVMDefaultOptions:+$JVMDefaultOptions }\
			${JVMMainClass}\
			${JVMArguments:+ $JVMArguments}\

it works fine.

Note the explicit -Djava.library.path with ${JAVAROOT} in quotes.

As the postings above suggest, there doesn't seem to be away to get these quotes to come through from the Info.plist.

@tofi86, I am just posting this to keep the issue live. I very much appreciate the work you have done on this project.

[Azhrei]

That works for you, but if the JAVAROOT variable is empty, it will fail (for everyone else that doesn't use the variable). However, if you replace that line with this it will work for everyone:

${JAVAROOT+"-Djava.library.path=$JAVAROOT"}

That variable substitution uses something called a parameter expansion modifier (technically it should be a parameter substitution modifier, but the legacy term is typically used). It says that if the JAVAROOT variable has something stored in it, do a substitution but don't use the variable's value; instead, use the contents of the double-quoted string that follows. And that string contains the command line option you need. Since it's inside quotes, the spaces inside the variable will be preserved.

I will make this change and it will probably get into the imminent 1.4.1.8 build. Thanks for the suggestion!

[rambaut]

Thanks. I wasn't suggesting I had a general solution, just one I could use in my application.

I am not sure your solution would be general either because most people wouldn't want to set java.library.path or may wish to set it to something else (I think JAVAROOT will always be set).

Perhaps JVMOptions variable needs to be parsed for java.library.path (possibly other properties?) and the path quoted?