FULL PRODUCT VERSION :
java version "1.6.0-internal"
Java(TM) SE Runtime Environment (build 1.6.0-internal-brad_30_dec_2006_20_53-b00)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0-internal-brad_30_dec_2006_19_05-b00, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Linux the-uberbeast 2.6.19-gentoo-r2 #1 SMP Thu Dec 21 20:16:21 UTC 2006 x86_64 Dual Core AMD Opteron(tm) Processor 285 AuthenticAMD GNU/Linux


EXTRA RELEVANT SYSTEM CONFIGURATION :
nvidia-drivers-1.0.9631, AIGLX, Beryl-0.1.3

A DESCRIPTION OF THE PROBLEM :
Similar to bug report 6429775, grey windows when using Swing applications (MatLAB 2006b's Desktop) while running Beryl Window Manager.  Verified that previous example code:

import javax.swing.*;

public class WmTest extends JFrame {

public WmTest () {
    JLabel l = new JLabel ("WM Test");

    this.getContentPane().add(l);
    this.setSize(256, 256);

    //this.pack();
    this.setVisible (true);
}

public static void
main (String args[]) {
    WmTest r = new WmTest ();
}

}

still fails on jdk6u1 binary snapshot.  Likely due to only "compiz" being detected in AWT as Non-reparenting.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run above test code under Beryl WM.  Judging by what I've found online, underlying 3d support (AIGLX vs. XGL) should not matter.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Application window showing "WmTest" text inside
ACTUAL -
Application window is all grey

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import javax.swing.*;

public class WmTest extends JFrame {

public WmTest () {
    JLabel l = new JLabel ("WM Test");

    this.getContentPane().add(l);
    this.setSize(256, 256);

    //this.pack();
    this.setVisible (true);
}

public static void
main (String args[]) {
    WmTest r = new WmTest ();
}

}
---------- END SOURCE ----------
Posted Date : 2007-01-03 03:47:12.0

N/A

Unfortunately, AWT can't support every window manager separately - there are a lot of them.
Posted Date : 2007-01-06 15:45:16.0

I think that after adding su
Posted Date : 2007-01-08 14:20:54.0

I think that after adding support for Compiz (7.0 and 6u1) it should be rather easy to add
support for Beryl.  But this WM is unsupported for now and so the priority of this bug is
very low.  So, I'll keep it opened but will not work on it until some sunny day I'll have 
to spend on a beach :)  or someone will submit fix for the problem.
Posted Date : 2007-01-08 14:20:54.0

Just noticed today: http://lists.freedesktop.org/archives/compiz/2007-April/001809.html

It looks like it is good to be a little bit lazy :)

Perhpas this letter also means that I should close this CR (not sure, perhaps it is better
to postpone this a little ;)
Posted Date : 2007-04-06 13:27:48.0

Since the Beryl window manager is no longer actively being developed, there's no need to keep this CR open.

However, some problems still exist when running on Compiz window manager. These are going to be addressed with 6632124 in JDK 7 (the fix is present in 6 since 6u10).
Posted Date : 2009-05-06 12:21:52.0

Actually it's pretty easy to fix it. All changes required for compiz can be applyed for beryl. I made it. You need to patch two files then update the rt.jar in the JRE. So it works for me.

Can you detail what you did to solve this bug ? In addition, what files need to be patched ?

Here is a fix, tested on beryl-svn and compiz 0.2.2. :

