Name: krT82822 Date: 02/27/2000


(please also see Comments section)

java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O)
Java(TM) HotSpot Client VM (build 1.3beta-O, mixed mode)

This bug occurs on versions all the way back to JDK 1.1

It doesn't seem that anyone can agree what the bug actually is.
Some say after the 250th line I get whatever problem, and others say
around 25k or 35k is where the problem exists. I have done some extensive
testing, and I have determined the following:

The TextArea is editable up to 30,000 characters on the mark. To see for
yourself, type any character or random set of characters (no carriage returns),
and copy and paste those characters until it will not allow you to paste
anymore. Take the String from the TextArea, and save it to a file (either from
within your code, or by selecting all and copying, then pasting to Notepad).
Look at the properties of the resultant file, and you will see 30,000 bytes on
the mark, EVERY TIME. I have tested this on NT, 95, and 98, and all yield the
same result.

Some say there is a problem programatically inserting over 60,000 bytes. I have
not tested this, and I will not provide a reproducable test case.

Use the following sample code with the procedure explained above, and you will
reproduce this bug:

import java.awt.*;

public class TextAreaBug extends Frame
{
    public TextAreaBug()
    {
        super("TextAreaBug");
        setLayout(new BorderLayout());
        TextArea ta = new TextArea();
        add("Center", ta);
        setSize(400,400);
    }
    
    public static void main(String[] args)
    {
        TextAreaBug tab = new TextAreaBug();
        tab.setVisible(true);
    }
}

Or, if you are feeling kind of lazy, you can use this to reproduce the bug:

import java.awt.*;

public class TextAreaBug extends Frame
{
    public TextAreaBug()
    {
        super("TextAreaBug");
        setLayout(new BorderLayout());
        TextArea ta = new TextArea();
        String text = "a";
        for(int i = 0; i < 29990; i++)
        {
            text = text + "a";
        }
        ta.setText(text);
        add("Center", ta);
        setSize(400,400);
    }
    
    public static void main(String[] args)
    {
        TextAreaBug tab = new TextAreaBug();
        tab.setVisible(true);
    }
}

You will then have to type 10 more characters to obtain your 30,000 limit.
(Note, that since you will have a for loop of ~30000, it will take a minute
or two for the application to become visible, be patient).

Now, this has been reported as a problem with Microsoft Windows, however,
Microsoft's version of a JVM doesn't have this 30,000 byte constraint.

-------------------

1/24/2000 email from user:

Here is the MS VM that works on NT40 SP5

        Microsoft (R) Command-line Loader for Java Version 5.00.3167
        Copyright (C) Microsoft Corp 1996-1999. All rights reserved.

        Usage: JView [options] <classname> [arguments]
...
I am not currently at home, so I cannot give you the info on the MS VM's for
each of those machines, however I can tell you that they are the VM's that
come with Win98. If you like, I can check version numbers when I get home
tonight. I really do not see how this is relevant though. The fact still
remains that Sun jdk versions 1.1 and on have this limitation. If you guys
don't want to fix it, that's fine, but don't close the bug as "not
reproducible", because that is simply not true. You may decide that this is
not a bug. If so, you must at least agree that this is a limitation of your
product. Although I am not a big fan of Microsoft, I don't think it is fair
if you try to pin this one on them. If Microsoft can implement a JVM that
doesn't have this problem, then there should be no reason why you guys
can't.

I don't want you to take any of this personally, it is just that sun has
done such a good job with java in the past, that I hate watching you (sun)
slowly destroy such a great language. I have dedicated the past 4 years of
my life to this language, and it tears me apart when I wait almost a year
for a bug to be fixed only to have it closed as "not reproducible",
especially when it is so simple to reproduce.

I hope that we can resolve this issue. Currently, this is the most
important issue I have open with the current implementation of java. It is
not setting me back in development, but like I said, I have been keeping my
eye on this one for almost a year, waiting for it to be fixed.

I appreciate your consideration of this bug, but please, if you are not
going to fix it, at least close the bug for some other reason besides "not
reproducible".

---------------------------------------

1/25/2000 (more) email from user:

I cannot say for sure if win95 works with an MS VM, I honestly haven't tried
the MS VM on 95. The problem is that there isn't an MS VM that comes with
the Win95 installation. All of sun's jdk's 1.1-on do have this limitation
on 95. Just recently, I placed both of my Win95 PC's in boxes in my garage.
I can dig one of them out tonight, download MS's JVM, and try it. I don't
know why MS's VM wouldn't work on 95 though, because it works on NT40, and
both are almost the same age. I can't tell much difference between the MFC
for 95 and the MFC for NT40. I could be wrong.


(Review ID: 100310)
======================================================================