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.
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 am implementing an Interpreter for a moderately simple Pascal/BASIC-like programming language, in Android. I have finished the parser, so programs get recognized, loaded in memory and ready to execute. The language is procedural, emulating command line input/output and obviously not event-driven like Java in Android.
A sample program may look like this:
FOR i FROM 1 TO 10
READ Name
PRINT "User ", i, " name: ", Name
END_LOOP
Being relatively new to Android, I did not know that Android dialogs are asynchronous, and thus cannot interrupt execution, as explained in dozens of similar questions. (1), (2), (3), (4)
So, I initially thought I would implement READ commands by showing a modal Dialog. Executing code that involves reading input from the user, would require waiting for it to finish before moving on to the next line of code. But this should not be done with a dialog, as mentioned in the above posts.
I figured out that the most "appropriate" way would be to "save" the execution state of the whole program, stop execution and then start executing by loading the last state, when user inputs something from the Dialog. But this seems impossible, and way too much hassle for such a simple task. Is there an easier way?
Any suggestions are welcome.
I did not know that Android dialogs are asynchronous, and thus cannot interrupt execution, as explained in dozens of similar questions
All Android UI is asynchronous.
I initially thought I would implement READ commands by showing a modal Dialog.
There is nothing intrinsically wrong with this. However, READ would need to suspend execution of your interpreter until the user has completed the dialog.
Is there an easier way?
Off the cuff...
Step #1: Run your interpreter on a background thread.
Step #2: Have your READ code invoke your dialog on the main application thread, then block on a Semaphore to block your background thread.
Step #3: Have your dialog code get the results of the user input over to your interpreter by some means, then release the Semaphore when the dialog goes away.
Step #4: Your interpreter code continues.
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?
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.