that’s it. So as usual, I made this change, gave it to the patching system ,which took the new class file made a zip downloaded it at the customer’s end and replaced the new class file. What do you know, it din’t work. I should have guessed. But I din’t.
The problem was this. In Java when constants are being referred from other files, it doesn’t read the value from the other variable dynamically, but copies the value within itself during compile time. For eg., when class “AnotherClass” access A_CONST, using code, say,
int b = ConstantClass.A_CONST;
it’s replaced to
int b = 10; within the class file.

So Iam off, making a patch by recompiling all the other (nearly 100) java files, and making a patch out of all those :(.

What you see is not what’s inside:

   Consider the TextField component. It has only one value associated with its model. The “text”. This is the same value that the user sees, and the value that you set or get using your code. This is OK for simple text fields, but what about cases where it’s convenient for you to manipulate the data in different way than what you need to show to the user. Not sure when such a case would arise? Consider this. Say you have a percentageTextField, in which the user can type his value in percentage like “30%” , “40%” etc. It’s very intuitive and readable for the user to see the string with “%” appeneded in the end (like “30%” instead of “30″), but wouldn’t you find it more easier to manipulate this value as integers 30 and 40, instead of Strings “30%” and “40%”?
   To solve this problem, JFormattedTextField introduces the notion of “value” in addition to the concept of “text”. The “text” part is what is showed to the user and the “value” part is what is easy for the code to manipulate. Got it? If you did, it should be obvious that the “text” part can only be a string(as it’s the one that displayed to the user) and the “value” part can be any object
   Easy So far? The rest should be even easier. read on.

Formatter: The one who converts between the “text” and “value”

   So, as far, you have understood that the JFormattedTextField has both “text” and “value” associated with it. But there’s one small catch left yet. When the “text” is updated so should the “value” and vice verca. For eg., when the user types “30%” the value should have an integer value of 30. and then when the user changes the text to “40%” the value should get automatically updated to integer 40. Right? And viceverca is true too, when through code you set the value to “50″ the user should see “50%” in the UI. When does this conversion happen? Before that let’s see who converts these.
   The “JFormattedTextField” has an inner class “AbstractFormatter”, instances of which are responsible for this conversion. So what methods should this class have for the subclasses to override? Obviously, one method that converts and returns the “value” object from the “text” string, and another method that converts and returns the “text” string from the “value” object. So here are the two methods that you need to override when you are making your own Formatter. Ofcourse, I need not tell now, which method should do what.

• public String valueToString(Object value) ;
• public Object stringToValue(String text) ;

When does Synchronization between text and value happen?

   When the user types some text it should get converted to the appropriate value object and when you modify the value object through code, it should somehow get converted back to the “text” string that the user sees. When does this conversion happen? When modifying the value object the conversion to text happens immediately, but when ther user types text, it usually happens in one of the following ways

• When the user presses enter after typing in some value
• When the user goes out of the text field (during focus lost)

Note, however this is not always true. The Formatter may decide to do it in other times too, like for example , for each character press by the user. You can also programatically call the commitEdit() method in the JFormattedTextField to convert the text to value at once.

An Example:

   Let’s write the percentage text field that we were discussing above. As discussed above it displays values like “30%”, “40%” etc., while the in the code we use integers like 30, 40 etc. First Let’s write an AbstractFormatter subclass
 &nsbp;&nsbp;Here’s the class. It implements the methods “stringToValue” and “valueToString”. The implementation is pretty simple, follow the code comments, if you have any doubts

Step 1: Create the PertentageFormatter class

class PercentageFormatter extends AbstractFormatter{
  //Convert the string to Integer	
  @Override
  public Integer stringToValue(String text) throws ParseException {
    if(text == null){
      return Integer.valueOf(0);
    }
    //If the text ends with "%" remove it
    if(text.endsWith("%")){
      text = text.substring(0, text.length()-1);
    }
		//If the text is empty, assume it's 0
    if("".equals(text)){
      return Integer.valueOf(0);
    }
    else{
 
      try {
        //Try to parse the remaining string, if there's an exception use 0
        return Integer.valueOf(text);
      } catch (NumberFormatException e) {
        //Leave it. If there's any exception return 0 below
      }
 
    }
 
    return Integer.valueOf(0);
  }
 
  @Override
  public String valueToString(Object value) throws ParseException {
     //If the value is an integer, append "%" to it
     // and return the value to display.
    if(value == null || (! (value instanceof Integer)))
    {
         return "0%";
    }
    Integer val = (Integer)value;
    return val.intValue() + "%";
  }
 
}

Step2: Create the JFormattedTextField using the “PercentageFormatter” formatter

This is really simple. You pass an instance of the “PercentageFormatter” sub class to the JFormattedTextField.

JFormattedTextField field = 
  new JFormattedTextField(new PercentageFormatter());

tha’s it. Now add this field to your form, type some value like “40%” and use the getValue() to get the value as an Integer Object 40.

• An “Email” text-field: That doesn’t let the focus out without the user entering a valid email address
• An “Numeric” text-field: That accepts only numeric input and ignores all others
• An “upper case” text-field: That automatically converts the characters to upper case as the user types in

   Besides using this components in whatever way you like, looking at the code can give you an excellent insight on using InputVerifier and DocumentFilter if you have already not used them

Let’s Make a MaxTextField

Let’s start by defining the problem. We are trying to add a TextField that will accept only 20 characters. After typing 20 characters the user cannot enter any more characters either by keypress or copy-paste. The user can however, delete existing characters and type new ones as long as the total number of characters is less than or equal to 20.

The Dirty way: Using KeyEvent.consume()

One’s first reaction would be to add a key listener to the textfield and calling the consume() method in a listener method like keyTyped() when the no. of characters exceeds 20.

Here’s the sample code that one would be templted to right

//Assume that textField is an instance of JTextField
textField.addKeyListener(new KeyAdapter(){
 public void keyTyped(KeyEvent e) {
  if(textField.getText().length() > 20){
  //Consume if the user has typed more than 20 charactes
  e.consume();
 }
}
}

This would seem to work fine. But there’s a catch. after typing 20 characters, the user can still insert more characters in the textfield by copy-pasting the text!!! why does this not work? Because, the paste happens at keyPress not keyTyped.
So, what’s the solution? We could add code in the keyPressed() that could handle ctrl+v. But what about shift+ins? What about right click and paste?
Started Sounding messy right? But the most itchy part of using this technique is this. When multiple keylisteners are attached to a textfield, there is no guarantee that which one will be called first. so, calling consume() on one listener does not prevent other listener from seeing this event! So when one listener is preventing the data from being entered, the other listener might happily be checking the spelling and underline the word in red(for a wrong spelling) even thought the user sees no character typed!!!

Enter DocumentFilter

What follows from the above discussion is this

“We need a technique that prevents more than 20 characters from being entered in the textfield before it reaches the textfield, not a technique that removes the character after it’s already there”

The solution is to use a document filter. What’s a document filter? Before that, What’s a document in the first place? A document is something like a container that sort-of stores the text entered in any text component in Swing. Each text component in swing has it’s own Document. It’s kind of a model for the swing-text-based-ui components. Got it?
Ok, so now what’s a DocumentFilter? Simple. A document filter is a special class that can be attached to documents to filter out the data before it goes into the document.

How to implement a DocumentFilter:

You simply follow the following steps

• Write a class extending the DocumentFilter class
• override one or many of insertString(), remove() or replace() methods, depending on whether you are filtering string insertion, string removal or string-replacement operations.
• you grab the document of the textfield and attach an instance of this document filter to that document

Let’s start. Here’s the DocumentFilter class for our problem. Clearly we need to override the insertString() and replace() methods so that user may not enter more than 20 characters why inserting or replacing strings. Here’s the code. See comments for more details

Step 1) Writing the class:

class MyDocumentFilter extends DocumentFilter{
 public void replace(FilterBypass fb, int offset, int length,
      String text, AttributeSet attrs) throws BadLocationException {
 
 //The current length minus the no.of characters deleted plus the
 // number of characters inserted is the final length in the textfield
 //and should not be more than 20
 if ((fb.getDocument().getLength() + text.length() - length) <= 20){
	super.replace(fb, offset,length, text, attrs);
 }
 else{
 	//Let's beep if the user tries to enter more characters
 	Toolkit.getDefaultToolkit().beep();
 }
}
public void insertString(FilterBypass fb, int offset,
       String string, AttributeSet attr) throws BadLocationException {
 
  //While inserting the current length plus the number of characters inserted
  //is the final length in the textfield and should not be more than 20
  if ((fb.getDocument().getLength() + string.length()) <= 20){
    super.insertString(fb, offset,string, attr);
  }
  else{
    //Let's beep if the user tries to enter more characters
   Toolkit.getDefaultToolkit().beep();
  }
 }
}

Step 2) Attach an instance of this class to the textfields document.

This is a simple and one line code as below

((AbstractDocument)textField.getDocument())
.setDocumentFilter(new MyDocumentFilter());

A small point to note is that we need to cast the return type of getDocument() to AbstractDocument, only which has the setDocumentFilter method.

That’s it! Hope you found this article interesting.

The need for InputVerifier

  To understand that let’s see the problems with the other common approach to solve this problem, using the focusLost() of the textfield

The problem with Focus-Snatching:

  One of the common approaches people take to solve such validation issue is to put the code in the focuslost() of a FocusListener attached to the textfield, and if the validation fails the requesting the focus back to the source component. This approach has several problems, but the main is this:
  ”The focus lost is called after the focus is moved to the new component. So if the new component itself has some other validation as a part of it’s focus lost, snatching the focus back to the first component, will trigger the focus lost of the new component too!, this might cause a sort of UI-lock when two components are trying to pull the focus to each other when both of them have invalid data”
din’t get the prose? Here’s the step by step description of the problem

When two things are wrong, does it matter which was wrong first?

• Assume there are two fields “email1″ and “email2″. both of them cannot accept empty values
• The user places the focus on field “email1″. No bombs here.
• He dosen’t type anything and moves the foucs to field “email2″.
• Now focus is given to field “email2″ and the focusLost() for “email1″ is called
• The focusLost() method of “email1″ validates “email1″ and checks that it cannot be empty so it prompts a messsage to the user saying “email1 cannot be empty” and requests the focus back to field “email1″.
• But by now, “email2″ already has the focus and when the focus is moved back to “email1″ the focus lost of “email2″ is called which again fires a validation
• The user gets a message “email2 cannot be empty” and code requests the focus back to “email2″
• Now, once again the focusLost() of email1 is called and this continues on and on.

  while there are ways to code to stop this from occuring, including putting this code in the focusgained(), of other components,and having flags to prevent this, why not use a better way provided in swing!

Enter InputVerifier:

  It’s great if you could fight and claim back the focus that belongs to you after letting it go to someone else, but wouldn’t it be better if you did not let it go in the first place?
  Coming back to swing, Wouldn’t it be cool, if I can have a method called whenever the user tries to move the focus out of my component and before the focus has actually entered the new component. Well, that’s what InputVerifier is for. To give a chance to the code to determine if the focus can move out of the current component to which it is attached to.

  The InputVerifier class has one main method “verify”, that get called before the focus is moved out of any component that it’s attached to. Let’s make it a little more clearer, here are the steps of invocation

• The user enter’s a field(the focus is moved to that field)
• The user does something and tries to moves the focus out of that field(either through mouse or keyboard)
• before User’s wish is granted and the focus is moved to the new field, the “verify” method in your InputVerifier gets called.
• Your InputVerifier’s verify() method returns “true” or “false” depending on whether the validation succedes or fails.
• If the verify() methods returns true the user’s wish is granted and the foucs is moved to the new textfield that the user has requested focus to.
• If the verify() method returns false, the user’s wish is not granted and the focus remains in the current field.

Please ..Anything but papayas

  Ever tasted a papaya? Some poeple like it. Some of my friends love it. It’s the fruit that I hate most! It’s so… soo.. yucky! So, as a dedication to my hatred, Let’s make a textfield accept anything, but the word “papaya”

The AnitPapayaVerifier:

   Here’s the code for the AnitPapayaVerifier class. See comments in the code for understanding

//class that starts the the anti-papaya movement
class AntiPapayaVerifier extends InputVerifier { 
 //Override the verify method to write the logic and then
 //return true or false
 @Override
 public boolean verify(JComponent input) {
	//Get the text in the text field
	JTextField couldBeEvilField =  (JTextField)input;
	String text = couldBeEvilField.getText().toLowerCase();
 
	//Check if the user has typed the p-word
	if(text.indexOf("papaya")!= -1){
		//show some arrogant message, and 
		//then return false
		//Bad guyz eat papya
		JOptionPane.showMessageDialog(null, "my JForm " +
				"dosen't grow papayas");
 
		//returning false ensures the focus, is not
		//moved out of the attached textfield
		return false;
	}
	else{
		//Nice guyz don't eat papaya
		//return true to ensure that the 
		//the focus is moved to where the 
		//user wishes to
 
		return true;
	}	
 }
}

