Re: Using the Java ATK Wrapper with Orca... again

[Ke Wang <Ke Wang Sun COM>]

Hi Mario,

Mario Lang wrote:
> Ke Wang <Ke Wang Sun COM> writes:
>
>   
> > I think the problem is that JAW could not find the so library file.
> >     
>
> That is one possibility, however, the empty catch block in AtkWrapper
> silently muffles all possible Exceptions so that debugging initialisation
> problems becomes pretty obscure.
>
> I am refering to this piece of code in
> wrapper/org/GNOME/Accessibility/AtkWrapper.java.in:
>
>   static {
>     try {
>       Process p = Runtime.getRuntime().exec("@XPROP@ -root");
>       BufferedReader b = new BufferedReader (new InputStreamReader(p.getInputStream()));
>       String result;
>       accessibilityEnabled = false;
>       while ((result = b.readLine()) != null) {
>         if (result.indexOf ("AT_SPI_IOR") >= 0) {
>           accessibilityEnabled = true;
>           break;
>         }
>       }
>
>       if (accessibilityEnabled) {
>         System.loadLibrary("atk-wrapper");
>         AtkWrapper.initNativeLibrary();
>       }
>     } catch (Exception e) { }
>   }
>
> Now, the problem on my system (Debian) is that @XPROP@
> gets expanded to /usr/X11/bin/xprop, but on my system xprop
> is located in /usr/bin.  So the System#loadLibrary call is never
> executed and the exception thrown by Runtime#exec is silently ignored.
>   
The problem is that @XPROP@ should be replace with the correct path in 
the configuring
phase, then configure will generate AtkWrapper.java. But I forgot to 
delete AtkWrapper.java while
packaging the tarball. So the xprop path is hardcoded to the path on my 
build machine.

I'll fix this in the next release. I'll also add some log message.
> Correcting the absolute path to xprop did apparently help to
> get me further but now I do get a segmentation fault.
>
> If you have any hints on how to debug segfaults related to the use of
> java-atk-wrapper, please let me know.
>
> Stack: [0xb6b33000,0xb6b84000],  sp=0xb6b823f0,  free space=13cb6b81d94k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpthread.so.0+0x7aa7]
> C  [libX11.so.6+0x2a08f]
> C  [libX11.so.6+0x4087e]  XrmQGetResource+0x3e
> C  [libX11.so.6+0x2054b]  XGetDefault+0xcb
> C  [libmawt.so+0xed8f]  Java_sun_awt_X11_XlibWrapper_XGetDefault+0xcf
> j  sun.awt.X11.XlibWrapper.XGetDefault(JLjava/lang/String;Ljava/lang/String;)Ljava/lang/String;+0
> j  sun.awt.X11.XToolkit.initializeMultiClickTime()V+12
> j  sun.awt.X11.XToolkit.getMultiClickTime()I+6
> j  sun.awt.X11.XToolkit.initializeDesktopProperties()V+66
> j  java.awt.Toolkit.getDesktopProperty(Ljava/lang/String;)Ljava/lang/Object;+32
> j  sun.swing.SwingUtilities2$AATextInfo.getAATextInfo(Z)Lsun/swing/SwingUtilities2$AATextInfo;+11
> j  javax.swing.plaf.metal.MetalLookAndFeel.initComponentDefaults(Ljavax/swing/UIDefaults;)V+12213
> j  javax.swing.plaf.basic.BasicLookAndFeel.getDefaults()Ljavax/swing/UIDefaults;+25
> j  javax.swing.plaf.metal.MetalLookAndFeel.getDefaults()Ljavax/swing/UIDefaults;+9
> j  javax.swing.UIManager.setLookAndFeel(Ljavax/swing/LookAndFeel;)V+79
> j  javax.swing.UIManager.setLookAndFeel(Ljava/lang/String;)V+16
> j  javax.swing.UIManager.initializeDefaultLAF(Ljava/util/Properties;)V+28
> j  javax.swing.UIManager.initialize()V+9
> ...
>
>   
This seems to be the same problem reported by Paul Hunt.
I have not met this on Solaris. I'll try to reproduce it and get a
solution as soon as possible.
> To wrap my experience up: I think xprop should be executed
> without a hardcoded path (relying on $PATH), and exceptions should at
> least
> print a stacktrace on the console if they occur.
>
> However, I am stuck when it comes to the segmentation fault,
> especially because JAW doesn't appear in the stack trace at all.
>   
Perhaps this is a synchronization problem and the corresponding 
implementations of
thread are different between Solaris and Linux.
> P.S.: I basically just tried JAW because JABG apparently stopped working
> on my system since the last major upgrade (it can no longer connect to
> orbit).  So currently, I am left without access to the Java platform,
> which is very unfortunate given that I am developing an application[1]
> for people with special needs, based on Java (and swing).
>   
I've no idea why JABG stopped working, but I'll try to make JAW work soon.

Thanks,

Ke
> If you read this and know why JABG is no longer talking to ORBit, please
> drop me a note, I need working Java Accessibility again (which did work
> for at least a year for me now).
>
> [1] http://code.google.com/p/freedots/
>
>