We Keep Coding

How to pass a string constant as it is in powershell

I have the following simple java program:
import java.util.Arrays;
public class Arguments
{
public static void main(String [] args)
{
System.out.println("args: "+Arrays.toString(args));
}
}
When I execute this in powershell using the following command: java Arguments "*.java" the string received in the program is not "*.java" but a comma-separated list of all java files in the current directory. And if there are no java files in the current directory the string received is "*.java".
I want to know why this is happening and how to pass a string as it is without converting it.
Update: java Arguments '"*".java' and java Arguments `"*.java`" did the work but this creates the same problem when executed in cmd. Can anyone explain why this is happening? Is there any common solution for both PowerShell and cmd?

It is not PowerShell (nor cmd.exe) that interprets "*.java" as a filename pattern and expands (resolves) it to the matching files, known as globbing in the Unix world.
(You would only get that behavior if you used *.java - i.e., no quoting - in PowerShell Core on Unix-like platforms, but never with a quoted string such as "*.java" or '*.java', and even without quoting never on Windows).
Apparently, it is legacy versions of java.exe on Windows that automatically perform the globbing on unquoted arguments, in an apparent attempt to emulate the behavior of POSIX-like shells such as Bash on Unix.
As of (at least) JDK 12, this behavior no longer seems to be effect, at least not by default.
The linked answer suggests that in earlier versions there may be a system property that controls the behavior, but it's unclear what its name is.
Generally, the syntax java -D<systemPropName>=<value> ... can be used to set a system property on startup.
Therefore, you have the following options:
Upgrade to a Java version that no longer exhibits this behavior (by default).
In legacy versions, find the relevant system property name that disables the behavior and use the syntax shown above.
Use shell-specific quoting, as shown below.
Using quoting to prevent globbing:
To prevent java.exe from performing globbing, the invocation command line must ultimately contain "*.java", i.e., the argument must be enclosed in double quotes.
Unfortunately, there is no common syntax that works in both PowerShell and cmd.exe:
cmd.exe:
cmd.exe passes double-quoted arguments through as-is, so the following is sufficient:
java Arguments "*.java"
PowerShell:
PowerShell, by contrast, performs re-quoting as needed behind the scenes (see this answer for more information).
Since an argument with content *.java normally does not require quoting when you pass it to an external program, PowerShell translates both "*.java" and '*.java' to unquoted *.java in the command line that is ultimately used behind the scenes - which is what you experienced.
There are two ways around that:
Use java Arguments '"*.java"', i.e., embed the " chars. in the argument, inside a literal string ('...').
Use java Arguments --% "*.java"; --% is the stop-parsing symbol (PSv3+), which instructs PowerShell to pass the remainder of the command line through as-is (except for expanding cmd.exe-style environment-variable references).

How to use jps -Joption

I really can't figure out how to use jsp -Joption. I got description as followed,
OPTIONS
The jps command supports a number of options that modify the output of the command. These options are subject to change or removal in the
future.
-q Suppress the output of the class name, JAR file name, and arguments passed to the main method, producing only a list of
local VM identifiers.
-m Output the arguments passed to the main method. The output may be null for embedded JVMs.
-l Output the full package name for the application's main class or the full path name to the application's JAR file.
-v Output the arguments passed to the JVM.
-V Output the arguments passed to the JVM through the flags file (the .hotspotrc file or the file specified by the
-XX:Flags=<filename> argument).
-Joption Pass option to the java launcher called by javac. For example, -J-Xms48m sets the startup memory to 48 megabytes. It is a
common convention for -J to pass options to the underlying VM executing applications written in Java.
Actually, I don't know what is a java launcher called by javac, and when I run the example jps -J-Xms48m just as same using jps. So, what this option for? Thanks.

Java development tools like jps, jstat, jstack, jmap etc. are all written in Java. Just like regular Java programs they require Java Runtime Environment, i.e. they run under JVM.
-J options do not affect jps tool directly, but they rather affect the JVM which runs this tool. E.g. -J-Xms48M option means that jps will launch Java Virtual Machine with the initial heap size of 48 Megabytes.
For example, compare jps -J-XX:+PrintGCDetails and jps -J-Xms48M -J-XX:+PrintGCDetails

Is it possible to "fool" java that an environment variable is set from the command line