Now all we need to do is attach it our textfield

JTextField noPapayaField = new JTextField("");
noPapayaField.setInputVerifier(new AntiPapayaVerifier());

  That’s it. Now your evil user dosen’t stand a chance against typing papaya in your text field and getting away with that.

So here’s the code to set the default button “button1″ for a frame “frame1″

frame1.getRootPane().setDefaultButton(button1);

 A corresponding method “isDefaultButton() ” is present in the JButton class to check if this is the default button.

easy?

A (Quick) look at the problem with the “Event Dispatch” thread:

    The “Event Dispatch” Thread(EDT) is a special thread in Swing where all graphical events are processed. One such event is painting the screen. Also, all the listeners attached to swing components are executed in the EDT(BTW, make it an habit to call it the “EDT”, it looks cool on interviews).
   So, get this clear, the code that paints the screen and your code that executes inside a listener, both runs on the EDT. Now, by the laws of nature, within a “single” thread operations cannot execute parallely. So when your listener code is executing, the code that paints the screen cannot execute. clear? If not read the above line again.
   Now, If your listener code takes a long time to execute(for eg., fetching large data from the network), till it’s completion the screen wouldn’t get painted. This makes the application look as if it’s hung. (You should have definitely seen this in almost all Java IDES.
If you’ve not paid attention, Wait for the time when you JAVA IDE seems to be hung,
then change the window and then come back to the IDE window. you won’t see anything on the screen, just the blank form. that’s what I am talking about)

Ok, how do I un-hang my Swing Application

   Simple. Don’t let the code in your listener execute for a long time. But what if you have to write code that takes long time to execute? For eg., what if you need to fetch large data from a db table and display it to the user when the user presses a button? Again, Simple. Execute the time consuming task in a separate thread. The paint method executing in the EDT can execute parallely when your new thread is happily waiting for the data to get fetched from the DB(yes, the laws of nature allow this). Simple, right?

   But wait, it’s not that simple. What would you do after you fetch the data. You cannot display the value directly from the new thread that you just created! As I told you all graphical operations must execute in the EDT. So you need to come back to the even dispatch thread to display the fetched values…How do you do that? I will come to that in a second. but let’s make sure you have the steps clearly defined.

So here are the steps,

• The action listener(of the button press) gets executed in the EDT
• You make a background thread to load the data [or does any other time consuming task for that matter]
• the background task calls code in the EDT to display the newly fetched data.

   From the background thread you can use methods like SwingUtilties.invokeLater() to run code in the EDT.. But….

Wouldn’t it be dreamy if …(yes, this title was picked up those head first books)

   Wouldn’t it be dreamy you could write just two methods, one method (m1) where you put the code to load data and the other method (m2) where you write the code to update the UI? Wouldn’t it be great, if automatically m1(loading the data) is called first and then when that completes,m2 is automatically called? Wouldn’t it be magical, if somehow m1 could be automatically get called in a background thread and m2 in the EDT?
   Well, lucky you, there’s a simple utility class ships with Java 6 that let’s you do this. and that class is… well, no surprise here.. The SwingWorker Class.

So SwingWorker is this..

A class having two main methods,

• method “doInBackground()” which always get executed in the background thread. This is the m1 method we were discussing in the last paragraph. Here you can put code that executes for as much time as you like!
• method “done()” which always gets executed in the EDT, and always get executed after the doInBackground() method gets finished. Same as the m2 method in the previous paragraph. So here’s where you put the code that displays the data after the data gets loaded.

An Example

SwingWorker worker = new SwingWorker<List, Void>() {
 
   //This method automatically gets executed in a background thread
   public List doInBackground() {
       //fetch the big list from the 	
       List list = getBigListAfterExecutingForLongTime();
       return intDoc;
   }
 
   //This methods automatically gets executed in the EDT
   public void done() {
      //Get method retuns the exect, same thing 
      //that the doInBackground() method returned
      List list = get();
 
      //Now do all UI Operations here..
      updateTheUIWithThisBigList(list);
   }
};  
 
 
//Code that executes when the button is pressed
public void actionPerformed(ActionEvent ae){
  worker.execute();
}

O, No!, I don’t get to use Java 6 in my project

    Don’t worry. There’s a backport of the exact SwingWorker present in Java 6 for Java 5. You can download it from here . “https://swingworker.dev.java.net/”