From a Java application I want to run another Java application on the same Java installation but in a separate process.
AFAIK for a new process I would use ProcessBuilder to run a command like
java -jar my.jar
but what if java is in a different directory, or should be java.exe since we are on Windows, or java.exe has some other name since the first application was jlinked and jpackaged?
Edit: What I learned meanwhile is that a jpackaged application comes with a native executable that sits in front of the JVM but passes all arguments to the application. That means it is no longer possible to specify an alternative jar to be executed, and some other mechanism is necessary.
If jlink image used within jpackage based apps is built without using the --strip-native-commands flag then the runtime image will contain bin/java (or bin/java.exe and bin/javaw.exe on Windows).
This will mean that you should be able to determine a path to launch a new JVM which works inside or outside of jpackage apps just based on the current runtime's java.home and by appending extra VM arguments in normal way for the classpath and main / module of the other application.
On Windows the environment property echo %PATHEXT% usually contains .EXE so the following should specify the java executable for the current runtime without needing to add the correct file extension on Windows:
String java = Path.of(System.getProperty("java.home"),"bin", "java").toString();
You can test above inside your jpackage and non-jpackaged app with a simple one-liner (note that this is not proper way to use ProcessBuilder):
new ProcessBuilder(java, "-version").start().getErrorStream().transferTo(System.out);
Obviously, the above is no help if you wish to determine whether to use Windows console enabled java.exe versus non-console javaw.exe.
Related
I have an application that I need to be a self-contained app, installable, on computers that may not have Java. I'm using javapackager command to create an EXE that can be sent out to the users, containing all the parts needed. The app, in a simple sense, reads in a file referenced by the first param, does transformations on it, and writes back out next to the source file a result. All of that works when running it as a JAR directly, and also when running it via the built EXE.
The problem is that when triggering the executable, it immediately returns execution to the command prompt, rather than waiting for the process to finish. I don't want to have to poll the output directory to check if the file exists and then give some arbitrary timeout on when to stop looking - I want the app to know that once the console command has completed, the processing is done. At that time I can do logic based on if I find the result file, and alert if it is not found or whatever other logic is right.
Is there a way to tell the javapackager command to set a wait until Java has died (good or bad) before returning control? Barring that, is there a code snippet/concept that would make the app hold off releasing control back to the terminal until the JVM has died?
I can confirm this behaviour for apps that I've packaged using javapackager included with Oracle JDK 8, 9 and 10 as well as with snapshots from OpenJDK 13. While the resulting binaries behave "as expected" under macOS and Linux, the Windows binary merely seems to spawn a new process and exits immediately.
Beginning with Java 9 jpackager invokes jlink internally, which has an option --strip-native-commands which basically removes binaries from the embedded JRE. With Java 8 you didn't have this option and executables such as java.exe are always removed. But my tests show that the JRE is otherwise complete and you should be able to simply include java.exe manually (better test this thoroughly!).
Therefore I propose the following workaround:
Create the application directory using javapackager -deploy -native image
Copy java.exe from your system-wide JRE installation to {OUTDIR}\runtime\bin (check if your license covers redistributing java.exe!)
Create a .bat file inside {OUTDIR} that calls runtime\bin\java.exe -jar ./app/yourapp.jar.
Now add {OUTDIR} to your .msi or innosetup installer or .zip file or whatever means of distribution you choose ;-)
You can then invoke the bat file instead of the exe. Since it is just a wrapper for java -jar it will wait until your program finished.
I want to automatically run a Java application under Windows at startup time, but not depending on a specical Windows or a special JRE-version.
Generally, a good way to run programs at Windows login time would be to add a registry entry under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
But it seems as if the system PATH is not evaluated when Windows tries to run the programs listed in the registry's RUN section.
So these both entries do work:
"C:\Program Files\Java\jdk1.8.0_111\bin\javaw" -jar c:\path\to\java.jar
"C:\ProgramData\Oracle\java\javapath\javaw" -jar c:\path\to\java.jar
But this one doesn't come up:
javaw -jar c:\path\to\java.jar
Now, the latter works when manually entered in a console window because there the required PATH exists and is evaluated:
PATH=....;C:\ProgramData\Oracle\Java\javapath;....
Now, I want to have the registry entry added from an automated installer programm and I would like to have it formed "windows-system-independent" (from Vista up to Win 10, and furthermore not depending from the version of the installed JRE). So I do not know a general path to the JRE and therefore I cannot add a specific RUN-command to the registry.
Does anyone know how to add JRE-calls system-independent correctly to the registry's RUN-section?
I've already tried with a command-file, e.g. "startup.cmd" with content java -jar file.jar there, have added a call of this file to the registry, and yes that worked, java was found, the application was started, but when using this method I have an annoying black command terminal window staying open all the time while the java app is running.
Thanx,
Tombo
Change your startup.cmd, from
java -jar file.jar
to
start java -jar file.jar
This will launch the java.exe in a new process an let your batch executor terminate.
I wish to open certain java applications (For example, MapTools, part of RPtools) with Oracle Java 6 for compatibility purposes using shell scripts.
In the simplest possible terms, what do I need to do to make a working shell script for an application to launch with a specific java version on Ubuntu?
Note that for maximum usefulness, specific application names should not be used. Instead use tags such as "App" to determine where the name of the application or it's path should go.
Specify absolute path of java executable of the JRE version,
[JRE_HOME]/bin/java -jar jar_name.jar
e.g.
/usr/lib/jvm/oracle-7-jre/bin/java -jar exec.jar
Use the full path to the desired java.exe in your command line.
See Run a JAR file using a specific JRE.
In my app i need send http requests via proxy. In terminal i start it by this:
java -Dhttp.proxyPort=**** -Dhttp.proxyHost=***.***.***.*** -jar app.jar
What environment variable i should use for starting on my apps without -D options, like
java -jar app.jar
OS Linux. Java 7.
Thx!
PS already tried JAVA_OPTS, JAVA_OPTIONS, _JAVA_OPTIONS, JAVA_TOOL_OPTIONS...
Java has two separate ways to pass parameters to programs:
Properties, which are typically specified in the command line arguments (as in your first example), loaded from files or manually added by code.
Environment Variables, which are determined by settings in your operating system.
These two concepts are separate; the former doesn't affect the latter and vice versa. As such, you cannot set a property by means of an environment variable.
Other options include loading a .properties file during runtime (assuming your proxy hasn't already been initialized at that point) or putting the full command (-D arguments and all) in a shell script for easier launching.
Nothing is going to work with the standard Java executable. The Java executable does not recognize any environment variables for setting general JVM options.
All those things that you have tried are conventions used by 3rd-party tools, scripts and launchers.
As far as I am aware, the only Java-specific environment variable that the Java executable pays attention to is CLASSPATH, and that is ignored when you run java with the -jar option.
Having said that, there is nothing1 stopping you from:
creating a wrapper script called java and putting it on your search path ahead of the standard java executable, or
creating a shell alias called java.
Such a wrapper or alias could get JVM options from an environment variable, and you could call it anything you wanted to.
1 - ... apart from good sense :-)
I have a somewhat strange issue. I have a java application that installs few services that run as Jars. Previously I used installed Java to run these Jars. There are four services and all will be instantiated from a single batch file with sequential call to each other. Something like this,
start %JAVA_HOME% commandtoruntjarfile
would work and all four services will run in the background and only one java.exe visible in process explorer. So I had another service installed as windows service which would start stop these services by calling the run bat or shutdown bat.
Now the customer requirement changed to using an internalized version of java. I extract java to a location, make our own environment variable name "ABC_HOME" and the required syntax in batch changes to
%ABC_HOME%\javaw commandtorunjarfile
When its run it works. but there is no stopping these. When I go to process explorer I see 4 java.exe running each for the four run commands in the batch file. If I stop the windows service all the four keep working. If I restart the windows service the number of java.exe in process explorer goes to eight and keeps going up until windows has had enough of it.
How do I get around it? I think the solution should be to have the one java process in process explorer but I cant seem to find any solution for that.
[EDIT]
The four sub services are actually XYNT processes. In the normal scenario it would be something like this
[Process1]
CommandLine = java -Xrs -DasService=yes -cp jarfiles
WorkingDir = c: bin scache
PauseStart = 1000
PauseEnd = 1000
UserInterface = No
Restart = Yes
For using java from a specific location the following change was needed
CommandLine = %JAVA_PATH%\bin\java.exe -Xrs -DasService=yes -cp jarfiles
but this wouldn't work as it would not accept the path variable in XYNT.ini file. so I called a batch file here and in that batch file I used the above code. So here is what the change looks like,
CommandLine = batchfile.bat
and in batchfile.bat
%JAVA_PATH%\bin\java.exe -Xrs -DasService=yes -cp jarfiles
Usually, every Java program run on your system has its own virtual machine running, which means: one java.exe/javaw.exe per instance of your program.
I can not tell why it "worked" from your point of view with java.exe like you described first, but the behaviour you described for javaw.exe (having 4 java processes in the process explorer) would be what I'd have expected.
For me the question is not why you're seeing 4 vs. 1 java processes, but how you can start/stop the "services". Killing the Java VM externally doesn't seem a very good solution. I'd consider building some IPC into the Java services that allow you to gracefully terminate the processes.