In an application I am writing, I am launching another application (a runnable JAR) using Runtime.exec(...). Everything launches successfully in Windows, but Linux (specifically certain installations of CentOS - works in Ubuntu) has been giving me some problems. For some reason, the only way the secondary application will successfully launch is if I execute the first through a terminal. All behavior works as expected. However, if I launch the first application by double-clicking its icon (without a terminal open), the button to launch the second application seems to do nothing. I get no exceptions or error output - just a flash of my progress bar saying that it is launching, and then nothing. I can confirm through jconsole that the second application's process is never launched.
I have seen the commonly linked article on the pitfalls of the exec method ( http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps.html ), but have not been able to solve this problem with anything I have found there. I am in fact reading the output and error streams of the second process, as I see all output when it successfully runs (after launching the first application through a terminal command). Not knowing a lot about deeper workings of Linux, I think this sounds like it may be a permissions issue with the output stream or something, but I am not sure.
In case it helps to diagnose the problem, I am using the command:
rt.exec(new String[]{"\bin\bash", "-c", "java -jar myjarfile.jar myArg1 myArg2 ..."}); Since this works (depending on how the application is launched), I'm not too concerned that anything is wrong with this piece of code...
Anyone have any suggestions? Thanks in advance!
EDIT: The solution was to fix the directory to the JAR I was attempting to run. When launched via the GUI, user.dir was pointing to the parent directory of the folder containing my application. Since I'm using Eclipse RCP, my solution was to use
String currDirPath = Platform.getInstallLocation().getURL().toString(); instead. Thanks for the help everyone!
Since you're just using the jar file name - myjarfile.jar - and not the full path to it, depending on the current working directory, the jar may or may not be found. Try changing your exec command to use the full path to the jar instead. You can debug this by using rt.exec() to write the output of 'pwd' to a text file.
instead of
rt.exec(new String[]{"\bin\bash", "-c", "java -jar myjarfile.jar myArg1 myArg2 ..."});
use
rt.exec(new String[]{"\bin\bash", "-c", "/***path to java***/java -jar myjarfile.jar myArg1 myArg2 ..."});
Related
I'm trying to run a java program on windows in VSCODE. When I click the run button at the top it opens the Java Process Console and runs the following command:
$ cmd /C "c:\Users\user\.vscode\extensions\vscjava.vscode-java-debug-0.31.0\scripts\launcher.bat "C:\Program Files\AdoptOpenJDK\jdk-11.0.10.9-hotspot\bin\java.exe" -Dfile.encoding=UTF-8 #C:\Users\jbree\AppData\Local\Temp\cp_7gau2431e54dxprosf092viw9.argfile com.example.restservice.RestServiceApplication "
It then prints out: Command 'cmd' not found, but there are 16 similar ones., and I'm not too sure what to do afterwards.
I just ran into this exact issue! After some debugging, I found out it's because my terminal (in VS Code) was running off of WSL.
Make sure to check which terminal you're using! If you're trying to run Java locally, then you can configure a default shell ie. bash.
Let me know if this helps.
Edit: I also found this, not sure if it will help, but here you go!
https://stackoverflow.com/a/58058378/11060097
your java debugger is using wsl. and most likely your java is installed on windows. not linux on windows. to fix this for me, i changed the settings for java debugging to use the external console. settings->java debugger->externalTerminal . this will then use the "external windows" setting for vscode. which should use cmd.exe (the windows shell, no linux).
This error happens because you probably have wsl has your standard terminal but it's probably configured to launch cmd using a windows path.
WSL won't understand what that windows path is, so you need to change it using a path structure it can understand
So
hit Ctrl+, to hit the Settings screen
type in terminal to see all the terminal settings
You will see an option called Terminal> External:Windows Exec
Change C:\Windows\System32\cmd.exe to /mnt/c/Windows/System32/cmd.exe
I had this error too and came here initially but I managed to figure out it was an incompatible path issue that was the cause.
We have a Java application based on Eclipse (main class implements IApplication) that is started from the Windows command line. Its output on System.out is not visible/printed into the command window from which it is started. Nevertheless, when piping the output to more, the output is fine. How come?
For example, consider helloworld.exe. When running C:\>helloworld.exe in a command window, the application simply returns. But when running C:\>helloworld.exe | more, the screen shows
C:>helloworld.exe | more
hello world
C:>
On linux, the output is fine. How to see the output on Windows, too?
Some reqested information:
The application is quite large. And I probably cannot cut it down. The output are simple calls to System.out.prinln("xxx");
Java version 1.8.0_60, Eclipse 3.6.2
Using >std.txt 2>err.txt shows that output is indeed on stdout.
Line endings are CR/LF
the .ini file is as follows
--launcher.suppressErrors
-vmargs
-Xms256m
-Xmx4096m
-Djava.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory
-Djava.library.path=plugins
Maybe this issue is related?
If your application is somehow started via eclipse.exe (has no console attached to it) change the call to use the eclipsec.exe (has a console attached to it, note the c in the application name).
You can launch Eclipse RCP based applications using equinox launcher as shown below:
java -jar plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar
Of course you have to find the correct version of equinox launcher you are using in your RCP Application.
This way you would see the console logs.
You can read more about it here: http://wiki.eclipse.org/index.php/Starting_Eclipse_Commandline_With_Equinox_Launcher
EDIT: The reason you don't get console logs when eclipse.exe based launcher is used is because eclipse.exe on Windows spawns a separate process which brings up another command prompt window.
You'd better use a framework to handle your logs like logback
This is much more portable and maintainable.
In your example it seems that you have created an exe from your java code. My guess is that the packager you used to create the exe made some changes to the output target because it is a wrapper for your java program.
Try creating a jar instead and try executing it by java -jar helloworld.jar.
Is the string going to stderr in place of stdout? (or the other way around depending on your expected behaviour).
https://support.microsoft.com/en-us/kb/110930
I have a Java application that runs great :) While uploading files, it uses the standard output to show progress : "System.out.println(...);".
When I run it in Eclipse, well it works perfectly, but when I run the JAR file, I don't see any console/terminal showing up and printing what I print through "System.out.println(...),".
How can I open a new terminal when my application is launched (it is a Swing application)?
Basically I want to be able to run the Swing application and show information on the side in a terminal / console. Why? Don't worry about why I want to do this ;)
Thanks a lot!
Regards.
Open terminal and run application as java -cp yourjar.jar YouMain or java -jar yourjar.jar if you jar is runnable.
I believe that you do not see output because you are running your application using javaw - the special windows-only variation of JVM that does not have STDOUT at all. If you want to click your application and see output map *.jar file to be opened using java instead of javaw. Alternatively write bat file that runs your application. In this case you will see console.
Use java instead of javaw to launch your application. Double-clicking on a jar executes it with javaw. Instead, open a command line window and type
java -jar thePathOfTheJarFile.jar
If you want to have something double-clickable, then write a shell script containing this command, and double-click the shell script instead of the jar.
I am trying to run a simple JAVA program once per day on a Windows 7 machine.
My code runs fine inside NetBeans. If I do a clean and build it suggests this:
C:\Program Files\Java\jdk1.7.0/bin/java -jar "C:\Users\User1\Documents\NetBeansProjects\Facebook\dist\Facebook.jar"
This does not work from the DOS prompt of course because of the space between program and files so I do this:
C:\Program Files\Java\jdk1.7.0/bin/java -jar "C:\Users\User1\Documents\NetBeansProjects\Facebook\dist\Facebook.jar" -jar "C:\Users\User1\Documents\NetBeansProjects\Facebook\dist\Facebook.jar"
This works from the DOS prompt.
I now create a task in Windows Scheduler to run:
C:\Program Files\Java\jdk1.7.0/bin/java
with arguments:
-jar "C:\Users\User1\Documents\NetBeansProjects\Facebook\dist\Facebook.jar"
When I then run it, all I see is a DOS box flashing up for a second. I expect the code to take about 30 secs to run. The code should persist data to a database and no updates happen.
The code also uses java.util.logging so I should see log entries and I don't.
I strongly suspect that I am not running the JAVA command properly or that there's a bad classpath issue that it present when running via Scheduler that isn't there when running from the DOS prompt.
Help would be appreciated. If you've seen this before and can sort it that would be great. If you can tell me how to get a meaningful error trace from Scheduler than that would also be really helpful.
Thanks!
I Think that you could create a simple batch script that will launch your program in this way :
#echo off
REM Eventually change directory to the program directory
cd C:\Users\User1\Documents\NetBeansProjects\Facebook\dist\
REM run the program
"C:\Program Files\Java\jdk1.7.0\bin\java.exe" -jar "C:\Users\User1\Documents\NetBeansProjects\Facebook\dist\Facebook.jar"
Copy it into the notepad and save as java_script.cmd and then schedule this script instead of the program directly.
I solved it after changing all fonts' references to "SansSerif"
I was using Jasper Reports inside Java to create a PDF file. It was working fine when I double click the batch file or Scheduler with Windows Server 2003 but not working with the Scheduler of 2008.
I tried many different things nothing worked so I though Could it be that Windows Server 2008 is blocking the access?.
Now is working perfect. So, if you are having problems check the references to anything you are using.
The scheduler will run under a different user unless you specify what user to run as. If it isn't running as your user then it won't be able to write to your directories.
The real problem to the original question is a java installation issue on Microsoft systems. Java jre installs into Program Files\java. The executable (java.exe) is only installed in that java\bin directory. Running from the command line, the os looks in the proper location for the java.exe. Running from other MS tools (such as VBA Excel or in this case TaskScheduler), it does not!
You can see that TaskScheduler is looking in the wrong place by viewing the tasks history in the TaskScheduler tool. Double click on some of the history events and one will list the action and return code. The action will show that the TaskScheduler is trying to run
"C:\Windows\system32\java.EXE"
So, copy java.exe from the java\bin directory into the place where the scheduler is looking, and now it will work.
Or update your task and provide the full path to java.exe.
You can also update the environment system path to look for java in the java\bin directory, but that has to apply to all users and sometimes this is faulty as well.
The Problem is as follows:
I have a Java Application packed in a ".jar"-File.
I can start the App (Swing Application) by either
doubleclick on the jarfile
commandline java -jar MyApp.jar
However when I put the commandline command into a batchfile, it will tell me
Unable to access jarfile MyApp.jar
The batch file is in the same directory as the jar. Just where I also started from cmd-line.
I tried to call the bat with Administrator-rights and from an admin-shell - no effect.
I'm working on a Windows 7 (64bit) machine. Any hints will be appreciated.
EDIT
You asked for it :) Here is the batch file:
#ECHO OFF
java -jar MyApp.jar
#PAUSE
EDIT 2
Invoking the batch by double-click and from cmd has the same effect.
Changing the command to
java -jar "C:\Full\Path\MyApp.jar"
has no effect.
EDIT 3
I added SET Path=%Path%;C:\Path\To\Jar to the batchfile. No effect.
I also tried using double backslashes as suggested by Chris' link and supported by Viruzzo. Also no effect.
When you double click on .bat file, the working directory is not set to where the .bat file is, but is usually something like %AppData%. To make it work you need to put the full path to the file inside the bat (i.e. java -jar C:\path\to\jar\MyApp.jar).
I just had to put my path in quotes, even though it had no spaces or odd characters.
java -jar C:\Users\Jacob\executables\some-file.jar failed, but
java -jar "C:\Users\JStamm\executables\some-file.jar" worked.
This isn't the answer to your specific problem, but this will allow you to troubleshoot the problem so you will find an answer. Adding a sleep command will let the command prompt sit, so it doesn't close right away.
ping 1.1.1.1 -n 1 -w 10000
(sleep for 10 seconds)
Make sure you don't have the hide extension option enabled in windows. Maybe the name of your jar ends with .jar.jar? Are you sure the path to the jar is correct?
I havent't yet figured out why, but now it works:
The first batchfile was a copy of another and I just changed the contents to fit my needs.
NOW I renamed it to MyApp.bak and wrote a new MyApp.bat from scratch.
As soon as I find out, what the difference was, I'll update this answer.
UPDATE
It happened again with another batch. This time, we got the reason: For some reason, the batch file did not inherit rights when copied. Creating a new one in the folder had the correct rights. So, in the end it was indeed a rights-issue.