I'm using AWT, and specifically a TextField component with an added java.awt.event.FocusListener to receive events when a User focuses in and out of the TextField.
This is just an introduction, not my real issue, and the important features of my class is down below if it helps put things into perspective (minus AWT's window close events listener, so you can't close the window unless you use the Control+C keyboard, Java's cut-off shortcut on Windows/Mac OS X (at least), at the command line/terminal).
Now, my question, when Java calls a method when does the method return instantly, when does it block until completed? I have heard that the Java GUIs (Swing, AWT) has an events dispatch thread which will trigger my listerners, and I have also heard that these event calls can block waiting for methods to return. So, I want to avoid hogging the GUI event thread. I'm trying to decide if I should use a Thread/Runnable or a method call, or even just run logic on the event dispatch thread.
I want to find out when and how I can start methods then return instantly?
Is it methods with void return type? Can Java just run them and instantly return because it doesn't need to wait for a return to be computed?
Okay, yes, I do know about Threads/ Runnable, but I really want to know how Java chooses to wait for a method or when to move on.
Is it safe to start a thread from an Event Listener ? I mean if event calls really block until finished, I think, it might become stuck waiting for any Threads, if defined in the event call method, to finish and become garbage collected before it can continue other event calls.
Wouldn't that blockage also happen if an Event listener calls a method to do the work?
Why are you not using Swing?
In AWT, you had to add a listener (I think a WindowListener) to its top-level container, with an implemented windowClosed (or windowClosing) method which would close the application. You should finish writing all files, etc, before closing the JVM. In Swing, you can specify a behaviour; DISPOSE might be the best for your purposes. You will find more details in the JFrame documentation.
Methods in Java™ neither block nor return immediately, or only if you get deadlock, an infinite loop etc will they block. They execute their statements and then return. A method like this . . . may return in a few nanoseconds, but it is not quite immediate. So the thread in which that method is called will execute that method, then control returns to wherever that method was called from, and the next statement is executed, maybe this sort of thing: int i = add(123, 456);
It says in the API documentation to look at AWTEvent for details of the event model.
I do not know whether AWT components are thread-safe, but I know that Swing components aren't. So you should only manipulate objects of any Swing classes from the Event Dispatching Thread (EDT). Anything which takes a long time can be executed in its own thread, provided it doesn't access any Swing components. Maybe you should apply the same restriction to AWT components.
Try Swing instead.
Make sure to start the EDT with invokeLater or similar.
Use a class which creates threads for anything which takes a long time, SwingWorker is one example.
This discussion would sit better on the GUIs forum, so I shall move it.
Actually, my question isn't about choosing which GUI to use, I'm just adding some background information about my program, but rather I want to know what is the recommended way to start an event listener going.
Tasks such as setting a single variable are usually very fast (<0-1 ms), but add method calls to a java.text.Format subclass, a try-catch block (which could generate a stack trace even if I don't use it), and finally set a condition to return a parsed String to the TextField, if try was successful, or provide a visual warning, if an exception was thrown, to an event listener could cause some serious lag time in a GUI refresh cycle.
That makes me think it would be wise to use Threads. However, if I start a Runnable from a Thread created in the Event Listener, I think one of two things will happen:
1. The Listener has a reference to a Thread object, which won't expire until it is finished running, still blocking the Event Dispatch Thread, even though a Thread' start() call should return right away.
2. The Thread is created and started from the event listener, which then returns instantly, but then there isn't a reference to the running thread making it eligible for garbage collection.
For your information, I'm using AWT because it is the first GUI in Java, and hooks into the native OS toolkit, so it should be more compatible with early versions of Java such as version 1.1), with less overhead. I also hear conflicting reports that AWT uses a multi-threaded event model and I want to see what that is about.
And, yes, you can close a AWT window by implementing the java.awt.event.WindowListener interface and using the windowClosing() method. I just wanted to warn people who might try to run the program that I didn't implement window events yet.
As for why I'm targeting 1.1, I had a wake up call when I went to Stat Owl's Java Market Share page. Undetected versions was >20%, and no it wasn't 1.7. I have visited there before the 1.7 release and still several undetected versions. Altering the URL to show Java Version 1.3 Usage, I can see that even today there are still Java 1.3 JREs running.
Stat Owl depends on Java Web start, which was added in version 1.3 of Java, so they can't detect earlier versions. That means the average web user can't or won't update their Java version. If this is anything like HTML standards, it's not unusual to see +10 year hold outs.
Prior to Java 1.5/6's auto update, updating Java was a chore. I think it's reasonable to assume that no one but tech-heads and Java developers would try to update their software. And, many users of platforms in the late 90s, early-2000s time period are stuck with their OS's or Browser's integrate Java engine, often Java version 1.1. Sometimes 1.3 or 1.4 if they bought their computer with Java pre-installed in the mid-2003-5 ish.
So, I think, Oracle's end of life cycle is wrong. It might take 3-5 years for current Java versions to enter the mainstream after being released, not the end of a version being useful (10 year hold outs), and that's mainly because people appear to be upgrading because they buy new computers with Java pre-installed.