I am trying to use a class into a jar using a Nashorn Shebang script with the -cp option (java version "1.8.0_31"). However it does not works. I have perform some test. The following shebang line works:
#!/usr/bin/jjs -scripting
#!/usr/bin/jjs -fv (returns nashorn full version 1.8.0_31-b13)
while the following not:
#!/usr/bin/jjs -cp ./some/lib/lib.jar will return the following error message: "-cp ./some/lib/lib.jar" is not a recognized option.
#!/usr/bin/jjs -scripting -fv will return the error message: "-scripting -fv" is not a recognized option. Use "-h" or "-help" to see a list of all supported options"
All options are theoretically valid. The classpath option should also works as seen on http://www.adam-bien.com/roller/abien/entry/setting_the_classpath_for_nashorn .
More info about nashorn and Shebang: http://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn/shell.html#CHDEGHJJ
You ran into an issue which doesn’t have anything to do with Nashorn nor Java. According to this answer the command line argument handling with shebang never was clearly specified and it seems to be a common behavior to treat everything encountered after the first white-space as one single argument.
So one solution would be to write a shell script containing an invocation of jjs with the actual arguments and use that shell script as the interpreter in the shebang line of your Nashorn script.
You can use -Dnashorn.args=-cp in a shebang script. See also https://bugs.openjdk.java.net/browse/JDK-8072138
As it appears you want a way to automatically add JARs to your classpath, I'll highlight a little wrapper I've written which allows you to define Maven co-ordinate dependencies (including transitives) to be added to the classpath of your script, so you can write a script using the "# dep" lines:
#!/usr/bin/env jjs-with-deps
#
# The line below is parsed by the jjs-with-deps script to build a new
# classloader in which the script is really executed, including logback
# and its transitive dependencies.
#
# dep:ch.qos.logback:logback-classic:1.1.2
var log = org.slf4j.LoggerFactory.getLogger("com.example.app.Logger");
log.info("Hello World!");
It does require Maven to be installed somewhere on your PATH, and it does slightly increase startup time (but then again, you're already starting up a JVM ;). First invocation of a given script will be much slower while any dependencies are downloaded to the local M2 repository.
Link is https://github.com/stevestorey/jjs-with-deps
Related
I am trying to run a Java application which has many dependencies. In the past I have use the following command to launch the application
java -cp "program.jar:jar1.jar:jar2.jar:jar3.jar:[...]" program
However as the list of dependencies have grown, I have moved them into an arguments file, the contents of this file are:
-cp "\
program.jar:\
jar1.jar:\
jar2.jar:\
jar3.jar:\
[...]"
And I am running the application with
java #arguments-file program
Everything up to this point works fine.
Sometimes I end up with beta versions of program.jar, they share all of the same dependencies, but program.jar is renamed program-beta.jar.
So to run the jar the following command would be used
java -cp "program-beta.jar:jar1.jar:jar2.jar:jar3.jar:[...]" program
or more specifically, I would use an environment variable, so that the same script can be used, and the variable would be set to either program.jar, or program-beta.jar, depending on the circumstance
java -cp "$PROGRAM_JAR:jar1.jar:jar2.jar:jar3.jar:[...]" program
Now that I am using an arguments file I was hoping to be able to be able to do something like:
java -cp "$PROGRAM_JAR" #arguments-file program
However using -cp twice causes one of the two to be ignored, resulting in a java.lang.ClassNotFoundException exception.
Is there any way around this that allows me to specify one jar file by name, but abstract away all of the others so that my java command isn't thousands of characters?
This will be running entirely on Linux, so any command line "magic", such as using grep is fine, so long as the resulting code is easily readable
You could just write two bash scripts production.sh and beta.sh that contain a reference on program.jar and program-beta.jar, respectively.
Also, the classpath can contain wildcards (see man-page), so if you can ensure that on disk exists only one of the two versions, you can write it like this:
java -cp "program*:jar1.jar:jar2.jar:jar3.jar:[...]"
In the long term, you might think about building/running it with Maven or Gradle, depending on your requirements.
I want to use an environment variable as a JVM option when executing java -jar.
The command I want to execute it:
java -XX:onOutOfMemory='echo test' -jar foo.jar
When I run the above command as is, the jar will run.
(If you don't have the foo.jar, you will get an Error: Unable to access jarfile foo.jar error. But this still means that the option gets used correctly).
But when I create an environment variable containing the JVM option, and run the command using that variable.
OOM="-XX:onOutOfMemory='echo test'"
java $OOM -jar foo.jar
Than I get the following error:
Error: Could not find or load main class test'
It seems like the java command is ignoring the quotes around 'echo test'.
After looking for similar questions on SO and on other websites, I tried various variations of using quotes:
OOM="-XX:OnOutOfMemoryError=\"echo test\""
OOM='-XX:OnOutOfMemoryError="echo test"'
OOM=-XX:OnOutOfMemoryError="echo test"
But they all result in the same error.
An article from Oracle concerning JVM options, mentions using a semicolon:
-XX:OnOutOfMemoryError="<cmd args>; <cmd args>"
But the purpose of the semicolon is to separate multiple commands, not command and arguments. So this does not fix my problem.
Does anybody know how I can correctly move the -XX:onOutOfMemory='echo test' option into an environment variable?
When running java, you should quote $OOM
Example:
java "$OOM" -jar foo.jar
See Why does my shell script choke on whitespace or other special characters? on Unix stackexchange for why this is needed.
I am using Jenkins CI to run java from execute shell build step :
java -jar -Dadmin.hostname=$hostname -Dschema_name=$schema myapp.jar
I have noticed that although both parameters hostname and schema are defined well and has non empty values on runtime, Jenkins parses it the following way:
java -jar -Dadmin.hostname= -Dschema_name=MYDB myapp.jar
meaning admin.hostname value doesn't get parsed.
I have tracked the problem and noticed that when i dont use . in the parameter name everything get parsed okay.
I am wondering if this is a limitation of Java command line or a bug in Jenkins perhaps. (I am using RHEL64)
Thanks
EDIT:
I think this is bug with Parametrized build jenkins plugin as using . in other builds works fine.
Perhaps the problem is that environment variables on UNIX are case sensitive
$ echo $hostname
$ echo $HOSTNAME
myhostname
There shouldn't be any problem using . because may built in properties uses them.
BTW: Just because a property is set to blank doesn't mean its not set.
System.out.println("not.set=" + System.getProperty("not.set"));
System.out.println("admin.hostname='" + System.getProperty("admin.hostname")+"'");
when run with -Dadmin.hostname= prints
not.set=null
admin.hostname=''
Is there a way to pass the output of git describe --tag to my Java application at compile time? I'd like to use that in my about box to display version info. I'm using Eclipse to build, but I can use ant if necessary.
With C code, I can pass -D'REV="$(shell git describe --tag)"' to my gcc compiler, and my code can pick that up. I'm hoping there's something similar in Java.
If ant is acceptable, it supports a similar command line option.
As a concrete example, this line in an ant script
<echo>property: ${property}</echo>
when invoked with the following command,
$ ant -Dproperty="$(git --version)"
produces the following output on the console,
[echo] property: git version 1.7.5.4
This question already has answers here:
How do I auto load a database jar in Groovy without using the -cp switch?
(5 answers)
Closed 6 years ago.
I have a groovy script that needs a library in a jar. How do I add that to the classpath? I want the script to be executable so I'm using #!/usr/bin/env groovy at the top of my script.
Starting a groovy script with #!/usr/bin/env groovy has a very important limitation - No additional arguments can be added. No classpath can be configured, no running groovy with defines or in debug. This is not a groovy issue, but a limitation in how the shebang (#!) works - all additional arguments are treated as single argument so #!/usr/bin/env groovy -d is telling /usr/bin/env to run the command groovy -d rathen then groovy with an argument of d.
There is a workaround for the issue, which involves bootstrapping groovy with bash in the groovy script.
#!/bin/bash
//usr/bin/env groovy -cp extra.jar:spring.jar:etc.jar -d -Dlog4j.configuration=file:/etc/myapp/log4j.xml "$0" $#; exit $?
import org.springframework.class.from.jar
//other groovy code
println 'Hello'
All the magic happens in the first two lines. The first line tells us that this is a bash script. bash starts running and sees the first line. In bash # is for comments and // is collapsed to / which is the root directory. So bash will run /usr/bin/env groovy -cp extra.jar:spring.jar:etc.jar -d -Dlog4j.configuration=file:/etc/myapp/log4j.xml "$0" $# which starts groovy with all our desired arguments. The "$0" is the path to our script, and $# are the arguments. Now groovy runs and it ignores the first two lines and sees our groovy script and then exits back to bash. bash then exits (exit $?1) with status code from groovy.
If you really have to you can also load a JAR at runtime with:
this.getClass().classLoader.rootLoader.addURL(new File("file.jar").toURL())
My Favorite way to do this is with Groovy Grapes. These access the Maven Central Repository, download the referenced jar, and then put it on the classpath. Then you can use the library like any other library. The syntax is really simple:
#Grab(group='com.google.collections', module='google-collections', version='1.0')
You can read more details here. One major advantage here is that you don't need to distribute your dependencies when you distribute your script. The only drawback to this method is that the Jar has to be in the Maven repository.
You can add the jars to $HOME/.groovy/lib
You can also try out Groovy Grape. It lets you use annotations to modify the classpath. Its experimental right now, but pretty cool. See docs.groovy-lang.org/.../grape
The same as you would in Java.
This is an example of running a MySQL status monitoring script. mysql.jar contains the MySQL connector that I call from script status.groovy.
groovy -cp mysql.jar status.groovy ct1
Below is a combination of Patrick's solution, Maarteen Boekhold's solution, and foozbar's comment that works with both Linux and Cygwin:
#!/bin/bash
// 2>/dev/null; SCRIPT_DIR="$( cd "$( dirname "$0" )" && pwd )"
// 2>/dev/null; OPTS="-cp $SCRIPT_DIR/lib/extra.jar:$SCRIPT_DIR/lib/spring.jar"
// 2>/dev/null; OPTS="$OPTS -d"
// 2>/dev/null; OPTS="$OPTS -Dlog4j.configuration=file:/etc/myapp/log4j.xml"
// 2>/dev/null; exec groovy $OPTS "$0" "$#"; exit $?
import org.springframework.class.from.jar
//other groovy code
println 'Hello'
How it works:
// is a valid groovy comment, so all of the bash commands are ignored by Groovy.
// will return an error, but the error output is redirected to /dev/null and is therefore not displayed.
bash executes commands following a semicolon even though the previous command failed.
exec replaces the current program in the current process without forking a new process. Thus, groovy runs within the original script process (ps shows the process as the script rather than the groovy executable)
The exit $? statement following exec groovy prevents bash from trying to interpret the rest of the script as a bash script, and also preserves the return code from the groovy script.
The above bash trick is more convenient in some cases than the RootLoader trick because you can use regular import statements within the script. Using the RootLoader trick forces you to load all of the classes using reflection. This is fine in some situations (such as when you need to load a JDBC driver), but inconvenient in others.
If you know your script will never be executed on Cygwin, then using Patrick's or Maarteen's solution will likely result in slightly better performance because they avoid the overhead of generating and throwing away an error.
Adding to #Patrick his answer, which helped me a lot, I recently discovered another trick.
If you add lots of jars to the classpath all on one line, things can become quite unreadable. But you can do the following!
#!/bin/bash
//bin/true && OPTS="-cp blah.jar -Dmyopt=value"
//bin/true && OPTS="$OPTS -Dmoreopts=value2"
//usr/bin/env groovy $OPTS "$0" $#; exit $?
println "inside my groovy script"
Let your imagination run wild on how complex a command line you can break down this way into manageable pieces
Maarten
If you want to use it right away before the import declarations it is possible like this :) :
// printEmployees.groovy
this.class.classLoader.rootLoader.addURL(
new URL("file:///C:/app/Dustin/product/11.1.0/db_1/jdbc/lib/ojdbc6.jar"))
import groovy.sql.Sql
sql = Sql.newInstance("jdbc:oracle:thin:#localhost:1521:orcl", "hr", "hr",
"oracle.jdbc.pool.OracleDataSource")
sql.eachRow("SELECT employee_id, last_name, first_name FROM employees")
{
println "The employee's name is ${it.first_name} ${it.last_name}."
}
Taken from this javaworld.com article.