diff -Naur orig/j2se/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java fixed/j2se/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java
--- orig/j2se/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java	2007-01-19 01:56:27.000000000 +0100
+++ fixed/j2se/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java	2007-01-19 01:59:01.000000000 +0100
@@ -643,7 +643,7 @@
             if (!insets_corrected && getDecorations() != winAttr.AWT_DECOR_NONE) {
                 Insets correctWM;
 
-                if (runningWM == XWM.COMPIZ_WM) {
+                if (runningWM == XWM.COMPIZ_WM || runningWM == XWM.BERYL_WM) {
                     correctWM = XWM.getWM().getInsets(this, window, XConstants.None);
                 } else {
                     long parent = -1;
@@ -692,7 +692,7 @@
                 // ConfigureNotify, only the one from X with zero
                 // coordinates.  This is the workaround to get real
                 // location, 6261336
-                // Do the same for non-reparenting WMs (Compiz, Looking Glass)
+                // Do the same for non-reparenting WMs (Compiz, Looking Glass, Beryl)
                 switch (XWM.getWMID()) {
                   case XWM.CDE_WM:
                   case XWM.MOTIF_WM:
@@ -700,6 +700,7 @@
                   case XWM.SAWFISH_WM:
                   case XWM.COMPIZ_WM:
                   case XWM.LG3D_WM:
+		  case XWM.BERYL_WM:
                   {
                       Point xlocation = queryXLocation();
                       if (log.isLoggable(Level.FINE)) log.log(Level.FINE, "New X location: {0}", new Object[]{xlocation});
diff -Naur orig/j2se/src/solaris/classes/sun/awt/X11/XWM.java fixed/j2se/src/solaris/classes/sun/awt/X11/XWM.java
--- orig/j2se/src/solaris/classes/sun/awt/X11/XWM.java	2007-01-19 01:56:27.000000000 +0100
+++ fixed/j2se/src/solaris/classes/sun/awt/X11/XWM.java	2007-01-19 01:59:16.000000000 +0100
@@ -79,7 +79,8 @@
         ICE_WM = 10,
         METACITY_WM = 11,
         COMPIZ_WM = 12,
-        LG3D_WM = 13;
+        LG3D_WM = 13,
+	BERYL_WM = 14;
     public String toString() {
         switch  (WMID) {
           case NO_WM:
@@ -106,6 +107,8 @@
               return "Compiz";
           case LG3D_WM:
               return "LookingGlass";
+          case BERYL_WM:
+              return "Beryl";
           case UNDETERMINED_WM:
           default:
               return "Undetermined WM";
@@ -534,6 +537,10 @@
         return isNetWMName("LG3D");
     }
 
+    static boolean isBeryl () {
+    	return isNetWMName("beryl");
+    }
+
     /*
      * Is Metacity running?
      */
@@ -546,7 +553,7 @@
     }
 
     static boolean isNonReparentingWM() {
-        return (XWM.getWMID() == XWM.COMPIZ_WM || XWM.getWMID() == XWM.LG3D_WM);
+        return (XWM.getWMID() == XWM.COMPIZ_WM || XWM.getWMID() == XWM.LG3D_WM || XWM.getWMID() == XWM.BERYL_WM);
     }
 
     /*
@@ -738,8 +745,10 @@
                 awt_wmgr = XWM.COMPIZ_WM;
             } else if (isLookingGlass()) {
                 awt_wmgr = LG3D_WM;
+            } else if (isBeryl()) {
+	    	awt_wmgr = BERYL_WM;
             } else if (doIsIceWM && isIceWM()) {
-                awt_wmgr = XWM.ICE_WM;
+	        awt_wmgr = XWM.ICE_WM;
             }
             /*
              * We don't check for legacy WM when we already know that WM
@@ -1388,6 +1397,8 @@
               return readInsetsArray(window, XA_E_FRAME_SIZE, insets);
           case XWM.COMPIZ_WM:
               return readInsetsArray(window, XA_FRAME_EXTENTS, insets);
+          case XWM.BERYL_WM:
+              return readInsetsArray(window, XA_FRAME_EXTENTS, insets);
           default:
               return false;
         }

Actually this was the patch I applied first. And it works in most of the cases, but there is a bug in it which causes that sometimes gray windows appears with no content or partial content. It seems the inset correction which is required by compiz does not needed for beryl. So the first section of the patch above is not required.

+                if (runningWM == XWM.COMPIZ_WM || runningWM == XWM.BERYL_WM) {

should remain as it was:
+                if (runningWM == XWM.COMPIZ_WM) {

I wrote a page on fixing this for end users until a patched JDK is released, http://wiki.beryl-project.org/wiki/Java

The problem is that the approach is broken. I'm happy that java SE will be soon GPL so we can work on this kind or problems. You should not, in my opinion, consider at all windows managers.

This prevents for experimenting new form of desktop/wm combinations. What if both compiz, metacity and beryl becomes obsolete and a new wm surfaces? You have to change again, and you have to do it after this wm is spread. This means other pains for users.

I'm not a wm programmer, so I can't tell you the solution, but I'm sure there is. To prove this, look at classpath. Maybe that our swing implementation is not very close to that of the RI, but we don't suffer this problem. Eclipse and SWT work well. We only have problem with swing.

As a side note, beryl evolves faster than compiz, and it is an option in some environments. In my fedora I have to use beryl to work with TwinView (or use a patched compiz), as the default compiz has a broken TwinView (and Xinerama) support.

I hope you find this suggestion useful.

you do not have to wait until AWT will be open-source to submit this patch.  It is possible now.
see https://jdk7.dev.java.net/collaborate.html for more information

The fix described is working, but maybe it would be interesting to compare how they are actually doing it in Eclipse/SWT. 
Beryl is the window manager I have installed on the network here. I'm confident this is going to be patched up in the JDK soon ... right ?

I think the above patch does not solve the problem entirely. While AWT applications now get displayed correctly, the same does NOT happen with stuff like JDialog(s). 

Every time I  open a "Find" dialog after having selected a word in the edit panel in Netbeans 5.5, the dialog frame is not rendered properly (the frame is gray and the size seems not to be the right one). 

This in not a Netbeans bug since the dialog is displayed correctly without Beryl. Would be interesting to test whether Compiz had the same behaviour.

I have the same experience as mauriziocima with NetBeans, JDK 1.6 and Beryl, even with JDK 1.6.0_01 plus the patch to XDecoratedPeer and XWM.

In fact, when I exit Beryl back to metacity I still get the same problem.  Everything works fine with JDK 1.5 but in JDK 1.6 when I open a Find dialog and then press escape, my keyboard stops responding.  I have to double-click a file tab (to maximize it) and then the keyboard starts working again.  Does anyone have any workarounds?

Sorry, forgot to include my screen name in the previous post.

I just confirmed I still get the error even with twm as my window manager, so I don't think this is window manager related.  Maybe this is a different issue than reported, but it seems at least a few people are complaining about NetBeans not working in this and related bug 6429775.

I've opened bug 97249 for NetBeans to see if it can be explored from that angle.

http://www.netbeans.org/issues/show_bug.cgi?id=97249

I think that the pronlem explained in my previous post is a little different. As far as I know, the focus problem you're experiencing are due to the fact that you're using the MTollkit as the default awt toolkit... MToolkit seems to be broken in jdk6, so this is the reason for which you could run Netbeans fine under jdk5 but not in jdk6. You should check your bashrc files in order to see if you are exporting the AWT_TOOLKIT variable. 

I guess you've done this in order to make Beryl to work toghether with Java; unfortunately, this trick no longer applies in jdk6 and the proposed solution (changing the awt sources in order to recognize Beryl/Compiz) does not seem to work in every case (awt windows get displayed, but still problems when displaying JDialogs). 

Why is this an issue? Why can't the code be rewritten in such a way that determining whether a window has a non-root parent is the only thing that counts?

As I understand it, non-reparenting WM' s do not give each 'top-level' window a new parent to draw borders etc. Therefore, the fact that a WM is reparenting is detectable at run time by looking at parent windows of a top-level window and comparing it with the root window. If it is the root-window, the WM was not reparenting. Instead of using a property that is different for some WM's, and could also change over time, one should query for the needed information, which is: is this a top-level window and is its parent root or not.

So my suggestion is: 

rewrite the method from XWM.java

 static boolean isNonReparentingWM() {
        return (XWM.getWMID() == XWM.COMPIZ_WM || XWM.getWMID() == XWM.LG3D_WM);
    }

to some run-time (non-static) equivalent like

private boolean hasNonRootParent() {
Xwindow parent = getParent();
if (parent!=null)
 return parent.getParent()!=null;
return true;
}

This bug is duplicate of 6429775 which Sun has closed but it is _not_ fixed.
Will you please do this right already, you know the problem and you know the solution (check for parenting).
Then perhaps you could spend some time on the beach.

Just noticed today: http://lists.freedesktop.org/archives/compiz/2007-April/001809.html

I wonder if this change is still needed :)

Thanks:  "StupidScreenName" for http://wiki.beryl-project.org/wiki/Java

Applied patch as described on that link on source from http://www.java.net/download/jdk6/6u2/promoted/b02/jdk-6u2-ea-src-b02-jrl-12_apr_2007.jar
and so far, that  works very well (quite happy to again have AA-fonts instead of that MToolkit hack), I have not much more to say but hope that this issue is resolved quite soon.

The fix listed in the comments that involves recompiling some AWT classes doesn't completely fix the problem. It only fixes it _most_ of the time. However, it is still an issue and sometimes the dialog windows are still gray.

Hopefully there is going to be a general fix for this bug. Beryl is definitely not the only wm that doesn't do reparenting.

It's not a fix, but a little tip, the problem appears when you use Emerald, but I just tried with aquamarine, it seems to work, without using MToolkit :-)

Now that beryl and compiz have rejoined to CompComm or compiz-fusion and there is not need to have a piece of code for each VM separately how difficult is it to alter the compiz fix in 6u1 to make it work with compiz-fussion, since now everything is ran from the compiz-core?

VOTE!! :-)

I'm happy that there's still an open bug report regarding this problem, unlike 6429775 , which has been closed as "fixed", which it isn't!!

First: As the other comments said, you've got to check and re-check the JDialogs, which occasionally fail to render...
Netbeans is "king" here... (Find dialog).

It may work 10 times, 15 times... then .. bang!! Grey, double the size and/or on a different position on the screen.

Second: I don't think of this bug as "unimportant"... no way.
A lot of Linux distributions will enter the 3D-Desktop bandwagon in the near future, it's too damn sexy... if you like it or not. We'll get some major distributions with compiz-fusion activated by default, I'll bet!

Thinking of Swing as the "more portable, cleaner" solution as SWT (..that's what the Swing guys told me always..) it's just weird that Swing fails like that.

I've just checked it today. It seems JDK 7 is free from this bug, and the XDecoretedPeer file doesn't contain any COMPIZ or BERYL tweaks.
The dialogs in applications work as well.

 I hope it will be backported to Java 6 u3!

appending 
"export AWT_TOOLKIT=MToolkit"
to your /etc/profile will fix this beryl/swing problem too...
at least it works for me

appending

export AWT_TOOLKIT=MToolkit

to your /etc/profile will solve this swing/beryl issue as well.
at least this worked for me and some friends.

MToolkit is not a real solution. Many things won't work correctly with it.

As of the gray dialog problem on 6u2 please try to add the following line at the and of the <java_home>/jre/logging.properties:
sun.awt.X11.insets.level = FINEST

I'm WM developer and I already told you how to fix this bug in a 6429775 comment, and neugens did here in the comments as well.

If you want to detect a WM at all, you have to check if selecting input for SubstructureRedirectMask  on the root window fails, if so a WM is running.

If you want to detect if a WM is reparenting or not, this is trivial and doesn't needs any hardcoded WM-specific support:

if(yourwindow->parent == root)
   // NON-REPARENTING
else
  // REPARENTING

The insets handling is totally obsolete at all, because in X all windows use parent-relative geometries, so there is absolutely no reason to handle any insets at all.

On most modern linux distris compiz is enabled on default.
so Java is not usable on this platforms and
Sun has set this bug Priority to:_"5-Very Low"_ !!
what must be the thing to get a p1/critical Priority ???
I think this require code that throw the earth from orbit .

I had the similar problem with java 1.6.0 but last night I updated my java to 1.6.3 and it seems to be working good now....
-arin
arinv1618beta@gmail.com

I had the similar problem with java 1.6.0 but last night I updated my java to 1.6.3 and it seems to be working good now....

Is someone not paying this developer enough? Its been happening since Ubuntu 7.10. I worked around it by disabling compiz. Now, on Ubuntu 8.04 its the same thing, but its happening even when I disable compiz. Sun promised a fix for version 7 and this is what we get?  This bug is critical, Sun's own products, ie Netbeans are not working as well as Java. Luckily my eclipse is working becauase its not AWT.  This is completely unnacceptable, it should in my opinion be escalated to a major as swing apps do not work at all!

Please add 6632124 as related bug.

The Sun people along with this developer are all sleeping or are just ignorant, considering the agreement b/w Sun and Canonical that OpenJDK will be included by default from Ubuntu 8.04 onwards it only seems foolish not to correct this problem since compiz is enabled by default and effectively no Swing application will run, so what is the point of including OpenJDK, they might as well continue with their current implementation. WAKE UP SUN!

it works for me on this jdk version: 
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b34)
Java HotSpot(TM) 64-Bit Server VM (build 14.0-b03, mixed mode)

no need to set AWT_TOOLKIT=MToolkit, 
I use linux(amd64) with beryl.

unfortunately it stopped working on  build 1.7.0-ea-b37, it doesn't work on a few 1.6 jdks I tried either (including 1.6.0u7 and  1.6.0u10 rc2).

This bug is so old, so many people complained about it and Sun still doesn't care. 

Just close this and set the status to "we don't give damn"

I've stumbled upon a workaround for this problem. Here is the link:

http://www.vikrammohan.com/blog/2006/12/31/how-to-make-java-swing-work-on-beryl-with-aiglx

The basic idea is to run swing apps inside a nested X server (Xnest).

ps. before lunching any applications you could try to run some WM inside the nested server (twm, wmaker or other except for beryl of course :) ) , so that you'll be able to move/resize windows and dialogs.

is this developer still alive or not? HELLO?