JAVA question (somewhat GUI related)

[purbeast0]

So a project I'm working on at work is incorporating a 3rd party library that we're going to use. Included in the library is an applet that we are going to incorporate into our actual application.

The applet is going to be added to a class that extends JDialog and will be on a modal dialog.

As of now, the applet is pretty buggy. I've seen it crash randomly, and I can't get it to happen consistently. I have been told the library we're using now is a beta version and we're gonna have a better one from the 3rd party company soon.

However as of now, sometimes the applet is causing our application to crash. It's not throwing an exception or anything of that nature. It's simply just crashing and makes the application terminate. No errors or anything - the app is just totally killed.

So my question is, is there anyway that I can handle a crash in the applet so that it won't crash the whole application?

I tried putting a try/catch around where the dialog displaying the applet is created and used, but it's not hitting the catch (catching just a general Exception object). That did not work and I still saw it just close out the application.

So does anyone know if there is some other way I can handle this?

Another solution that I did was create another little application that was basically just that dialog pop up, from another JAR file. And when it crashes that way, it at least does not crash our whole application. However I'm trying to keep it all contained in our application if possible, but this quality and crashing isn't looking to good so far.

 

[Aikouka]

I've done a bit of GUI work in Java, but I've never worked in a situation like you're describing. Although, it sounds like the applet could be catching the exception and terminating?

As to your try/catch, I'm wondering if there's a chance that they would never catch the exception, because it would be occurring off of a different thread. Any GUI application would at least have a thread for the actual GUI elements and a separate thread for control (the main thread or whatever).

 

[degibson]

Run the applet in a subprocess.

 

[Ancalagon44]

What IDE are you working in?

If its a netbeans based IDE, you can get it to stop on all exceptions. Most probably the applet is throwing an exception that you arent catching, and neither is the IDE. When you debug it, can you step into the source code?

Try adding an exception breakpoint for java.lang.Throwable.

 

[purbeast0]

Run the applet in a subprocess.

that is what my last paragraph I explained was doing, sorry if that wasn't clear. i am just trying to keep it in the same process (if possible to stop this crash) because it's cleaner.

as far as the IDE, i am developing in netbeans and building from the command line with an ant script. however i am developing this on linux, and it's being ran from my windows machine (connecting to the deployer and jboss server on my linux machine).

unfortunately, this environment here is setup that i can't easily debug windows from my linux machine, and i can't get the source onto the windows machine. and i can't run this applet on linux because it's loading dll files.

 

[purbeast0]

well i just made the decision that I'm going to just simply go with the option to make a minor external application that runs the applet that will be called in a subprocess. so problem solved!

 

[Aikouka]

Does your vendor provide the source code for the applet? I still have a feeling that they're catching the exception (or just hitting an error condition and there is no exception) and doing their due diligence P) by exiting the application.

 

[purbeast0]

Does your vendor provide the source code for the applet? I still have a feeling that they're catching the exception (or just hitting an error condition and there is no exception) and doing their due diligence P) by exiting the application.

no they do not, and they aren't going to be either.