Suppose you're short on time and you're looking for a program with certain features, and you find one, except it lacks one feature - it cannot save and load its state. Is it possible to achieve this on OS level, or with another program, that can take the whole thing, write it to a file, and then at a later time, load it back into memory? How?
Specifically for me, this is about a Java program, but any more information on this topic is welcome.
One (heavy and easy) solution could be to use VirtualPC and install the program on a virtual OS.
Check these library's:-
Brakes
ACTC(Asynchronous Transfer of Control Threading) [Article]
Apache JavaFlow
You want to do something like the Hibernate function of Windows right?
This will be extremely difficult to implement in Java as you will also have to write the state of the JavaVM. If you had open files when you closed the program end so on.
I think the best you can do is writing the objects you need to recover to disk using Java serialization.
Have a look at the CRIU project at https://criu.org/Main_Page
It offers exactly this possibility within linux systems. Docker integrates it and offers a docker checkpoint command, which if you run your program in a container, will allow you to do this on any OS.
Related
This might be just too crazy to accomplish but this is what I'm trying to do:
I want an very basic java program that upon running will download another java program from a certain server and run that. I'm terrible with these kind of dynamic things but is there a way to download it and run it from inside the original program?
This is something I wanted to implement to prevent the need for issuing updates, assuming the computer must be connected to the internet in order to run the app, otherwise they can't.
Java does support this, and you can write this sort of thing yourself, but JNLP (aka Java WebStart), already does this, and it might require far less work on your part than rolling your own solution.
I'd like to start external third party application from my Java application. This external application should run all the time whilst my java application runs.
From time to time (it depends on user interaction) my java app should be able to read and write to this external application via stdin and stdout.
How can I do that?
Essentially, you will need multiple threads in Java that watch for the outside process to end and which shuffle around its input/output/error streams so that your main Java app has access to it.
There are more "basic" ways to do it with classes like Process, but I would suggest Apache Commons-exec, which provides some useful tools for handling return values and I/O.
As you are implementing the suggestion of starting a Process, read and implement all the recommendations of When Runtime.exec() won't.
Also consider using a ProcessBuilder in place of Runtime.exec() (if coding for 1.5+).
Is ex-app native code, or another Java program? If it's native code, look at http://download.oracle.com/javase/1.5.0/docs/api/java/lang/Process.html and http://download.oracle.com/javase/1.5.0/docs/api/java/lang/Runtime.html
Those will allow you to execute a native program, keep track of its status, and get its output and send it input.
It depends on the specifics of the external application, mainly: 3rd party or is it something you have control over?... what it's built with, what it's capabilities are, etc.
A 'kludgy' method would be to simply use the file system and have Java watch for files dropped in a specific location (taking care to handle locked files appropriately). A more sophisticated method would be to communicate via sockets, or writing to a database table within a local/internally hosted db such as hsqldb. Using in/out streams via java.lang.Process might also do the trick, depending on the 3rd party app of course.
But again all of this depends on the specifics of the application you're communicating with. Java's Process class isn't going to help if the 3rd party app is Excel (in which case you'd probably have to watch a save directory for xls files per the first method I mentioned).
I have a situation where I need to execute some code that for a number of reasons (that I won't get into here) is better done in Java than in PL/SQL. As I see it there are two options:
Create a jar with all my compiled code and other supporting files/other jars, load the jar into Oracle (we're running 10g), and execute the Java from a stored procedure.
Pros: The Java code integrates very nicely with the rest of the system, can be called from existing PL/SQL.
Cons: I have very little experience with running Java in Oracle.
Leave the Java in a separate jar and execute it through shell scripts.
Pros: I've written Java like this before so I'm familiar with it.
Cons: Poor integration with everything else, will probably require extra manual steps to run and manage.
The Java code will have to read XML data from Oracle tables, and write data (non-XML) to other tables, so the amount of database integration made me think loading the Java code into the database might be a good idea but I'm just not sure...
What experiences do people have loading and running Java code from within Oracle? How easy is it to test and debug? Are there are any special tools required? Any "gotchas" I should be aware of?
I would go with option number 1: loading your java code in your database. I have had good experiences with this approach and you don't need that much experience to get a good solution working with this method.
The only part where embedding Java in your database gets complicated (you'll have to set special permissions for your Java code) is when you need access to external resources (network, file i/o to name a few) and it is clearly not your situation in this problem.
For your scenario, doing it within the database seems the right approach. Reasons to do it outside could be:
dependence on Java libs that are not compatible with Oracle's built-in JVM
need to run it under a different linux user account than Oracle's
but I don't see either in your scenario
I've been looking for an api for simple java-based multiprocessing and couldn't find anything.
I have legacy code which I need to integrate into my java application. Since this legacy (native) code crashes sometimes, the whole jvm crashes with it. So what I want to do, is to run this code and its adapter in a different process (not thread!).
There's the ProcessBuilder in the newer java jdks, it lets you start a new process and gives you a In/Outputstream; so solving my problem is possible by hand. In order to do so, you have to find the path to your jvm and start it up with the for your process. Then you have to use the stream to communicate.
Is there something which takes over that job? Or do I really have to do it by hand?
AFAIK, people usually do this by hand.
The problem is that there's no truly portable way of doing it ... what with the difficulty (impossibility) of identifying where the currently running JVM was launched from, and the fact that JVM command-line options are vendor, version and (potentially) platform specific.
The simple solution is just to put the JVM path and options for launching the child JVM into some configuration file.
You can use the -Dprocess.name=$1 and let your main class take in some command line args. You can invoke by calling something like this:
java -cp $CLASSPATH $VM_ARGS $MAIN_CLASS
and your VM_ARGS can be defined something as
VM_ARGS=" -Dprocess.name=$1"
FWIW, I wrote a replacement class to take care of a lot of the I/O stream redirection nastiness, at david.tribble.com/src/java/tribble/util/RuntimeExec.java
You are looking for the technology called Java RMI (Remolt Method Invocation).
This allows one JVM to call a method in another JVM. This can be on the same machine or over a network.
I need to write a process controller module on Linux that handles tasks, which are each made up of multiple executables. The input to the controller is an XML file that contains the path to each executable and list of command line parameters to be passed to each. I need to implement the following functionality:
Start each executable as an independent process
Be able to kill any of the child processes created, independent of the others
In order to do (2), I think I need to capture the pid when I create a process, to issue a system kill command. I tried to get access to pid in Java using ProcessBuilder but saw no easy way to do it.
All my other logic (putting info about the tasks in DB, etc) is done in Java so I'd like to stick with that, but if there are solutions you can suggest in C, C++, or Python I'd appreciate those, too.
For a Java solution, you should take a look at the apache commons exec library. They've done a lot of work to make it platform independant and they have a great tutorial.
In python, you can use the included subprocess library.
You really really need to look up "shell scripting" on google. Specially if your employer/instructor wants you to work on linux and deal with processes etc.
Maybe start here:
http://supportweb.cs.bham.ac.uk/documentation/tutorials/docsystem/build/tutorials/unixscripting/unixscripting.html
I'm not sure, but if you start executables from Java, you may start them in seperate threads, and then you can map them however you want - by name, by line number or something - and stop that enclosing thread regularly as java-thread, which doesn't seem to be an elegant solution (not closing files, etc.), but could work to some extend (as long as the linux-program doesn't start a process, which is freeing itself from its parent).
Specific commands for closing each process, send via stdin to the programs, might be another option. How to handle stdin and stdout and other pitfalls are mentioned here in some length:
http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps.html?
Visible programs can even be controlled by java.awt.Robot (keyboard, mouse).
As a last idea I would consider using a new command "kill pidof program" which working on a name-basis, so you can't distinguish two instances of the same progam.
I don't know the apache-lib, mentioned by Steen, but there is normally very useful stuff, I would recommend to look there too - maybe in the first place.