I'm running in an environment where I can pass parameters but not set environment variables using a normal commandline.
I would like to set environment variables nevertheless. Is there an alternative way to "fool" java that an environment variable is set, e.g. using -D parameters?
(I'm running spark in oozie through hue; all in the Cloudera stack).

The java command itself doesn't seem to allow that. It has a -D parameter, but that sets Java 'system properties':
$ java -help 2>&1 | grep -A1 '\-D'
-D<name>=<value>
set a system property
Java system properties are a sort of Java properties. Like environment variables, java properties are key-value pairs, but aren't the same thing as environment variables: If your Java application reacts to a specific environment variable, setting a system property of the same name won't have any effect unless the application explicitly reacts to that property, too.
If your environment allows you to run arbitrary Java applications and if it allows your Java applications to execute other processes, you can write a little wrapper that sets the environment variables on a ProcessBuilder (see the question Arnon linked in his comment: How do I set environment variables from Java?) to then invoke java with your actual JAR from it. You could either hard-code the environment variables to set, or set them according to system properties the wrapper receives. (Or you could even implement your own shell in Java and pass a script to it.)
Though, if you can modify the source of that actual JAR, a much more idiomatic solution would be to make it itself react to properties instead of (or additionally to) environment variables. (Unless you have to control environment variables that the java command / the JVM reacts to rather than the JAR you'd like to run. Then this approach would not be applicable, of course.)

If you can run arbitrary Java code, you can create and run a Process using ProcessBuilder, including an environment of your choice.
Hence, write a java program that parses a command-line like
java -cp .... your.Prog FOO=BAR BAZ=BOOM command arguments ...
and starts command with the environment extended by FOO and BAZ
(Note that command could be java ...)

get JAVA_OPTS at runtime

My app is deployed on Tomcat and I've configured the JAVA_OPTS environment variable in /etc/default/tomcat7.
There seem to be a million different places where these variables can be provided to Tomcat, so I want to check that the values I'm providing are what's actually being used. Is there something I can inspect at runtime to determine the value of this variable. I checked System.getProperties(), but it doesn't seem to be there.

If you're looking for just the property overrides and JVM arguments, you can use RuntimeMXBean:
RuntimeMXBean mxBean = ManagementFactory.getRuntimeMXBean();
System.out.println(mxBean.getInputArguments());
For example, running with the following command-line:
java -Xms512m -Xmx1024m -Dtest.prop=foo com.example.sandbox.RuntimeMXBeanExample
I get the following output:
[-Xms512m, -Xmx1024m, -Dtest.prop=foo]
Note that this does not include arguments passed to the main() method.

You can use System.getenv("JAVA_OPTS") as suggested.
If you don't want to modify code than you can use some of those methods
Java Tools
jps -v displays Java processes with arguments
jvisualvm connects to Java process and let's you inspect number of properties including MXBeans
GNU/Linux tools
ps e displays environment variables passed to processes

One important thing, although post is old. Whatever variable you are passing it should be before the class name you are executing else it will be ignored.
Below will work:
Example: java -classpath . -Dformat=xls -DTabname=\"Base data new\" com.cg.bench.GenerateReport
Below will NOT work:
WRONG Example: java -classpath . com.cg.bench.GenerateReport -Dformat=xls -DTabname=\"Base data new\"

Java path problems on Cygwin

I'm trying to compile a Java project under Cygwin using a native Win32 Java.
The Java binaries are correctly found under /cygdrive/c/jdk/bin on my machine.
The following command works fine:
javac -d . ./gnu/kawa/util/PreProcess.java
The PreProcess.class file is generated in ./gnu/kawa/util/. Trying to invoke Java on this fails however:
CLASSPATH=.:$CLASSPATH java gnu.kawa.util.PreProcess \
%java6 +use:com.sun.net.httpserver +enable:XML \
`sed -e 's|\([^ ]*\)|./\1|' < ./patch-source-list`
Error: Could not find or load main class gnu.kawa.util.PreProcess
...
This command was invoked by make, that's where the $CLASSPATH variable is set dynamically. patch-source-list is just a list of class names. The : in the classpath looks suspicious, but I'm not sure how to test ; while not annoying sh.
My only other suspicion is that the native Java is trying gnu\kawa\util\PreProcess, but I think cygwin can transparently handle that.
Any ideas? Thanks for your time.

Another option would be to build your path using the ':' and then fix the results using cygpath. This is probably overkill in your specific situation, but in a general case where you may have references to multiple directories, some of which may be referenced as absolute rather than relative paths, or if you are working with cygwin symlinks, it is much more useful.
$ ln -s /cygdrive/c/development/libraries/ ../libs
$ cygpath -pw /cygdrive/c/development/:.:../libs
C:\development\;.;C:\development\libraries\
so then you'd build your CLASSPATH variable as before, and in the final stage run
CLASSPATH="`cygpath -pw "$CLASSPATH"`" java (whatever)

Remember, the JVM has no idea that you are using the cygwin bash shell.
Two things:
for the classpath locations, use the windows path names. Thus, no "/cygdrive/c/somepath", but "c:\somepath\" ("/" and "\" can be used interchangeably however)
use ';' instead of ':' in the classpath list
This should work:
export CLASSPATH="./gnu/kawa/util/PreProcess.class"
CLASSPATH=".;$CLASSPATH" java gnu.kawa.util.PreProcess

The : in the classpath looks suspicious, but I'm not sure how to test ; while not annoying sh.
You're exactly right: you need to use ; instead of :. As for how to use it — as Mat alludes to above, you need to "quote" the semicolon. Any of these will work:
CLASSPATH=.\;$CLASSPATH java Foo
CLASSPATH=.';'$CLASSPATH java Foo
CLASSPATH='.;'$CLASSPATH java Foo
CLASSPATH=".;$CLASSPATH" java Foo
You can use whichever one you like best. (The first uses a backslash, which quotes a single following character. The second and third use single-quotes, which quote a sequence of zero or more characters. The fourth uses double-quotes, which are like single-quotes except that they still allow the variable $CLASSPATH to be expanded. For that matter, you could also write something like
CLASSPATH=".;"$CLASSPATH java Foo
if you want. See the above link for lots more information about quoting in Bash.)