We Keep Coding

Can you make an uncloseable, unleavable, Java application?

Is there a way to make sure that a user cannot close or leave my Swing application? I've tried to make it fullscreen, but you can still Alt-Tab away from it—and besides, that doesn't work well when you decide to use JOptionPane's dialogs.
So, is there any way to make a user use only this one Java program on a device?
Edit: Some people wonder about the purpose. The application is supposed to be sorta "embedded" into the handheld device (which runs under Windows), so the users of the device will use it as we intend it to be used—for example, that they won't play Freecells or do something worse instead of doing the actual work. Have you seen ticketing kiosks? They are locked down pretty well, you can't just close their big flashy GUI and get to the Windows desktop!

Okay #Daniel showed you how to make a Java app un-closeable (+1 to him) by calling:
JFrame#setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
on the JFrame instance.
To make sure you cant leave it i.e by pressing CTRL+ALT+DEL and ALT+TAB etc you may want to do this (applies to windows only):
1) Disable TaskManager/CTRL+ALT+DEL by:
Setting registry key:
HKCU/Software/Microsoft/Windows/CurrentVersion/Policies/System/DisableTaskMgr = 1
via reg script or cmd.exe.
2) To disable all shortcuts together like ALT+TAB etc see here (Download/use the *.reg script and execute it via cmd).

Uncloseable yes, you can use setDefaultCloseOperation(); and pass it JFrame.DO_NOTHING_ON_CLOSE
Example:
import javax.swing.*;
import java.awt.*;
class app extends JFrame {
app(String title, int height, int width)
{
super (title);
setSize(width, height);
setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
setVisible(true);
}
}
class program {
public static void main(String[] args) {
app myApp = new app("Hello", 350, 750);
}
}

We do something similar with a POS application, but we cheat a little bit. While making use of Full Screen helps a lot, we found users could STILL exit the application.
In the end, we created a Windows Service (yes, we run on Windows) that automatically RESTARTS as soon as it's closed. So, you can see the Windows desktop (we removed the icons) for a split second, but then the app pops up again. The benefit of this is also that we can update the JAR file remotely, from the intranet, and all the users need to do is push a button that closes the system, it restarts automatically and is updated. We wanted to use WebStart, but had problems integrating it with our wrapper.
The wrapper itself is a Python application that just starts the JVM and application, compiled to an EXE. Simple, but effective.
The net effect is a closable application that will automatically start itself again. Good enough for our use where we need to user to be able to do one thing and one thing only. Giving the startup credentials for the application Admin privileges, and the users just a normal account, took care of the pesky 'alt-ctrl-del' users as well. You can't kill a process that's got higher access rights than yourself.
If you don't feel like writing your own wrapper, give http://wrapper.tanukisoftware.com/doc/english/product-overview.html a whirl, it looks like a brilliant product.

You can catch pretty much any keystrokes you like (and have them ignored) in your app, so Alt-Tab can be fixed. The one key combination that an application can never (ish) handle itself, is the Ctrl+Alt+Delete, which is hooked into the kernel in many operating systems for security reasons. As a side note: this is why many login screens ask you to hit C+A+D before entering your username and password.

You can make a maximized window that can't be unmaximized or closed. You'd also have to trap certain keystrokes such as CTRL+SHIFT+ESCAPE, ALT+TAB, WIN+[anything], various Fn keys, and you'd have to do something to prevent CTRL+ALT+DELETE from working (Either from showing the task manager or from bringing up the blue options screen in windows vista or 7.
I believe there are windows API calls that can change the behavior of CTRL+ALT+DELETE somehow but have no idea what they are. A good place to investigate would be Sysinternals Process Explorer, which has the functionality to replace the task manager. Figure out how it does this, then replicate it.

Using print dialog from applet makes browser window unresponsive

I have a ten-year-old applet that wraps itself around the Crystal Reports Viewer applet in order to handle some custom features. It has worked satisfactorily, displaying and printing reports as designed. The web-app provides data selection, and then generates the HTML to invoke the applet with the correct parameters via an AJAX call.
I have one user (so far) who experiences the following problem: after generating the applet and viewing the reports, she prints the reports. Once the print dialog has appeared, even if it is cancelled, the following things no longer work:
the Close link which is supposed to clear out the generated applet HTML no longer works;
the navigation links to other pages no longer work: they dim appropriately when the mouse hovers over them, but the browser does not respond to clicking on them;
the window cannot be closed, whether
by clicking the X in the upper-right-hand corner,
by clicking on the system menu and selecting Close,
by right-clicking on the entry in the task bar and selecting Close, or
by trying to invoke the File/Exit menu item (I believe the File menu is disabled);
clicking on the window title-bar no longer makes it appear active.
In order to close the window, one has to start the Task Manager and end the iexplore process.
It may be that this is another occasion where the applet is retaining focus and it should not: similar bugs such as
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4838000
are reported as being folded into a bug I can no longer find in the Java bug base:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4918282
There are also reports of invisible applets retaining focus: it might be that the custom applet is invoking the original Crystal Reports applet in some way, but I didn't myself develop this code, just the wrapper that drives it.
I do not believe I have a case where a dialog of some sort is appearing behind the IE window; I should think that would occur on more than one system, and this appears to be unique to this user, but the system looks like one of our stock images.
There are also reports of printing locking up an IE window until printing is complete, where the solution is to put the printing into another thread. In my case, it is unnecessary to actually print: invoking the Print dialog and then cancelling it is enough to cause the buggy behavior.
I would like to understand what's going on here, and get things running for this user if possible. I'd appreciate any reports of similar experiences, or directions to look that I've so far missed.
Some version notes:
Win XP Pro: 5.1.2700 SP 2 Build 2600
IE: 7.0.5730.13
Java JRE: 1.6.0_31-b05
Printer: Imagistics 2500 USB printer (on the off chance)

