Name: gm110360 Date: 04/29/2002


FULL PRODUCT VERSION :
java version "1.4.0-beta3"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta3-b84)
Java HotSpot(TM) Client VM (build 1.4.0-beta3-b84, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]



A DESCRIPTION OF THE PROBLEM :
  From the documentation, I understood that calling
JFormattedTextfield.setValue(new Double(1.0)) would install
a formatter for Doubles. The JavaDocs example uses Date()
instead of Double() and I inferred that the behavior would
be the same.

In fact, the javadocs say: "If an AbstractFormatterFactory
has not been explicitly set, one will be set based on the
Class of the value type after setValue has been invoked
(assuming value is non-null)."

However, the component seems to behave differently with
numbers. With setValue(new Double(1.0)), getValue() returns
a Long. I can edit the value to any numeric value but if
there is no decimal point or all zeros after the decimal
point the returned component value is a Long. If there is
any non-zero value after the decimal point it returns a
Double. With setValue(new Long(1)) the behavior is the
same - Longs can mutate to Doubles and visa versa,
depending on the presence of non-zeros after the decimal
point.

This default behavior would be more useful to me if the
class returned by getValue() remained constant and matched
the class passed to setValue(). As it is, I have to do type
checking on the getValue() to convert back to a Double when
it is a Long or visa versa.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.Create dialog with JFormattedTextField
2.call setValue(new Double(1.5))
3.edit value in dialog to 1.0
4.getValue() will return a Long.
5.edit value in dialog to 1.5
6.getValue() will return a Double.

EXPECTED VERSUS ACTUAL BEHAVIOR :
In step 4. above, getValue() should return a Double not a
Long. The class passed in to setValue() should be the class
returned from getValue(). If there is no such contract,
then ANYTHING could be returned and there's no way to code
around that. At the least, document the behavior in a way
that provides a predictable model and matches the behavior.

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
/*
 * FormattedTextFieldTest.java
 *
 * Created on January 22, 2002, 9:27 PM
 */

/**
 * JFrame with a JFormattedtextField above a JLabel.
 * Editing the text field value causes the class of object returned
 * by getValue() to be displayed in the JLabel.
 *
 * @author sreed
 */
public class FormattedTextFieldTest extends javax.swing.JFrame {


public FormattedTextFieldTest() {
initComponents();
}

  private void initComponents()
  {
    formattedTextField = new javax.swing.JFormattedTextField();
    typeLabel = new javax.swing.JLabel();

    setTitle("JFormattedTextField Test");
    addWindowListener(new java.awt.event.WindowAdapter()
    {
      public void windowClosing(java.awt.event.WindowEvent evt)
      {
        exitForm(evt);
      }
    });

    formattedTextField.setColumns(20);
    formattedTextField.setHorizontalAlignment(javax.swing.JTextField.RIGHT);
    formattedTextField.setText(" ");
    formattedTextField.setAlignmentX(0.0F);
    formattedTextField.setAlignmentY(0.0F);
    formattedTextField.setValue(new Double(1.0));
    formattedTextField.addPropertyChangeListener(new
java.beans.PropertyChangeListener()
    {
      public void propertyChange(java.beans.PropertyChangeEvent evt)
      {
        formattedTextFieldPropertyChange(evt);
      }
    });

    getContentPane().add(formattedTextField, java.awt.BorderLayout.NORTH);

    typeLabel.setHorizontalAlignment(javax.swing.SwingConstants.CENTER);
    typeLabel.setText("java.lang.Double");
    getContentPane().add(typeLabel, java.awt.BorderLayout.CENTER);

    pack();
  }

  private void formattedTextFieldPropertyChange(java.beans.PropertyChangeEvent
evt)
  {
    if (evt.getPropertyName() == "value" && evt.getNewValue() != null)
      typeLabel.setText(evt.getNewValue().getClass().toString());
  }

    /** Exit the Application */
    private void exitForm(java.awt.event.WindowEvent evt) {
        System.exit(0);
    }

    /**
    * @param args the command line arguments
    */
    public static void main(String args[]) {
      new FormattedTextFieldTest().show();
    }


