We Keep Coding

JavaFX show looping Python print output

I built a GUI in JavaFX with FXML for running a bunch of different Python scripts. The Python scripts continuously collect data from a device and print it to the console as it's collected in a loop at anywhere from around 10 to 70 Hz depending on which script was being run, and they don't stop on their own.
I want the end-user to be able to click a button on my GUI which launches the scripts and lets them see the output. Currently, the best I have done was using Runtime.exec() with the command "cmd /c start cmd /k python some_script.py" which opens the windows command prompt, runs python some_script.py in it, and keeps the command prompt open so that you can see the output. The problem with this is that it only works on Windows (my OS) but I need to have universal OS support and that it relies on Java starting an external program which I hear is not very elegant.
I then tried to remedy this by executing the python some_script.py command in Java, capturing the process output with BufferedReader, creating a new JavaFX scene with just a TextArea in an AnchorPane to be a psuedo-Java-console and then calling .setText() on that TextArea to put the script output in it.
This kinda worked, but I ran into many problems in that the writing to the JavaFX console would jump in big chunks of several dozens of lines instead of writing to it line by line as the Python code was making Print() calls. Also, I got a bunch of NullPointerException and ArrayIndexOutOfBoundsException somewhat randomly in that Java would write a couple of hundred lines correctly but then throw those errors and freeze the program. I'm pretty sure both of these issues were due to having so much data at such high data rates which overflowed the BufferedReader buffer and/or the TextArea.setText() cache or something similar.
What I want to know is what approach I should take at this. I cannot migrate the Python code to Java since it relies on someone else's Python library to collect its data. Should I try to keep with the pseudo-Java-console idea and see if I can make that work? Should I go back to opening a command prompt window from Java and running the Python scripts and then add support for doing the same with Terminal in Mac and Linux? Is there a better approach I haven't thought of? Is the idea of having Java code call Python code and handle its output just disgusting and a horrible idea?
Please let me know if you would like to see any code (there is quite a lot) or if I can clarify anything, and I will try my best to respond quickly. Thank you!

My solution was to still call the Python code from the Java Processbuilder, but use the -u option like python -u scriptname.py to specify unbuffered Python output.

How to move Java runtime console to different terminal window?

I executed a Java program from the command line in terminal app A. I want to move the console to terminal app B without having to exit and re-execute the program.
I can think of a few potential ways to solve this, ranging from:
A) In Java implement a new InputStream and OutputStream that somehow can be wired to a new process started in terminal app B.
...to
B) Find a way to put the main Java process in terminal app A in the "background" so that original process can be reopened in a terminal app B.
Ideally, I want to be able to "log in to" and "log out of" my Java process from any terminal on my computer. Has anything like this already been accomplished, and which approach would be best to make it myself? I am open to solutions that involve Java code, shell scripts, or both.
My specs:
OSX: 10.12.4
Usually running zsh on iTerm

If I was using Linux, the perfect solution would be reptyr, a command line tool that allows you to easily switch terminal windows.
On Mac, the best solution I have found is screen. It can also be used to switch terminal windows but must be invoked before running java in order to work and seems a lot more complex.

How does one start a Java server in Linux via console?

So I have a Java program sitting on my DigitalOcean server and I have been using the command,
java -jar IO_Server.jar
To run it. However the problem is that when I type this command in PuTTy, it requires that I keep PuTTy open. If I close PuTTy, the server then shuts down which is not what I want. I need a way to start the server and leave it running even after PuTTy is closed.
I have been trawling the internet for about 2 hours without any luck. I keep coming across the aforementioned command. I have used the command before but I cannot remember what it is nor where I found it.
Help would be appreciated!

You can use nohup. Something like
nohup java -jar IO_Server.jar &
The first line of the linked Wikipedia article says
nohup is a POSIX command to ignore the HUP (hangup) signal.

To add to Elliott's solution, another option is to use screen which allows you to open a "new window" run a command and detach from that window. Then, even when you're logged off, the command is still running, and you can re-connect via ssh and re-attach to that window and continue from where you stopped.
Here's a "getting started guide" to screen.

Run Java programs from PHP in a sandbox

I have a little question: we have to run Java programs and parts of the code will be uploaded by the users.
So I want to know what's the best way to run them? I know 2 possible ways,
exec("javac Usercode.class") and then run the whole thing with exec("java Main"), but I tried it with exec() and it don't work. maybe because the http is not root? But I don't know exactly why.
http://php-java-bridge.sourceforge.net/pjb/ ?
Any suggestions?
And another question is, how can I run these programs in a sandbox. we have a Debian server and so it's no problem to execute the command with a limited time, but is there a possible way to run the whole code in a sandbox?

Ideas for sandboxing:
Run in a chroot using e.g. Debian's schroot command. Protects against them accessing files outside of the chroot but not against them doing things like opening sockets etc.
Each user has their own Linux username against which they validate. Commands will then be run under the appropriate username (e.g. by using sudo or a set-uid executable).
Maintain a pool of virtual servers - expensive and complicated but gives best isolation.

Running Java UI program though unix

I want to facilate my client to run java program through UNIX command prompt using some shells. It'll look more effecient if they would be able to give input through some GUI. So it can be tested immedietely. I dont want prefer unix commands fro input.
Can somebody tell me how to run Java swing or applet programs in UNIX?

As Thompson mentioned, looking at Java Web Start could be a good idea.
Otherwise, if what you want is to execute, using a *NIX-like terminal, an application located on a remote host and have it rendered on your local display, then you need to do a few things:
you need a working X server on the local machine
you need to export the DISPLAY to the local machine (you can do this by setting up the DISPLAY environment variable on the remote system)
then you need to start your Java app from the command-line.
Hope this helps.
Here's an example of how to export your display over SSH.

Java programs use the X windows system (just like any other GUI on Unix). Assuming your X windows system is setup correctly, you should just open up a JFrame and do your GUI coding just like Windows.

Using the command prompt to launch a GUI is so last millennium. If you can distribute from a server, look into Java Web Start to provide the end-user with a simple and painless install.
Oh, and of course, follow Starkey's advice to throw a JFrame into the mix.

If you have an X-server installed locally, Putty can tunnel the X11-graphics generated by Linux Java back from the server to your local machine, and view it there.
If the above doesn't make sense to you, your next best bet is either running the Java code locally with Java Web Start (and code it to communicate back to the remote server) or run Servlets inside a Java Web Server running on the remote host.
In other words, GUI over a Putty connection is not something which is easily done.