Many Java applications require the environment variable
JAVA_HOMEto be set appropriately to work correctly. In PowerShell, you can check the setting of a particular environment variable with the command
echo $env:JAVA_HOME. An example of this is shown in the next screen snapshot (click on image to see larger version).
Another environment variable that is often useful to note when using Java is any CLASSPATH setting. This can be checked with the
echo $env:CLASSPATHcommand. If the CLASSPATH environment variable is set, it will be displayed. What if you wanted to set your classpath for use in Java applications rather than passing the classpath to the application with the Java launcher? In that case, you could set CLASSPATH with the command
$env:CLASSPATH = "<<someClassPath>>".
The quotation marks are significant in setting the classpath because the semicolon (
;) is still used to separate class path entries. Because the semicolon also tells PowerShell that a command is being terminated and another started, this must be in quotation marks to avoid the classpath being treated as two separate statements.
The classpath can also be set on the command-line in conjunction with the Java launcher with a command like:
java -cp "<<someClassPathEntry>>;<<anotherClassPathEntry>>" <<package>>.<<classToRun>>(again, as with setting the CLASSPATH environment variable, quotations should be used around the entire classpath entry so that the semicolon is not treated as a statement terminator). A concrete example of this is shown next:
java -cp "C:\NetBeansProjects\SpringJmxExample\build\classes;C:\spring-framework-2.5.1\dist\spring.jar;C:\spring-framework-2.5.1\lib\jakarta-commons\commons-logging.jar" marx.SpringJmxMain
The take-aways from all of this include the following:
- Although many Unix-isms can be used in PowerShell, one should still use the semicolon for classpath separators as described in the Windows Setting the Class Path document rather than with colons for Unix as documented in the Solaris Setting the Class Path document.
- PowerShell does recognize semicolons as statement terminators for placing multiple statements on the same line. This very Unix-like feature means that class path values must be surrounded in quotes so that multiple entries can be separated with semicolons without making PowerShell think there are multiple statements on the line.
- Although PowerShell "feels" much more like Unix than DOS, it still supports DOS operations and the semicolon and backwards slashes in the examples above shown that this is the same as in DOS as well. That being said, I can also use more Unix-like syntax and have it work as well. The command shown above could also be run as follows:
java -cp "/NetBeansProjects/SpringJmxExample/build/classes;/spring-framework-2.5.1/dist/spring.jar;/spring-framework-2.5.1/lib/jakarta-commons/commons-logging.jar"
The above command will behave exactly as the one shown above, but without the DOS-obvious
C:\drive syntax and the backwards slashes.
- It is not shown above, but you can find out more about using PowerShell environment variables by running the command
help env) in the PowerShell terminal window.
When specifying Java system properties on the command line in PowerShell, you need to put quotation marks around the these specifications so that the
-Dis not interpreted prematurely. The next screen snapshot shows running Java with the
-Dsystem properties options without quotes and the error that follows. The same screen snapshot then shows how it runs successfully if double quotes are used around the
You can run the
java -versioncommand in PowerShell just as you would in DOS or Unix/Linux. The next screen snapshot demonstrates this.
Similarly, you can run other Java executable tools in the same way you'd run them in DOS or in Unix/Linux. The next screen snapshot shows the command-line view of running these in PowerShell.
PowerShell brings each of us a more "natural" Java development command-line experience if we've developed Java primarily in a Unix/Linux environment in the past.
It is not as easy as I would have expected to find good blogs and articles on using Java with PowerShell. This may be due somewhat to the chasm that often seems to exist between the Windows community and Java or other non-.NET communities. Here are some interesting links related to using Java with PowerShell: