United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4487993 : weird AWT interaction between jdk 1.3.1 and 1.4 on OpenWindows and Linux

Details
Type:
Bug
Submit Date:
2001-08-03
Status:
Closed
Updated Date:
2002-01-16
Project Name:
JDK
Resolved Date:
2001-09-18
Component:
client-libs
OS:
linux,solaris_7
Sub-Component:
java.awt
CPU:
x86,sparc
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.0
Fixed Versions:
1.4.0 (beta3)

Related Reports
Duplicate:
Relates:

Sub Tasks

Description
ingrid.yao@Eng 2001-08-03

J2SE Version (please include all output from java -version flag):
    this report documents an interaction between JDK 1.3.1:
        Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
        Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
    and JDK 1.4:
        Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta_refresh-b72)
        Java HotSpot(TM) Client VM (build 1.4.0-beta_refresh-b72, mixed mode)


Does this problem occur on J2SE 1.3?  Yes / No (pick one)
    Not at first.  If you start up a machine, run only jdk 1.3.1 
    there is no problem. If you then run using jdk 1.4 there is no problem.
    But if you then try using jdk 1.3.1 again, the problem occurs!


Operating System Configuration Information (be specific):
    (1) Linux RedHat 7.1 (kernel 2.4.3-12)
    (2) Solaris 2.7 for both OpenWindows and KDE wms(works fine with CDE)
    [no problem on WIndows 2000]


Hardware Configuration Information (be specific):
    (1) IBM Thinkpad 600X (500Mhz)
    (2) Sparc Ultra 60 (2x 300Mhz)


Bug Description:
   A problem occurs with an application that opens frames and 
   dialogs using JDK 1.3.1. The problem only occurs *after* running 
   the same application using JDK 1.4.

   As stated above, if you never run JDK 1.4 there is no problem 
   using jdk 1.3.1. On the face of it, this is a problem with JDK 1.3.1.
   However, it seems more than likely JDK 1.4 is the cause of the problem.



Steps to Reproduce (be specific):
    1) ensure you have both jdk 1.3.1 and jdk 1.4 available
    2) logout of the system or, whatever you need to do to restart X-Windows
        (X needs to be in an initial pristine state)
    3) compile the attached application(Frame2.java) using jdk 1.4 or 
       1.3.1 (doesn't matter)
    4) run the application using jdk 1.3.1 first using "java Frame2"
    5) follow these steps
        - initial frame shows a button labelled "Click me"
        - click the button
        - a dialog is shown placed over the original frame
        - click any diaog button, or close the dialog (doesn't matter)
        - repeat once or twice more (click the "Click me" button, then 
          close the dialog)
        it works as expected
    6) now repeat step (5) using jdk 1.4, again it should work as expected
    7) finally, repeat step (5) using jdk 1.3.1 again, here is what I 
       see happening:
        - on Solaris, both the initial "Click me" frame, and the dialog 
          have no size
        - on Linux,
            = the initial frame is fine
            = the first time you open the dialog it is incorrectly 
              positioned on screen
            = the second and subsequent times you open the dialog, it 
              has no size

    The point, the dialog is non-resizeable, so when it is shown with no 
    size, it is rather frustrating.

                                    

Comments
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
merlin-beta3

FIXED IN:
merlin-beta3

INTEGRATED IN:
merlin-beta3

VERIFIED IN:
merlin-rc1


                                     
2004-06-14
EVALUATION

Here is my guess: this is caused by the improved window manager detection 
we added in 1.4 (4384023):  

[###@###.### 
> There's one gotcha that you should be aware of.  Old code detects WM
> by naively checking if certain atoms are interned, assumption being
> that only specific WMs would intern such atoms (which is obviously
> incorrect).  The new code does more sophisticated checks and as part
> of those checks it interns a bunch of exactly those atoms old code
> looks for.  As a result, once you have ran JDK with this fix, old JDK
> builds will be thoroughly confused.  The first WM old code tests for
> happens to be Enlightenment, atom ENLIGHTENMENT_COMMS, so, since new
> code has interned this atom, old code will assume it runs under
> Enlightenment - and if the WM is not actually Enlightenment results
> will be disastrous as insets code tailored for Enlightenment will
> produce wildly wrong results (as described in this very bug report).
>
> Unfortunately, this side effect is *absolutely* unavoidable.  If you
> need to run an older build after a build with this fix - you *have* to
> reset the X server to purge all the extra atoms that confuse the old
> code.

On Unix, you typically reset the X server by logging out of your session.  
Under win32, X servers usually have a "Reset" menu item.  

eric.hawkes@eng 2001-08-03

This is covered in the AWT section of the release notes for 1.4.  

eric.hawkes@eng 2001-08-07

We think we may have discovered a way to fix this.  Reopening.  
Depending on how the fix pans out, we should either modify or remove 
the entry about this from the release notes.  

###@###.### 2001-08-14

========================================================================
Verified on Linux RedHat 7.1 with jdk build 91

###@###.### 2002-01-16
=========================================================================
                                     
2002-01-16



Hardware and Software, Engineered to Work Together