zombie java interpreter after launching applet prevents java console to reappear if relaunched

I have a java application that can be run as a JFrame or as an applet.
Launching the applet in the browser adds a new tab in the browser and also makes the Java Console appear. After I close both of them, I expect to be able to repeat this operation and see the Java Console reappear. It does not reappear, however I can reload my applet in the browser.
Everytime I have to kill this zombie java interpreter process launched by firefox.
/usr/lib/jvm/java-6-sun-1.6.0.26/jre/bin/java -D__jvm_launched=22906841394 -Xbootclasspath/a:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/deploy.jar:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/javaws.jar:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/plugin.jar -Djava.class.path=/usr/lib/jvm/java-6-sun-1.6.0.26/jre/classes -Dsun.awt.warmup=true sun.plugin2.main.client.PluginMain write_pipe_name=/tmp/.com.sun.deploy.net.socket.1444.1704699298565364673.AF_UNIX
After killing the process, the Java Console will reappear. Also tried the repro steps with chromium, it's the same result except the zombie process' commandline is different.
Things to note:
When I close the browser tab containing the applet, the applet is in a normal state, waiting for the user to perform actions on the UI.
Closing the browser completely between applet relaunches will also fix the problem since the java process is a child of the browser process.
Anyone has an explanation or workaround? Thanks!

Anyone has an explanation or workaround?
For the work-around, test in the applet viewer. (The console is not relevant to production, unless the design is very flawed.)
As to the explanation, a browser will end the JRE/console when/if it feels like it. It is not up to the developer or applet to override that. I've noticed that FF will typically leave the JRE running for 30-60 seconds after leaving an applet page (judging by when the console vanishes).

It's not a zombie, by which I imagine you mean to imply something is going wrong; this is just how the Java plug-in has always worked. The first time it's needed, it starts up, and this may involve opening the console, depending on your settings. It will then continue to run until the browser shuts down. In other words, this is not a bug, but a feature.
Some browsers include a menu item for opening the Java console; you could use that to reopen it as needed, without killing or restarting anything.

Is there a way to detect browser closing in JApplet?

There are certain configuration files that the user should save before closing the browser. Is there a way to detect if the user is trying to close the browser and to warn them to first save the files?

You should define a public method inside your applet and invoke it using Javascript before the user closes a page:
window.onbeforeunload = document.YourApplet.YourMethod(event);
where YourApplet is your applet's name attribute: <applet name="YourApplet" ...
and YourMethod is the method you defined in your applet.

You can use javascript to detect this. And you can invoke applet methods from javascript.
So you should define a javascript onunload handler which invokes your applet's close method.

Generally the PlugIn will try to stop the applet once the browser window (or just tab) closes or navigates elsewhere.
IIRC, you used to get 20 seconds to do your clear up before the PlugIn started getting medieval. I believe if there are no other applets sharing the JVM, the process will now get killed if you don't stop.
So, you really don't want to be hanging around attempting to show annoying save dialogs. I would go so far as to say, you don't want annoying save dialogs. So just do the saves quietly. Add a "you didn't save, do you want to restore these changes" thing (like the re-open windows dialogette beneath the toolbar in Chrome) when restarting. For extra marks, log deltas periodically in the background, so that even in the case of abrupt termination or network failure the data can be restored.

IE Browser hangs after opening a file dialog. Workaround?

This is a registered bug (Bug ID: 6515708) but does anyone have a workaround for it?
Scenario
javascript calls OpenDialog() method in applet
applet starts new thread which opens the AWT FileDialog
on completion, the file name is read and the javascript method OnDialogComplete is called
At this point the dialog is disposed and (on some browsers only) the browser hangs.
We have a mixture of XP with IE6/7 and Vista with IE7 but unfortunately the bug appears randomly on any of them.
Ideas anyone?

The bug report suggests it only happens when two FileDialogs are open at once. Perhaps you could detect when the Java implementation is affected (pre-1.6.2), and in that case use an inter-applet-communication method such as a static variable on a class, to implement a mutex preventing OpenDialog() from working when there is already a FileDialog in progress?