Re: instability in Frame disposing - sbb Linux_JDK_1.1.5_v7
I am forwarding the following message for my colleague Norm Shapiro.
Steven C. Bankes, Ph.D.
Managing Partner
Evolving Logic Associates
3542 Greenfield Ave.
Los Angeles CA 90034
310-836-0958
[EMAIL PROTECTED]
[EMAIL PROTECTED] (Nelson Minar) writes:
>I'm still getting some occasional instability when disposing of Frames
>in the Linux JDK - I get IOT trap/Abort. My application is crashing
>randomly and it's driving me nuts. Is there anything I can do to help
>find this bug (I can send complete class files and instructions that
>crash the system fairly often)? Can anyone think of a work-around?
>
>The crash happens right when I call Frame.dispose(). I'll include the
>stack frame for the running thread when the thing dies. The frame
>contains several components: a Label, a TextField, and a Button, all
>in a FlowLayout.
>
I have had similar problems with JFrame. My workaround, which has been
generally successful, was to subclass JFrame. In the subclass I override
dispose (and also setVisible()) with a method that forks off Thread with a lower
priority than the current thread. The actual disposal or setVisible(false) is
done in the forked thread.
Here is the subclass.
import com.sun.java.swing.*;
import java.awt.*;
import java.awt.event.*;
public class AFrame extends JFrame implements Runnable, WindowListener
{
boolean mustDispose=false;
boolean disposed=false;
boolean mustHide=false;
Window master;
AFrame(String title)
{
super(title);
}
public void dispose()
{
if(disposed)
return;
mustDispose=true;
fork();
}
protected void fork()
{
Thread thread=new Thread(this);
thread.setPriority(thread.getPriority()-1);
thread.start();
}
public synchronized void run()
{
if(mustDispose && !disposed)
{
disposed=true;
super.dispose();
}
else if(mustHide)
{
super.setVisible(false);
mustHide=false;
}
}
public void setMaster(JComponent masterArg)
{
master=(Window)masterArg.getTopLevelAncestor();
master.addWindowListener(this);
}
public void setVisible(boolean visible)
{
if(visible)
super.setVisible(visible);
else
{
mustHide=true;
fork();
}
}
public void windowClosed(WindowEvent e)
{
if(e.getWindow()==master)
dispose();
}
public void windowActivated(WindowEvent e){}
public void windowClosing(WindowEvent e){}
public void windowDeactivated(WindowEvent e){}
public void windowDeiconified(WindowEvent e){}
public void windowIconified(WindowEvent e){}
public void windowOpened(WindowEvent e){}
}
===
Norman Shapiro
5011 Mattos Ct
Fremont CA 94536-7170
(510) 795-1800
[EMAIL PROTECTED]
--- End of Forwarded Message
Re: instability in Frame disposing - sbb Linux_JDK_1.1.5_v7
Norm Shapiro wrote: > [EMAIL PROTECTED] (Nelson Minar) writes: > >I'm still getting some occasional instability when disposing of Frames > >in the Linux JDK - I get IOT trap/Abort. My application is crashing > >randomly and it's driving me nuts. > I have had similar problems with JFrame. My workaround, which has been > generally successful, was to subclass JFrame. In the subclass I override > dispose (and also setVisible()) with a method that forks off Thread with a lower > priority than the current thread. Is Nelson's application multi-threaded? I'm pretty new to this Java game, but it appears to me that the AWT's dirty little secret is a lack of thread safety. The closest thing I've found to relevant information is in the documentation for Swing -- which states explicitly that Swing is not thread-safe, and that all GUI access, after the GUI is instantiated, needs to happen from the AWT Event thread. This means that GUI activity either has to take place in an event handler, or must somehow be triggered from the event thread. Swing even provides a trick (SwingUtilities.invokeLater()) that makes it easy to push an activity into that thread. Having said that, I've seen absolutely nothing anywhere claiming that AWT is not thread-safe. On the other hand, I've found that adopting Swing's approach has solved my GUI reliability problems. Norm's approach sounds suspiciously similar. Nathan Meyers [EMAIL PROTECTED]
Re: instability in Frame disposing - sbb Linux_JDK_1.1.5_v7
>>My workaround, which has been generally successful, was to subclass >>JFrame. In the subclass I override dispose (and also setVisible()) >>with a method that forks off Thread with a lower priority than the >>current thread. That's a clever workaround, but ugh! >Is Nelson's application multi-threaded? Yep, heavily. >I'm pretty new to this Java game, but it appears to me that the AWT's >dirty little secret is a lack of thread safety. AWT's threading is very strange and complicated (and update runs at the wrong priority), but I've never seen it do something unsafe. My impression is this is more like a Peer problem, that maybe the Peer implementation isn't safe. >The closest thing I've found to relevant information is in the >documentation for Swing -- which states explicitly that Swing is not >thread-safe, and that all GUI access, after the GUI is instantiated, >needs to happen from the AWT Event thread. This is certainly a requirement I can live with. But in this case, the dispose() only happens in an AWT Event thread. It's called when the user clicks on a button (stackframe included again) >On the other hand, I've found that adopting Swing's approach has >solved my GUI reliability problems. Norm's approach sounds >suspiciously similar. Actually, isn't it exactly the opposite, putting the call to Swing in some non-Swing thread? Here's that stack trace again - "AWT-EventQueue-0" (TID:0x407209c0, sys_thread_t:0x4154bf04, state:R) prio=5 *current thread* sun.awt.motif.MComponentPeer.dispose(MComponentPeer.java:215) sun.awt.motif.MFramePeer.dispose(MFramePeer.java:101) java.awt.Component.removeNotify(Component.java:2526) java.awt.Container.removeNotify(Container.java:1149) java.awt.Window.dispose(Window.java:177) java.awt.Frame.dispose(Frame.java:372) edu.mit.media.nelson.straum.agent.CreateAgentUI.createAgent(CreateAgentUI.java:70) edu.mit.media.nelson.straum.agent.CreateAgentUI$2.actionPerformed(CreateAgentUI.java:45) java.awt.Button.processActionEvent(Button.java:254) java.awt.Button.processEvent(Button.java:227) java.awt.Component.dispatchEventImpl(Component.java:1764) java.awt.Component.dispatchEvent(Component.java:1704) java.awt.EventDispatchThread.run(EventDispatchThread.java:63)
Re: instability in Frame disposing - sbb Linux_JDK_1.1.5_v7
Nelson Minar wrote: > >The closest thing I've found to relevant information is in the > >documentation for Swing -- which states explicitly that Swing is not > >thread-safe, and that all GUI access, after the GUI is instantiated, > >needs to happen from the AWT Event thread. > > This is certainly a requirement I can live with. But in this case, > the dispose() only happens in an AWT Event thread. It's called when > the user clicks on a button (stackframe included again) Oh, well... nice theory while it lasted :-(. > >On the other hand, I've found that adopting Swing's approach has > >solved my GUI reliability problems. Norm's approach sounds > >suspiciously similar. > > Actually, isn't it exactly the opposite, putting the call to Swing > in some non-Swing thread? I spoke too loosely. You're right, Norm's approach isn't much different from not doing anything at all: in either case, the GUI code (dispose) is being called from somewhere other than the AWT Event thread. The issue, as the Swing documentation points out, isn't about confining GUI access to one particular thread, it's about confining it to one thread *at a time*. Forcing everything into the AWT Event thread is a way to do that. Norm is doing something similar by putting the activity into a low-priority thread -- it's most likely to execute at a time that nothing else is going on. Nathan Meyers [EMAIL PROTECTED]
Re: [Q]: native method
I did both of following that, but didn't work. why does it work ? ln -s libHelloWorld.so.1.0 libHellWorld.so.1 ln -s libHelloWorld.so.1.0 libHelloWorld.so - takeru [EMAIL PROTECTED]
Unable to run java
Hi all Java-Linux freaks (there *are* other people on this list, aren't there?) I'd love to run Java and Swing on Linux, so I downloaded JDK1.1.6v2 and JDK1.1.5vX (for my intel pentium, 64 MB, Linux 2.0.30) Un-GZIP-ped the stuff, un-TAR-red. All went fine. Until I tried to run the script /usr/local/java/bin/java. It reported: File not found for the file /usr/local/java/bin/i586/green_threads/java. But the file does exist!!! When I try to run /usr/local/java/bin/i586/green_threads/java explicitly, I receive the same error message. When I do an ls, I'm told something like: rwxr-xr-x root root blabla java* The file is executable and it exists, so what's the problem. It is an ELF binary, but my kernel supports ELF. I use bash. When I print the return value, (echo $?) I receive 126, instead of the usual 127 if bash cannot find a file. The man page does not tell me what this means. I've written a C program that exec's the file for me. Result: file not found. Duh !!! Used to run JDK1.1.1 delivered on the Slackware distribution CD's... All went fine (except for Swing). WHAT'S MY PROBLEM Hope someone can help. Please!! (I'll let you have early access to some of my to-be-public Java code if you fix it! ;-) ) +-+ | "Come to me all you who are weary and burdened, and I | | will give you rest." | | | | -- Jesus Christ (Mt. 11:28) | +---+-+ | Ernst de Haan | email mailto:[EMAIL PROTECTED] | | Java programmer | web members.xoom.com/znerd/ | +---+-+ __ Get Your Private, Free Email at http://www.hotmail.com
Xemacs and Jacob
Hi, I'm trying to use Xemacs with Jacob and they working very well. However, I got a simple question. How can I control where the Xemacs and Jacob window come up? How about size? I notice that when Jacob comes up it make Xemacs smaller and then move itself to the corner of the page. But since I'm using NextStep, I can't see the edge of the screen. Is there some way to set it so that I can just issue one command and the two software will come up just fine? Thanks, Sze Yuen
Re: Visibroker for Linux and JDK 1.1.6v2 problem
Richard Jones wrote:
> org.omg.CORBA.UNKNOWN[completed=MAYBE]
> at com.visigenic.vbroker.orb.SE.read(SE.java:28)
Sorry to answer my own question :-) This topic seemed
to cause more discussion about how I ever managed to
get VBJ working on Linux than on the original problem.
Anyway, I solved it, and for reference here is the
answer. It's nothing to do with the Linux JDK or JVM.
It's caused by the server implementation method throwing a
java.lang.* exception, in this case, it was a
ClassCastException. Bizarrely, the server prints
nothing. Instead, VBJ seems to pass the exception
back to the client. The client, instead of doing the
right thing, throws a wobbler -- it turns the undeclared
exception into a CORBA.UNKNOWN and throws that instead!
I caught this fairly easily in the end by wrapping my server
method with a try { ... } catch (Exception ex) { ... }.
There you go ...
Rich.
--
Richard Jones [EMAIL PROTECTED] Tel: +44 171 598 7557 Fax: 460 4461
Orchestream Ltd. 125 Old Brompton Rd. London SW7 3RP PGP: www.four11.com
"boredom ... one of the most overrated emotions ... the sky is made
of bubbles ..." Original message content Copyright © 1998
List select and jdk1.0.x
I have to make an applet, which is supposed to work well on all Java enabled browsers. So because of this I do not use the new 1.1 features. Here is my problem : I have a list and I want to perform something when a list item is selected. The problem is that I cannot use action(Event,Object) because is get called only when I double click on the selected item. I know, in Java >1.1 I could use the ItemListener to detect when an item is selected or deselected. How can I do this without using 1.1 features ? Thanks, Stefan Toth --
Re: [Q]: native method
[posted & e-mailed] Takeru Tamayama wrote: > Hi, >I want to use IrDA on linux & java. >but, I have a problem in making native method. > This is very easy test program, bat don't work. > My jdk is jdk-libc5-1.1.5-v7 > > I did following commands. > > 1.javac HelloWorld.java > 2.javah -jni HelloWorld > 3.gcc -fPIC -I/usr/local/java/1.1.5/include > -I/usr/local/java/1.1.5/include > -c HelloWorldImp.c > 4.gcc -shared -Wl,-soname,libHelloWorld.so.1 -o libHelloWorld.so.1.0 > HelloWorld.o > 5.ln -s libHelloWorld.so.1.0 libHelloWorld.a > > following is the source and ERROR message. > Does anyone have some further information or hints for me what to do ? > > Takeru Tamayama [EMAIL PROTECTED] [snip-code + error msgs. (total dump!)] Hi- I am using JDK1.1.6 and your HelloWorld works, with a few changes: 2. gcc -fPIC -I/usr/local/jdk1.1.6/include -I/usr/local/jdk1.1.6/include/genunix -c HelloWorldImp.c [you need /genunix] gcc -shared -Wl,-soname,libHelloWorld.so.1 -o libHelloWorld.so.1.0 HelloWorldImp.o [must be HelloWorldImp.o] 5. ln -sf libHelloWorld.so.1.0 libHelloWorld.so [if I use libHelloWorld.a (!), I get the reasonable msg. that it can't find the shared library] Result: [user@ravel native]$ java HelloWorld Hello World ! HTH. Bob L. -- Robert Lynch-Berkeley CA [EMAIL PROTECTED] http://www.best.com/~rmlynch/
