I'm writing a program in Java which relies on a pre-compiled third party JAR residing in the same directory as mine. At runtime, my program checks if this file exists, then downloads it if it doesn't. Its main class is then executed. However, the spawned program prints a large amount of text directly to the console. Is there any way to 'capture' (and therefore hide) this output from stdout and return my own input directly from my parent application to stdin? I would ideally like the child program to reside inside the same JVM, so I would like to avoid any version of Runtime.exec().
Use the Java 1.5+ ProcessBuilder class and the Process class. Remember that the process will block if you don't handle its streams correctly.
Related
I'm making a little tool that handles a sort of exotic device, with lots of options to manage it etc. One of them would be to scan for tty ports, find the right one then throw the user to "minicom" with some parameters for example.
How can I make java completely exit while running a specific command, under certain condition, after such exit ?
Initial thoughts would be to use a bash script, scan the return value, communicate via files etc.A fully functional interactive serial console in Java would be the dream, but the ones I try right now can't seem to even find tty ports now.
Most processes on linux follow a call stack where process A calls process B which calls process C.
Wen process C terminates, the control goes back to process B, and so on.
It sounds like in this case you want java to call minimum, but when java is finished, return to the parent shell.
I am not aware of any way you can terminate a JVM upon a call to another process (returning to the JVM's parent when it terminates). Perhaps with some clever C calls using JNI, but that isn't really java anymore and could create new problems.
You could have the JVM wrap the target process and pass through the user inputs and outputs. Alternatively, use file communication, e.g. the java program writes the command-line to a file, that the parent bash script executes after the JVM terminates, but that is a bit of a kludge.
I wrote a Java class, I made it into a runnable jar, I want to call a method in that class in a beanshell or JSR223!
I wrote a beanshell sampler, in that I imported the class and called that method, the method calls another method which has multithreading, it uses ExecutorService.
What is happening is, the beanshell is working fine, the class is imported, the method is called, the method called another method which has threads, the problem comes when the thread is started, when the thread is started, the beanshell script is not moving further, the testcase in jmeter is not stopping at all, Is it because of threads in the class in that jar?
Given you have a runnable .jar it might be better idea to run it using OS Process Sampler. So you will be able to decide whether you want to wait till the .jar completes its work or not by using underlying operating system functionality like start command in MS Windows Family or & operator or nohup command in Linux.
See How to Run External Commands and Programs Locally and Remotely from JMeter article for more details.
If you would like to continue with scripting make sure to use JSR223 Test Elements and Groovy language as currently it is the best option in terms of performance.
With regards to your "not moving further" it is hard to tell what's going wrong without seeing your Java/Beanshell code, try checking jmeter.log file for suspicious entries.
I am creating a web application where user enters a query and i have a program in perl which tag the words in query. I am writing a spring controller to handle the Web request and then call the perl program from java class. Is this the optimized way. Is there any performance issue or time delay in calling perl program from java?
Well, it depends on how you are calling the perl program. When running a perl script, the perl interpreter starts, then compiles the script, then runs it. This means everytime you run program you spawn a new process, read the text file(s) containing the program, interpret them, and then get the results.
This is not optimum.
To optimize the process, write a wrapper in perl for you perl script that runs it continuously in a loop, waiting for input from your java process via a socket, named pipe, or file descriptor. This way, the process does not have to start over and over again. To support greater concurrency, run a pool of these.
At my university there is a Sun Grid Engine where I need to perform some tests on. These tests are written in Java an therefore I have created a JAR file which, by just executing it, starts the tests. The test reads in a file and performs some computation on it and at the end writes out a txt file with some results. However, every test is having different parameters which I pass in through the Main method of the JAR. After reading in the file, the parameters will give a different output.
Now I wonder, is this possible to accomplish? Can I run the same JAR multiple times knowing that they all need to read in the same (so just one) file?
Yes. It is possible. Having multiple processes reading the same file is not a problem, even if those processes are not on the same physical machine.
However, make sure you have a different output file per processes.
I am trying to write a Java program that will execute a line of code on the Windows command prompt. I would like to use an external program (7-Zip) to extract some RAR files (it's more complicated than that but it doesn't matter for the problem at hand).
I got the Runtime instance and used the .exec() method. It works fine when I try to extract one archive by itself but when I try to extract many at the same time, the process gets hung up and .waitFor() never returns.
I researched the problem and believe it is being caused by the output the process is producing. It seems that some buffer or another is filling up and locking up the program. I was outlined here. I implemented this solution (except I used an imput stream and directed it to a file) and it did indeed work. However, it seems to take a lot of extra time to write all that completely unnecessary output.
I was wondering if there was a way to trick the BufferedReader into thinking it has written all that is in its buffer without actually writing it?
Thanks for reading all the way to the bottom!
It's not the Java part that is hanging, it is the native application which blocks when it cannot write it's output anymore.
Since you already have the code to make it work in Java, why don't you just stick with that?
The next best option would be to make the external process not produce any output. Maybe there is a "silent" flag? On Linux, you can also pipe to /dev/null, not sure if Windows has an equivalent (I suppose you could pipe into a file).