I have a java app which has a menu. One of the menu items is Exit. Which is defined as follows:
item_exit.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent event) {
System.exit(0);
}
});
Another menu item is New, which makes another instance (?) of the same program run in parallel. It is defined as follows:
item_new.addActionListener(new ActionListener() {
MyApp app = new MyApp();
app.start();
}
});
It works as desired except for one problem. It's that when I close one of them, both of them close. The entire app is built on one JFrame object. I don't think changing the default close operation of it will help. I think the issue is with system.exit(0). But, what is the alternative to fix this? I only want the thread I closed to close, not all of them. Thanks.
Creating an object and callings its start() method doesn't make another program run in parallel. It only creates an object, in the same JVM, and executes its start() method, in the same JVM.
System.exit() exits the JVM, so everything running in this JVM stops running.
To make a JFrame invisible, you call setVisible(false) on it. That won't stop the JVM.
System.exit(0); makes the entire Java machine to quit, with everything that is running within. Try not to use this, unless you really need this to happen.
For quitting, perhaps try checking this How to close a Java Swing application from the code
System.exit(0) quits the complete program, not only the current thread. If you want to quit a thread, you have two options: a thread automatically quits as soon as the corresponding Runnables run() method finishes, or you can kill the thread using thread.stop() (just for completeness, shouldn't be used).
Please read the documentation for System.exit(). It specifically states:
Terminates the currently running Java Virtual Machine.
This means the JVM will terminate, and all of your threads with it.
System.exit(0) shuts the whole JVM down.
Your two instances run on the same JVM : you don't fork a process, you just create another instance of your MyApp class. So it is obvious that both "applications" will be killed.
Instead of calling System.exit(0), you should send a termination signal to the JFrame you want to close
frame.dispatchEvent(new WindowEvent(frame, WindowEvent.WINDOW_CLOSING));
This way, only that JFrame (or "application") will be killed.
Another option would be to fork a whole new process. For that, I recommend you take a look at the Process class.
Basically, you'll need to change the action of "Exit" so that it's able to detect when there's another "app" currently running ... and to do something plausible in that case. Maybe you alert the user that the other activity hasn't finished yet, and warn him that if he really wants to exit now, the other activity will be abandoned. Maybe you launch the other activity in such a way that it is altogether separate and therefore doesn't care. There are several good alternatives, so this really becomes a design decision on your part: what strategy makes the most intuitive sense for you, and for your users?
Related
I am making a javafx application that simulates a robot vacuum.
I want it to be automated so it would vacuum the environment by itself.
I need to insert a delay so a human can see the steps the vacuum is taking as it traverses the environment.
So far all the delay methods I have tested crash my program if they are inside a while loop.
If I put it outside the while and just click a button for the next step, everything works fine.
It also works fine if I set the delay to really short time, like 1 ms.
Any ideas of why this is happening?
Any application that executes a set of instructions for a while (is busy) and cannot respond to user input or system events is "seen" by Windows as "not responding" and when you try to interact with a "not responding" program, Windows will tell you it crashed.
The problem, you see, is that you try to delay interface updates with a while loop, and that makes your program execute something for a while and while is busy executing your loop it cannot respond to system or user events.
If you want to make delayed updates, use multithreading. Your while loop is blocking the main thread which is also responsible for rendering and taking any input, so you cannot block this thread. Create another thread and share state (eg. use observer pattern). And then you can execute TimeUnit's sleep() in this helper thread and it won't make your app "crash".
Everywhere I look about how to forcefully stop a thread in Java, I see "just do an exit variable check instead, your program is broken if you need to force kill."
I have a rather unique situation though. I am writing a Java program that dynamically loads and runs other Java classes in a separate thread. (No comments about security risks please, this is a very specific use case).
The trouble is, since other people will have written the classes that need to be loaded, there's no way to guarantee they'll implement the stop checking and whatnot correctly. I need a way to immediately terminate their thread, accepting all the risks involved. Basically I want to kill -9 their thread if I need to. How can I do this in Java?
Update: here's a bit more info:
This is actually an Android app
The user code depends on classes in my application
A user class must be annotated with #UserProgram in order to be "registered" by my application
The user also has the option of building their classes right into the application (by downloading a project with the internal classes already compiled into a libraries and putting their classes in a separate module) rather than having them dynamically loaded from a JAR.
The user classes extend from my template class which has a runUserProgram() method that they override. Inside that method, they are free to do anything they want. They can check isStopRequested() to see if I want them to stop, but I have no guarantee that they'll do that.
On startup, my application loads any JARs specified and scans both all the classes in the application and the classes in those JARs to find any classes annotated with the aforementioned annotation. Once a list of those classes is built, it is fed into the frontend where the UI provides a list of programs that can be run. Once a program is selected, a "start" button must be pressed to actually start it. When it is pressed, the button changes to a "stop" button and a callback is fired into the backend to load up the selected class in a new thread and call the runUserProgram() method. When the "stop" button is pressed, a variable is set which causes isStopRequested() to return true.
You can kill -9 it by running in its own process i.e. start with a ProcessBuilder and call Process.destroyForcibly() to kill it.
ProcessBuilder pb = new ProcessBuilder("java", "-cp", "myjar.jar");
pb.redirectErrorStream();
Process process = pb.start();
// do something with the program.
Scanner sc = new Scanner(process.getOutputStream());
while (sc.hasNextLine()) {
System.out.println(sc.nextLine());
}
// when done, possibly in another thread so it doesn't get blocked by reading.
process.waitFor(1, TimeUnit.SECONDS);
if (process.isAlive())
process.destroyForcibly();
Java 8 had Thread.stop(). The problem is that it could only work reasonably for very limited use cases, so limited you were better off using interrupts, and if the code isn't trusted, neither are any good.
There is the deprecated Thread.stop() but don't use it.
There is no way to cleanly terminate another thread without it cooperating.
The thread can be in a state where it allocated some memory, or added some objects to some global state, locked some mutexes, etc. If you kill it at the wrong moment, you risk leaking memory or even causing a deadlock.
It would be possible through JNI, under Windows there is a TerminateThread API that you can call, there is (hopefully) probably a similar thing under Android. The trouble will be getting the thread's native handle, you would need to obtain that when your user "program" is first loaded, probably by calling another JNI method from the thread in question as part of the initialisation process and getting the current thread handle from that.
I have not tried this myself, best case is that this "works" and kills the thread, but it is going to cause that thread to leak resources. Worst case is that it will leave the JVM in an inconsistent state internally, which will probably crash your entire application.
I really think this is a Bad Idea.
A better design, if you want to allow this, is to run your user code in another process and communicate with it via sockets or pipes. This way you can relatively safely terminate the other process if necessary. It's more work, but it's going to be a lot better in the long run.
You shold use Thread.interrupt().
I have a program which bruteforces an AES256 encryption, how would I pause the program when the computer goes into shutdown/or reboot and continue at the same point until the next boot of the system?
A sort of hibernate of the program.
I would agree with part 2 and 3 of #Thufir's answer, but regarding part 1 it assumes that you are running a GUI.
Instead of this I would add a shutdown hook into the JVM and write the state of my program at that point. You can do this using the following:
Runtime.getRuntime().addShutdownHook(new Thread() {
public void run() {
// your serialization code goes here
}
});
You asked three things here.
1- How can I check when the OS goes reboot/shutdown
Solution:
You can make an empty invisible window, and add WindowListener to it. It will receive windowClosing event on windows.
You can find an example HERE
2- How can I save the state of my BruteForce process and pause to start again when system goes up.
Solution:
Here is easy, you must serialize. These will save the state of your class/classes to deserialize when system goes UP again. You can study HERE
3- How know when startup the programm again when OS goes UP?
Solution:
You can put your program in initialization process of your OS. When it starts, you check if there is anything to deserialize and do it, restoring the process of the BruteForce.
I am relatively new to Stackoverflow and Java, but I have a little experience in C. I liked the very clean way of C exiting the programs after a malfunction with the 'exit()' function.
I found a similar function System.exit() in Java, what differs from the C function and when should I use a 'System.exit()' best instead of a simple 'return' in Java like in a void main function?
System.exit() will terminate the jvm initilized for this program, where return; just returns the control from current method back to caller
Also See
when-should-we-call-system-exit-in-java ?
System.exit() will exit the program no matter who calls it or why. return in the main will exit the main() but not kill anything that called it. For simple programs, there is no difference. If you want to call your main from another function (that may be doing performance measurements or error handling) it matters a lot. Your third option is to throw an uncaught runtime exception. This will allow you to exit the program from deep within the call stack, allow any external code that is calling your main a programmatic way to intercept and handle the exit, and when exiting, give the user context of what went wrong and where (as opposed to an exit status like 2).
System.exit() may be handy when you're ready to terminate the program on condition of the user (i.e. a GUI application). return is used to return to the last point in the program's execution. The two are very different operations.
I have, a game bot which runs through console. I don't think i'm going to code a gui for it but i would like to have the possibility to close the program without CTRL+C cause this just interrupts my program instead of properly cleaning up the code and ensure that theres no leaks.
Should i use som kind of Key Bindings or am i bound to, make a GUI ?
Or how could i go about this ?
I think thats what a shutdown hook is for.
Runtime.getRuntime().addShutdownHook( new Thread() {
#Override
public void run() {
System.out.println("Application shutdown");
}
});
David's answer is good. It may well work for you.
I generally prefer not to deliberately abort a process and then detect that it's coming down to avoid dangling operations. So I'd probably do more like:
Are you processing console inputs as they are entered? IF so, you could just have a console command that tells the app to shut down, and check for this in whatever your process is of handling console inputs. Or if you mean that the app just runs with no user input, you could just periodically check if the console buffer is empty (Console.reader().ready()), and if not, read the console and see if it's the quit command.