Implementing Callbacks and/or Synchronize questions

[Richard Maher]

Hi,

I have an Applet that instantiates an object that in turn instantiates
another which run()s a Thread that trundles away. Now, if it all goes
pear-shaped in the thread, I want to be able to asynchronously call back
into the applet object and tell it to "do something".

A quick look around leads me to believe that I should create a callback
interface and have the Applet implement it. Then have the Applet pass itself
to the threading-object's constructor and, if something goes wrong, the
thread can cast the applet to the interface and invoke the "callback"
method. Will it work? (I'm off to give it a go, but in case it doesn't (or
if someone knows a "better" way) I'm happy to hear alternatives!)

If I'm forced to go to Plan B and shift the "do something" down-stream, can
someone please answer the following Synchronize question for me? Is the
synchronization behaviour of a "synchronized" method functionally equivalent
to a non-synchronized method that wraps everything in a "synchronized (this)
{}" block?

IOW, will a synchronized block on an object
play-nicely/synchronize-correctly/block with any synchronized methods that
object may contain?

Cheers Richard Maher

 

[Joshua Cranmer]

A quick look around leads me to believe that I should create a callback
interface and have the Applet implement it. Then have the Applet pass itself
to the threading-object's constructor and, if something goes wrong, the
thread can cast the applet to the interface and invoke the "callback"
method. Will it work? (I'm off to give it a go, but in case it doesn't (or
if someone knows a "better" way) I'm happy to hear alternatives!)

Well, given such a vague problem statement, I can't answer with anything
other than "maybe."

If what you need to do is to alert the GUI, the best answer may be to
dispatch an event via SwingWorkers (you might look at
java.awt.Component's firePropertyChanged methods for code isolation).
Perhaps implementing the interface might be better down in inner classes
or anonymous ones as well--it depends on the situation.

If I'm forced to go to Plan B and shift the "do something" down-stream, can
someone please answer the following Synchronize question for me? Is the
synchronization behaviour of a "synchronized" method functionally equivalent
to a non-synchronized method that wraps everything in a "synchronized (this)
{}" block?

Assuming it's an instance method, yes. Static methods synchronize on the
class object itself. See
<http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.4.3.6>.

 

[markspace]

Hi,

I have an Applet that instantiates an object that in turn instantiates
another which run()s a Thread that trundles away. Now, if it all goes
pear-shaped in the thread, I want to be able to asynchronously call back
into the applet object and tell it to "do something".

This ought to be interesting, since there's probably many ways to
accomplish this. I'm looking forward to the different replies here, I
normally learn stuff.

Just to be contrary, why not just make some exit status and set that
before your pear-shaped thread exits?

public class ThreadWithExitStatus extends Thread {

private volatile int status;

public int getStatus() {
return status;
}
}

This'll need some additional work (like more constructors) but gives you
the idea. Note I obviated the need to use "synchronized" by making the
shared variable "volatile".

Will it work? (I'm off to give it a go, but in case it doesn't (or
if someone knows a "better" way) I'm happy to hear alternatives!)

Might work, depends. See answer to synchronized block below.

Another way to do this is make a thread safe queue and pass a value on
it to the parent thread. This is self-contained and thread safe, like
the status example above. For example:

IOW, will a synchronized block on an object
play-nicely/synchronize-correctly/block with any synchronized methods that
object may contain?

As Joshua note, yes, it's the same and plays nicely. But a little alarm
bell is ringing in my head. The most obvious way of doing this involves
only one thread taking the lock (calling the synchronized method) and
the other thread just polling it's own internal variables. This WILL
NOT WORK. Both threads must take the same lock or no synchronization
occurs. Be very careful here how you implement it.

 

[Roedy Green]

A quick look around leads me to believe that I should create a callback
interface and have the Applet implement it. Then have the Applet pass itself
to the threading-object's constructor and, if something goes wrong, the
thread can cast the applet to the interface and invoke the "callback"
method. Will it work? (I'm off to give it a go, but in case it doesn't (or
if someone knows a "better" way) I'm happy to hear alternatives!)

The key fact that will likely foul you up is ALL Applets on a page
share a single thread. You can't dither or other Applets won't be
able to process any events.

In particular if one Applet goes into an infinite loop, that will hang
all Applets on the page.

--
Roedy Green Canadian Mind Products
http://mindprod.com

If everyone lived the way people do in Vancouver, we would need three more entire planets to support us.
~ Guy Dauncey

 

[Richard Maher]

Hi Joshua,

Thanks for the reply.

Well, given such a vague problem statement, I can't answer with anything
other than "maybe."

Sorry to be vague but it's ok; Plan A works like a charm!

If what you need to do is to alert the GUI, the best answer may be to
dispatch an event via SwingWorkers (you might look at
java.awt.Component's firePropertyChanged methods for code isolation).

Most of the example GUIs are in JavaScript +/- Flex, but my code is designed
to yield a generic, single sign-on, single persistent network connection,
server access tool, that takes up no GUI real-estate on the HTML page(s) it
serves. There are a couple (soon to be 3) AWT dialog boxes to facilitate
user authentication and console, but (hopefully) the toolkit in use has been
abstracted away for easy replacement/preferences.

Perhaps implementing the interface might be better down in inner classes
or anonymous ones as well--it depends on the situation.

Nah, it's all good.

Assuming it's an instance method, yes. Static methods synchronize on the
class object itself. See

<http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.4.3.6>
..

What a fabulous link! Thanks for providing it - Just what I was looking for.

Cheers Richard Maher

PS. The Tier3Client package supports application-level granularity with
multiple application connections available over a browser-instance, or
TabSet/PageSet! (Even multiple connections/applications from the same page
if that tickles your fancy.)

 

[Richard Maher]

Hi Roedy,

The key fact that will likely foul you up is ALL Applets on a page
share a single thread. You can't dither or other Applets won't be
able to process any events.

Nah, the "key fact" you missed (or rather I wasn't explicit about) is that
the Applet doesn't wait for thread completion before returning to the
JavaScript/browser. So to set the scene: - the EDT(s) are doing what they do
best unencumbered by me, the user is typing/clicking away madly, when it all
goes tits-up in the thread. Then ***and this is (one of) the really sexy
bits!*** the session-global, statically maintained, thread runs through all
subscribing tabs logging them off! Oooh!

You know you want some of that - No? (Oh well, maybe it's just me

In particular if one Applet goes into an infinite loop, that will hang
all Applets on the page.

Yep, if you hit yourself on the head with a hammer it really hurts all
right.
Cheers Richard Maher