how to create an applet parallel to a process to show progress - java

i want to create a applet which paints a running ball while a process a running in the Java application . I have no idea how to synch the process time with the applet life . Help please ??

Applets run in a browser controlled JVM, that is completely separate from the JVM executing your program, but can do anything a normal Java application can do.
Therefore the problem here is actually, how you can have one JVM ask another JVM for information and you have several options depending on your need and skills.
I would suggest you look into JMX which is usually used for these kind of things, and if inapplicable then the EndPoint class which provide a tiny web server to your application.

Related

Releasing JavaFX resources

I have a JavaFX application, when the user closes the window, I want to destroy all of the JavaFX related resources and only have a tray icon, where the user can then reopen the application.
I have many background threads running, which should stay running when the GUI is closed. I have tried using Platform.exit() however it has no impact on the RAM usage of the program.
What is the best way to accomplish this? My goal is to reduce the impact on the system from my program as much as possible when the application is closed, but still running all of the background threads.
One option is to run the application as a separate process, launching the process when you want to create the application and exiting the process when the application is no longer needed (so completing a full application lifecycle). That way you will be absolutely sure that the application is not consuming any resources when it is not being used, because it won't be running.
How you would accomplish the launching and any communication between your tray service and the application would be up to you. You can research various mechanisms and, if you decide to go this route, ask some new follow up questions on accomplishing certain aspects of the task.
Some example routes you could look at are the ProcessBuilder, which is admittedly a pretty finicky and horrible API or the new Process API updates that will be available with Java 9. If wish to ensure at most a single instance of the application process is ever used, there are solutions for that. If you need to send a signal to the running application process, you could use something like RMI or run a basic HTTP REST server in your application and send messages into that.
As an aside, years ago there used to be some ongoing work on building multi-process JVMs, but there was never any wide uptake of the idea for Java. Though most modern browser clients, such as Chrome and Firefox, are multi-process architectures, the linked articles give some insight into this architecture, some of the potential implications of it and why it used for those applications.
Before going such a route, I would advise you to ensure that such an approach is truly necessary for your application (as pointed out by user npace in comments).

Can I use a java policy file to safely run an un-trusted app with sudo

I'm running a J2SE application that is somewhat trusted (Minecraft) but will likely contain completely un-trusted (and likely even some hostile) plugins.
I'd like to create a plugin that can access the GPIO pins on the Raspberry PI.
Every solution I've seen requires that such an app be given sudo-superpowers because gpio is accessed through direct memory access.
It looks like the correct solution is to supply a command-line option like this:
-Djava.security.policy=java.policy
which seems to default you to no permissions (even access to files and high ports), then add the ones your app needs back in with the policy file.
In effect you seem to be giving Java "sudo" powers and then trusting java's security model to only give appropriate powers out to various classes. I'm guessing this makes the app safe to run with sudo--is this correct?
Funny that I've been using Java pretty much daily since 1.0 and never needed this before... You learn something new every day.
[Disclaimer: I'm not very convinced by the Java security model.]
The way I would solve this is to have the code that needs to access the hardware run as a separate privileged process, then have your Java application run as an unprivileged process and connect to the privileged process to have it perform certain actions on its behalf.
In the privileged process, you should check with maximum distrust each request whether it is safe to execute. If you are afraid that other unprivileged processes might connect to the daemon too and make it execute commands it shouldn't, you could make its socket owned by a special group and setgid() the Java application to that group by a tiny wrapper written in C before it is started.
Unix domain sockets are probably the best choice but if you want to chroot() the Java application, a TCP/IP socket might be needed.

How to start Tanuki Software Wrapper automatically on interval of 2 hours

I am using Tanuki Software Wrapper for building a java application as Windows Service . I follow the example Simple HelloWorldServer Java Class and it works fine . I have made configure in wrapper.conf file wrapper.ntservice.starttype = AUTO_START for automatically starting the service on windows system starting .
But i want that my service would be automatically started on every two hours , how can i do it , if any one has idea please help me .
Thanks a lot in advance .
Finally I have done through following configuration in the wrapper.conf file as
wrapper.pausable=TRUE
wrapper.pause-on-startup=TRUE
wrapper.timer.1.interval=minute=120
wrapper.timer.1.action=restart, resume
wrapper.on_exit.default=PAUSE
It basically pause the wrapper action after main jvm(java application) is closed , and then after 2 hours it automatically restart wrapper's local JVM and resume the required output with updated data .
Thanks to all for trying to help me .
It's better to keep your java application running, and schedule tasks from within your application.
E.g. use http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ScheduledExecutorService.html
If you schedule a task in your main() method, a new Timer Thread is started, so the application will keep running after the main() has ended, and keep executing the scheduled task at the rate you specified.
Ajeet,
As GreyFairer said, it is usually a good idea to run tasks from within the JVM, especially if they happen often.
The Wrapper's ability to stop and start the JVM using the pausable feature definitely works as well. This approach can be better if your JVM is large, and the task it needs to complete is relatively infrequent. There is a bit of load to launch a JVM.
Relaunching the JVM as you are doing also has the benefit of allowing you to change the configuration for each invocation if you combine configuration include files with the wrapper.restart.reload_configuration=TRUE property. You can modify the include file as needed so each JVM runs with the needed information. (There are of course ways of getting the same results within a single JVM invocation if needed.)
Cheers, Leif

Opening a new command prompt and writing to it in Java

The idea behind this is that I have a main class that acts as an agent, constantly running and waiting for instructions. Then, the agent gets instructed to launch n instances of another class which plays a monitoring role.
Since each instance of the monitoring class is going to be doing heavy printing (plus the fact that the agent class also prints a little bit), I would like for each instance to have its own command window to do all its printing to.
Is this possible? If not, I welcome suggestions on how to get a similar effect.
Thank you.
EDIT: I feel like some clarification is in order. I want to start a new command/terminal window per monitoring instance and regularly write to that window.
I would obviously love to be able to run this on any machine, but at least I'd like to it to be able to work on Windows.
I know that there are some GUI libraries available (AWT, Swing) but I want the application to be as lightweight as possible, so that I can maximize the number of monitors that I can have on each computer. I will use a GUI library only if I have no other option.
First of all, if an instance is running for a long time and you may require multiple of those running at the same time, you will need to implement multi-threading. In particular, look into concurrency: http://docs.oracle.com/javase/tutorial/essential/concurrency/
Next, once you figure out how to run each instance in a separate thread, you simply access Runtime:
Runtime RT = Runtime.getRuntime();
RT.exec("cmd.exe /c start command", null, new File(newDir)); // for example
There are plenty of GUI libraries that can do what you want. AWT is one see AWTConsoleWindow. Or this one.

Protecting against X11 Crashes in Java Applications that have a Swing Component

Is this possible?
With the right architecture, for many kinds of applications - sure.
Just split the GUI and "core logic" into separate processes, and have the GUI able to detect and reattach to the running backend process when you run it after the crash.
For extra robustness, given that an X crash can often take down the whole system, move to a classic client/server architecture with the backend running over the network.
No. X11 is the foundation for the window manager and then the Java Swing application that runs in that window environment. So if X11 crashes there's not much you can do.
In addition to what wrt said, your backend system could also watch for HeadlessExceptions, and handle them appropriately.
It is generally not practical for an X11 desktop application to recover from a crashed X11 service, whether it is written in Java or another language.
But it may be possible to prevent the problem happening to a Java app the first place. I recall having to deal with this a long time (5+ years) ago. Sun had a workaround that involved setting a system property to tell the JVM to not use 2D graphics acceleration. I cannot recall the details, but you may be able to find an equivalent solution on the Sun website.

Categories