JDK-6214603 : LayoutFocusTraversalPolicy;JDK1.5;wrong getComponentAfter()| JDK1.4 is OK.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2005-01-06
  • Updated: 2011-01-19
  • Resolved: 2005-09-16
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.5.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08)
Java HotSpot(TM) Server VM (build 1.5.0_01-b08, mixed mode)

I get the same bug behavior from Java1.5 regardless of whether the
classes have been compiled under 1.4 or under 1.5.  My java1.4  will
execute the classes compiled under 1.4 but not under 1.5.  My java 1.5
will execute the classes compiled under 1.4 or 1.5.  Source code being
the same for either compilation.

The old version of 1.4 that I have been using successfully is:
Java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
SunOS nunatak 5.8 Generic_117350-12 sun4u sparc SUNW,Sun-Blade-1000

EXTRA RELEVANT SYSTEM CONFIGURATION :
64-bit machine.  64-bit Java installed.  All Patches for
uptodate recommended patch clusters for both java and
SunOS 5.8 are installed.



A DESCRIPTION OF THE PROBLEM :
I have an AWT/SWING application.
A focusable/active window:

This window is a focus cycle root.  There are no
FocusTraversalPolicyProviders among any of the children components
 of the window.  In fact there are none in my application at all.
There are no other focus cycle roots among the descendants of this
window.

Under j2sdk1.4.2, my application worked without any errors. In
particular forward Focus Traversal (TAB key) worked perfectly.

Under jdk1.5.0_01  Backward Focus Traversal (Shift_TAB)  works
correctly but Foward Focus Traversal does not.

When I investigated by printing out the component order given
by the (LayoutFocusTraversalPolicy) and  getComponentAfter and
getComponentBefore  I found that under js2dk1.4.2  the order
of components was correct,  but that under jdk1.5.0_01
although the order returned by getComponentBefore was
correct,  the order returned by getComponentAfter was
not consistant with getComponentBefore and that
getComponentAfter was not correct---In my particular case,
the component returned (in 1.5) by getComponentAfter was
(for a focusable component)  the currentComponent itself.
   So I suspect that something is wrong with the
Comparator algorithm in JDK1.5 for SortedFocusTraversalPolicy.

I cannot give you an example short of sending you the whole
Application (about 13,000 lines of code) that I wrote.

The Window Hierarchy is (I am doing the best I can here, but
am not absolutely sure I have it entirely correct):

1)A JFrame that implements WindowListener

2)An abstract subclass of 1) that implements ActionListener,
ComponentListener, KeyListener, MouseListener

3)An implementation of 2),  this [ 3)], is the Window that
  actually appears and is the FocusCycleRoot

4) In 3)  there is a component which is a subclass of JPanel.
   This Component [ 4)] is implemented  as a member class of
   3)  and added to 3) by 3)'s  constructor.

5) 4) contains a number of subclasses of JPanel.

6) Each of the JPanels in 5)  has a BoxLayoutManager
   and contains at least 1 HorizontalStrut,  1 JLabel, and
   one subclass of JTextField.  Some of these JTextFields are
   Focusable.  Some are not.  Some are Editable, Some are not.

   The only components in the window that are focusable besides the
   window and window trimmings themselves  are the JTextFields.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
As I mentioned above, I cannot do this short of sending you
my whole application  (which I would be willing to do if you
would like me to) and even if I did, although
I am sure I could send you all of the relevant code,  the application
itself speaks to a back end DataBase running on a Tomcat server, so
it would be a nuisance for you to modify the code to run the application
in such a way that the bug is exhibited.
I AM SURE that the communications with the backend are completely
irrelevant to this problem.



ERROR MESSAGES/STACK TRACES THAT OCCUR :
Under 1.4  there are no messages returned at either
compilation or runtime.

Under 1.5 there are no messages returned at runtime.
 compilation returns:
"Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details".

When compiled with -Xling there is much output.
All messages are like either
 a) "CloseableFrame.java:6: warning: [serial] serializable class
     CloseableFrame has no definition of serialVersionUID public class
                                                                ^
     CloseableFrame extends JFrame implements WindowListener {"

           or
   
 b)"Screen.java:1157: warning: [unchecked] unchecked call to
 put(K,V) as a member of the raw type java.util.HashMap
                 slitemshm.put(""+i+slitems[i][j].getVarname(),
                 slitems[i][j]);"
                              ^


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
I have not found a workaround.
I have over 70 Windows that I am constantly changing. And
making more windows---in response to my users' needs.
So making a specific FocusTraversalPolicies for each window while
possible is not practicable.
Writing a very general FocusTraversalPolicy sufficient for my
application could very well be beyond what I am capable of.

About "SEVERITY"  below.  none of the categories I can check
are appropriate, so I am giving my True answer here.
You should disregard what I have checked in the box below
for severity.
  I could continue to employ 1.4.  There would be no impact then
on the developement of my application.  1.4 has all the features
necessary for my application in the medium short run.  But
I could not upgrade my environment and this would be
a serious impact.   Also my users's would not be able to
upgrade to 1.5 (or be upgraded by those maintaing their environments.
  Also, since the BackwardFocusTraversal works properly,  I can
  continue to develope my application without much difficulty,  but
  my users would be much disturbed by the substantial inconvenience
  they would find when they used Java1.5.
THE BOTTOM LINE IS THAT THIS IS FOR US A SERIOUS BUG.
###@###.### 2005-1-06 09:26:10 GMT

Comments
EVALUATION Thanks for example. I'm extracting the sources and classes from jar file and run the test as described in README file from there and it seem work with JDK1.4 but stop working with JDK5.0. I'm not looking into sources very attentive though. As reported there is an extra check for XAWT in javax.swing.UIManager which installs LayoutFTPolicy but after check on Linux with XAWT/Motif I didn't notice any problems and thus this doesn't depend on enabled toolkit. That change is described in 4897659. Furthermore, I checked the behaviour with current mustang and seems the problem has eliminated by #5070991.
16-09-2005

EVALUATION This is an AWT bug and I believe it might be a duplicate of 5070991. ###@###.### 2005-1-06 17:37:57 GMT There is no action could be taken without a testcase. Asked submitter to help us. ###@###.### 2005-1-18 08:42:26 GMT
06-01-2005