  private javax.swing.JLabel typeLabel;
  private javax.swing.JFormattedTextField formattedTextField;

}

---------- END SOURCE ----------

CUSTOMER WORKAROUND :
Always check getValue() retruned class and convert when
necessary.
(Review ID: 138672)
======================================================================
Contribution by java.net member leouser:

A DESCRIPTION OF THE FIX :
BUGID 4676880 JFormattedTextField setValue(Double) getValue()->Long
FILES AFFECTED: javax.swing.JFormattedTextField
JDK VERSION
jdk-6-rc-bin-b64-linux-i586-15_dec_2005.bin

/**
 * BUGID 4676880 JFormattedTextField setValue(Double) getValue()->Long
 * This bug was centered upon the fact that setting the value to 1.0
 * will in turn cause the JFormattedTextField instance to return a Long
 * instead of a Double. The test case, which is a pretty literal copying
 * of the test case in the bug report, shows that this is no longer happening
 * so we can close this bug.
 *
 * TESTING STRATEGY:
 * Start editing in the text field, watch the console. Hit enter. Your
 * new value and its class will be spit out. You will see that upon
 * entering 1.0 that it returns 1.0 and also a Double, which is not the
 * behavior the bug was showing. If it were still broken, upon 1.0
 * we would see a Long be spat out.
 *
 * RECOMMENDATION: Close this bug!
 *
 * FILES AFFECTED: javax.swing.JFormattedTextField
 *
 * JDK VERSION
 * jdk-6-rc-bin-b64-linux-i586-15_dec_2005.bin
 *
 * test ran succesfully on a SUSE 7.3 Linux distribution
 *
 * Brian Harry
 * ###@###.###
 * Jan 24, 2006
 */

JUnit TESTCASE :
import javax.swing.*;
import static java.lang.System.*;

/**
 * BUGID 4676880 JFormattedTextField setValue(Double) getValue()->Long
 * This bug was centered upon the fact that setting the value to 1.0
 * will in turn cause the JFormattedTextField instance to return a Long
 * instead of a Double. The test case, which is a pretty literal copying
 * of the test case in the bug report, shows that this is no longer happening
 * so we can close this bug.
 *
 * TESTING STRATEGY:
 * Start editing in the text field, watch the console. Hit enter. Your
 * new value and its class will be spit out. You will see that upon
 * entering 1.0 that it returns 1.0 and also a Double, which is not the
 * behavior the bug was showing. If it were still broken, upon 1.0
 * we would see a Long be spat out.
 *
 * RECOMMENDATION: Close this bug!
 *
 * FILES AFFECTED: javax.swing.JFormattedTextField
 *
 * JDK VERSION
 * jdk-6-rc-bin-b64-linux-i586-15_dec_2005.bin
 *
 * test ran succesfully on a SUSE 7.3 Linux distribution
 *
 * Brian Harry
 * ###@###.###
 * Jan 24, 2006
 */
public class JTF4676880 implements Runnable{

    JFormattedTextField jftf;

    public void run(){

JFrame jf = new JFrame();
        jftf = new JFormattedTextField();
        jftf.setColumns(20);
        jftf.setHorizontalAlignment(JTextField.RIGHT);
        jftf.setText(" ");
jftf.setAlignmentX(0.0F);
        jftf.setAlignmentY(0.0F);
        jftf.setValue(new Double(1.0));
        jftf.addPropertyChangeListener(new java.beans.PropertyChangeListener(){
         
public void propertyChange(java.beans.PropertyChangeEvent evt){

                    formattedTextFieldPropertyChange(evt);

                }


});
jf.add(jftf);
        jf.pack();
        jf.setVisible(true);


    }

    public void formattedTextFieldPropertyChange(java.beans.PropertyChangeEvent evt){
        if(evt.getPropertyName() == "value" && evt.getNewValue() != null)
out.println(evt.getNewValue().getClass());
        out.println(jftf.getValue());
    }




    public static void main(String ... args){
SwingUtilities.invokeLater(new JTF4676880());


    }



}


FIX FOR BUG NUMBER:
4676880