We Keep Coding

Why System.getProperties() returns null for -D defined property?

I'm running a jarball using
java -classpath myBatch.jar some.package.MyMainClass \
-bloodyArgument "I got the argument!" -Dbloody.prop="I got the prop!"
Then in my main I have:
Properties argsProps = BatchUtils.argsToProperties(args);
System.out.println(argsProps.getProperty("bloodyArgument"));
System.out.println(System.getProperty("bloody.prop"));
And I get output:
I got the argument!
null
I can see the command line bloodyArgument (I added it to see if "something" gets passed to the program), but I'd expect the -D argument to set the system property. Why is the "bloody.prop" null?
PS: BatchUtils.argsToProperties() does what you'd expected it to do: parse -argName "value" from command line into argName=value property pair.

Everything after the class argument of java command gets passed to your main in String[] args and doesn't make it to the JVM.
The solution was to rearrange the properties like this:
java -classpath myBatch.jar -Dbloody.prop="I got the prop!" \
some.package.MyMainClass -bloodyArgument "I got the argument!"
I didn't find this anywhere explicitly stated when waddling the web with http://duckduckgo.com or googling this queation of "null -D defined property". I figured it a lot later when printing all system properties and the whole arguments array, so am posting for others.

Pass shell script argument containing spaces as java system property

Have a shell script which, in turn, run a java program.
The script is invoked as follows :
./script.sh 1 2 3 4 "ab cd"
The 5th shell argument (ab cd) must be passed as a a java system property, what I'm doing is this :
JAVA_OPTS="-Xmx512M -Dlog4j.defaultInitOverride=true"
if [ "$5" ] ; then
JAVA_OPTS="$JAVA_OPTS -Dconfig.path=$5"
fi
Then, run java (JAVA_EXE & CP have proper values) :
$JAVA_EXE $JAVA_OPTS -classpath $CP com.foo.Main
Receiving this error :
Error: Could not find or load main class cd
If passing "abcd" instead of "ab cd" everything is ok.
If passing inline, just surround the value with quotes :
java -Xmx512M -Dconfig.path="ab cd" com.foo.Main
The problem occurs when a variable must be used.
How should I pass the argument containing spaces correctly ?

