JDK-4080391 : TextArea.setText() doesn't work for large Strings.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version:
    1.0.2,1.1,1.1.1,1.1.2,1.1.3,1.1.4,1.1.5,1.1.6,1.1.7,1.2.0,1.3.0 1.0.2,1.1,1.1.1,1.1.2,1.1.3,1.1.4,1.1.5,1.1.6,1.1.7,1.2.0,1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows_95,windows_nt
  • CPU: x86
  • Submitted: 1997-09-19
  • Updated: 2000-02-27
  • Resolved: 2000-02-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.3.0 kestrelFixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
Name: diC59631			Date: 09/19/97

The code below calls TextArea.setText() with a
large String. The constant STRING_SIZE determines
how many lines of 10 bytes will make up the String.

When STRING_SIZE is 5000 (ie a 50k String) the
whole string is displayed.
When STRING_SIZE is 6000 (ie a 60k String) nothing
is displayed.
*************************************************

import java.awt.*;

class TextAreaSize extends Frame {
   /* Demonstrates the limit to the amount of text that can
      be displayed in a TextArea.
      When STRING_SIZE is 5000 (50K of text) all the text is displayed.
      When STRING_SIZE is 6000 (60K of text) NO text is displayed.
   */

   static final int STRING_SIZE = 6000;

   public static void main(String[] args) {
      new TextAreaSize();
   }

   TextAreaSize() {
      super("TextAreaSize Test Frame");

      setSize(300,300);

      Panel pnl1 = new Panel();
      add(pnl1);
      pnl1.setLayout(new BorderLayout());
      TextArea textArea = new TextArea();
      pnl1.add(textArea);
      setVisible(true);

      StringBuffer bigStringBuffer = new StringBuffer();
      for(int i=0; i < STRING_SIZE; i++) {
         bigStringBuffer.append("123456789\n");
      }
      textArea.setText(bigStringBuffer.toString());
      System.out.println("String size=" + bigStringBuffer.toString().length());
   }
}

======================================================================

ronan.mandel@Eng 1997-11-04
Another Case:
I am not sure it's the same as bug 4067898.
For method replaceRange, insert, or append 
in class TextArea, after you use a big string
as the parameter, you can only delete texts; you
can not input texts.

Here is the code:

import java.awt.*;

public class Test extends Frame         
{
   
   public Test(String title, String  argv[])
   {
      super(title);

      TextArea textArea = new TextArea(40, 30);
      textArea.setEditable(true);
      this.add("Center", textArea);
      String bigString = new String();
      for (int i = 0; i < 1500; i++)
	 bigString = bigString.concat(i+"abcdefghijklmnopqrstuvwxyz\n");
      System.out.println("Replace String " + bigString);
      textArea.replaceRange(bigString, 0, textArea.getText().length());    
   }

   public static void main(String argv[])
   {
       
      Test frame = new Test("Test", argv);
      frame.setSize(800, 600);
      frame.setVisible(true);
   }   

}

################# From the so#3175931 customer ###############
 Sun14Dec97-16:00 BELLEY

The following is a summary of the issues we discussed yesterday evening
about the problem that I have encountered when running my JAVA application
with the SUN JRE versions 1.1.5 and 1.1.2 on the Windows 95 operating
system, service order #3175931. 

The project that I am developing is soon to be released in Beta (Jan 16th).
Our final release is scheduled for some time in February.While testing, it
was discovered that when very large strings of text are placed in my
java.awt.TextArea component using the setText() method, the text will not
show in the text box. No errors are generated by the program when this
happens. 

I browsed the SUN web site and found the "Bug Parade" page
(http://developer.javasoft.com/developer/techDocs/knowledgebase.html).
Searching on the "TextArea" keyword, I found several bug reports which are
strikingly similar to my findings--specifically Bug Id 4080391. (The others
are 4071955, 4064198, 4082558, 4061916, 4039177, and 4038047.) It appears
that none of these bug reports are currently being investigated.

I have discovered that when the text area is in read-only mode, I can get a
little over 50,000 bytes of text to show. If the text area is in writable
mode, I can add up to about 28,000 bytes before it stops accepting any more
text.

This problem occurs on Win95 but NOT on WinNT. It is my understanding that
the Windows 95 operating system still uses 16-bit implementations in some
of its lower level windowing routines, and I am suspecting that this is at
the root of the problem.

The completion of this product is very high priority for my company. We
cannot release our product with this text box limitation as many of our
customers will be running in the Win95 environment. 

It is important for me to know if SUN intends to pursue a fix or
work-around for this problem, how soon I might be able to expect the
fix/work-around. If a fix/work-around is not available, I will be forced to
investigate Microsoft's JVM which is something that I really do not want to
do.

Please let me know if I can provide you with any other information. Sample
test programs are provided by the authors of the previously mentioned Bug
Id 4080391, so I have not included any.

#########################

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic FIXED IN: kestrel INTEGRATED IN: kestrel
14-06-2004

PUBLIC COMMENTS The String size of up to 100K was tested on Windows NT 4.0 SP5, P-II 350 machine with JDK 1.3RA.
10-06-2004

EVALUATION There is a limitation on the amount of text a Win95 edit window can hold. Microsoft has set this limit at 32K, minus some overhead. Attempts to load more than 32K into a text area can produce strange behavior, although it should be possible to load in up to 64K if the TextArea is in read-only mode. Reports vary between users on the exact amount of text that can be displayed. Users have variously reported being able to display as little as 25K, or as much as 43K on Windows 95. I can display over 70K on Windows NT 4.0 with no problem. A Work-around would be to use the Java-based text components supplied with Swing. eric.hawkes@eng 1998-01-27 The capacity of the native windows text widgets has been set to the maximum possible. On win95 this is 0x7FFF for TextFields, and 0xFFFF for TextAreas. On winNT this is 0x7FFFFFFF for TextFields, and 0xFFFFFFFF for TextAreas. This work was done as part of the fix for 4260109. In cases where this is not enough space, a workaround would be to use lightweight components: either Swing-based components, or lightweight AWT components. The TextComponent work done for 4260109 definitely should be back-ported to Dino. eric.hawkes@eng 1999-11-05 ========================================================================= Tested on Windows NT 4.0 SP5 with P-II 350 and 64MB RAM and JDK 1.3RA. I was able to get a string of 100K inserted. Since the limit of a LARGE STRING is unclear or not really defined, I am closing this bug as sufficiently supportable under JDK 1.3RA on NT. sandeep.konchady@Eng 1999-12-21 We have had a request to clarify the reason for closing this bug. As discussed above, we set the limit to the maximum in JDK1.3. I am therefore changing the reason for closure to be "fixed in JDK1.3." There is another bug report open that requests this functionality be backported to a 1.1.x release: 4316821. eric.hawkes@eng 2000-02-27 Note: the maximum size for a TextArea is now essentially unlimited on both Win9x and NT/2000 in Merlin as we converted TextAreas to use RichEdit 1.0 controls. See bugid 4341196. eric.hawkes@eng 2000-11-29
29-11-2000