Instead of building JAVA_OPTS as a string, you can build it as an array:
JAVA_OPTS=(-Xmx512M -Dlog4j.defaultInitOverride=true)
if [ "$5" ] ; then
JAVA_OPTS+=("-Dconfig.path=$5")
fi
"$JAVA_EXE" "${JAVA_OPTS[#]}" -classpath "$CP" com.foo.Main
(Note: the Bourne shell did not have arrays, and POSIX does not require shells to support them, so this approach is not maximally portable. If you use this approach, make sure the first line of your script is something like #!/bin/bash or #!/bin/zsh and not something like #!/bin/sh.)

The only solution I found is to use a special variable for the problematic param
CONFIG_PATH="-Da=a"
if [ "$5" ] ; then
CONFIG_PATH=-Dconfig.path=$5
fi
$JAVA_EXE $JAVA_OPTS "$CONFIG_PATH" -classpath $CP com.foo.Main
It must have some value, otherwise the empty value will be taken as the name of the main class.

$JAVA_EXE $JAVA_OPTS -classpath $CP com.foo.Main MUST be $JAVA_EXE "$JAVA_OPTS" -classpath $CP com.foo.Main - Pay attention to the double quotes around $CP
EDIT: JAVA_OPTS="$JAVA_OPTS -Dconfig.path=$5" should also be JAVA_OPTS="$JAVA_OPTS -Dconfig.path='"'$5'"'"

Passing pre-escaped command-line arguments to ProcessBuilder

I bumped into this problem today when setting up a local set of communicating programs. Basically one of my applications is sending some data to another, and part of this data is a string containing a command to execute (like you would from the command-line). Let's say, for example:
g++ foo.cc bar.cc -o foobar
is the command sent by my first application. The second application, which receives the command (amongst other things), needs to execute this command after doing some other processing.
Now, at first I thought this would be trivial using a ProcessBuilder:
String exampleCommand = "g++ foo.cc bar.cc -o foobar";
ProcessBuilder builder = new ProcessBuilder(exampleCommand);
builder.start().waitFor();
However this is where the problem occurs.
CreateProcess error=2, The system cannot find the file specified
Okay, no worries I guess I can't just dump the whole thing into the builder. The first part of the command is usually a trivial string so I thought I could probably get away with a split around the first ' ' to separate the program name and arguments.
String exampleCommand = "g++ foo.cc bar.cc -o foobar";
String[] parts = exampleCommand.split(" ", 2);
ProcessBuilder builder = new ProcessBuilder(parts[0], parts[1]);
builder.start().waitFor();
And this brought me a little closer, the g++ file could now be found correctly, however after examining the stderr of g++ I found that the following error had occurred:
g++.exe: error: foo.cc bar.cc -o foobar: No such file or directory
At this point I realised that the ProcessBuilder class must be escaping all arguments passed to it in preparation for the command-line (hence the reason it usually takes arguments as an array of individual arguments rather than just a predefined argument string).
My question is, "Is there any way to pass a raw string of arguments to a ProcessBuilder and say THERE, execute EXACTLY this?"
Because the command comes from another application and is in no way static I can't just break the arguments down into an array beforehand and pass them to the ProcessBuilder constructor properly. The arguments are not so trivial that simply splitting the string around a ' ' will work properly either; arguments might contain spaces escaped with double quotes. For example:
g++ "..\my documents\foo.cpp" bar.cpp -o foobar
Could be a command coming from the application and splitting that string around ' ' and passing it to the ProcessBuilder will result in corrupt arguments.
If there is no proper way to do this can someone please point me to a standalone command line argument parser (in Java) that can turn a command-line string into a valid String[]?

Okay I feel rather foolish now but I achieved my desired result by simply reverting back to the good old Runtime.getRuntime().exec(...). I'll leave the question up in case anyone is as silly as me and find it useful.
String exampleCommand = "g++ foo.cc bar.cc -o foobar";
Runtime sys = Runtime.getRuntime();
sys.exec(exampleCommand);
Easy.

A comment to the Runtime.getRuntime().exec(...) solution:
The Runtime.getRuntime().exec(...) is not good anymore. In java executed on OSX El Capitan, 'Runtime.getRuntime().exec(...)' contains an error that sometimes closes the opened process when the java program exits. It works fine on previous OSX versions. However, ProcessBuilder works on all OSX versions.
(Haven't posted enough to have a enough rep points to make this as a normal comment.)

Standard error not getting redirected from this java command in bash

I have the following shell script. For some reason the java program's standard error and standard output is not printed to the file "log" but instead always appear in the console. Is there a type some where or am I missing something?
JAVACMD="java -XX:+HeapDumpOnOutOfMemoryError -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=19000 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Xss128k -Xmx700m -jar program.jar >log 2>&1 "
echo "Starting server...";
$JAVACMD&

Regrettably, you will have to use eval if you want to keep the redirection operators in the string value.
Like other shell-special characters, redirection operators are only evaluated if they are not quoted. When you expand the JAVACMD parameter it will split on whitespace, but it will not re-evaluate any special characters it includes. Using eval forces this re-evaluation.
The problem with eval is it forces every character be re-evaluated. In your case, none of the other characters will have any untoward affects. If your string value contained some other shell-special character (e.g. ;(){}…) that you did not want the shell to re-evaluate you would have to escape/quote it inside the string value so that eval would not give it a special meaning.
⋮
eval "$JAVACMD &"
To avoid problems with eval, I suggest moving the redirection out of the string value:
JAVACMD="… program.jar"
⋮
$JAVACMD >log 2>&1 &
Done this way the only characters in the string value that you need to watch out for are the whitespace characters (e.g. if you needed some embedded whitespace in one of the options/arguments; if you run into this you might consider using an array variable or "$#" (a singular, array-like variable available in all Bourne-like shells)).

Have you tried:
JAVACMD="java -XX:+HeapDumpOnOutOfMemoryError -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=19000 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Xss128k -Xmx700m -jar program.jar"
echo "Starting server...";
$JAVACMD >log 2>&1 &
The redirections are considered as arguments to the java command as they are contained in the variable.

You can't actually stick redirections in a variable like that and expect bash to accept them. Simple example:
tesla:~ peter$ ECHOCMD='echo > log 2>&1'
tesla:~ peter$ $ECHOCMD
log 2>&1
I.e. your redirection indicators are becoming simple arguments, passed to your java invocation.
One workaround is to say eval $JAVACMD but it won't make your script any cleaner.

Space in Java command-line arguments

In my Java command-line arguments, any characters after space get ignored. For example,
java test.AskGetCampaignByName "Dummy books"
I get the first argument (args[0]) as "Dummy" only. Single quotes also do not help.
Is there a workaround/fix for this? Could it be because of my terminal settings?
My $TERM is xterm, and $LANG is "en_IN".

The arguments are handled by the shell (I assume you are using Bash under Linux?), so any terminal settings should not affect this.
Since you already have quoted the argument, it ought to work. The only possible explanation I can think of is if your java command is a wrapper script and messes up the escaping of the arguments when passing on to the real program. This is easy to do, or perhaps a bit hard to do correctly.
A correct wrapper script should pass all its arguments on as ${1+"$#"}, and any other version is most likely a bug with regards to being able to handle embedded spaces properly. This is not uncommon to do properly, however also any occurrences of $2 or similar are troublesome and must be written as "$2" (or possibly ${2+"$2"}) in order to handle embedded spaces properly, and this is sinned against a lot.
The reason for the not-so-intuitive syntax ${1+"$#"} is that the original $* joined all arguments as "$1 $2 $3 ..." which did not work for embedded spaces. Then "$#" was introduced that (correctly) expanded to "$1" "$2" "$3" ... for all parameters and if no parameters are given it should expand to nothing. Unfortunately some Unix vendor messed up and made "$#" expand to "" even in case of no arguments, and to work around this the clever (but not so readable) hack of writing ${1+"$#"} was invented, making "$#" only expand if parameter $1 is set (i.e. avoiding expansion in case of no arguments).
If my wrapper assumption is wrong you could try to debug with strace:
strace -o outfile -f -ff -F java test.AskGetCampaignByName "Dummy books"
and find out what arguments are passed to execve. Example from running "strace /bin/echo '1 2' 3":
execve("/bin/echo", ["/bin/echo", "1 2", "3"], [/* 93 vars */]) = 0
brk(0) = 0x2400000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f420075b000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f420075a000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib64/alliance/lib/tls/x86_64/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/alliance/lib/tls/x86_64", 0x7fff08757cd0) = -1 ENOENT (No such file or directory)
open("/usr/lib64/alliance/lib/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
...

In case your program needs more than positional arguments (= when the command line usage is important), you should consider options and switches. Apache Commons has a great library for this.

You just have to escape the spaces like this:
normal String: "Hello World!"
escaped String: "Hello" "World!"
That worked for me.
My environment:
23:39:19 Zarathustra#thora:/Users/Zarathustra~$bash -version
GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin11)
Copyright (C) 2007 Free Software Foundation, Inc.

It sounds like you are using a operating system distribution where the java command available to the user is a wrapper which finds the right JVM "somewhere" and invokes it accordingly.
If so, it most likely does not escape the arguments properly when invoking the actual java executable.
What distribution do you use?

Just reassemble the arguments in your Java program:
StringBuilder allArgs = new StringBuilder();
for (int i=0; i < args.length; i++)
{
//System.out.println("arg"+i+": "+args[i]);
allArgs.append(args[i]+" ");
}
// Parse out the args the way you wish using allArgs