This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 44152 - PropertySheet is not able to deal with large amount of data.
Summary: PropertySheet is not able to deal with large amount of data.
Alias: None
Product: platform
Classification: Unclassified
Component: Explorer (show other bugs)
Version: 4.x
Hardware: PC Windows ME/2000
: P2 blocker (vote)
Assignee: _ tboudreau
: 42111 (view as bug list)
Depends on:
Reported: 2004-06-02 10:18 UTC by Jan Jancura
Modified: 2008-12-22 23:53 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jan Jancura 2004-06-02 10:18:49 UTC
1) create some string property.
2) display it in TreeTableView.
3) return some big string (~500kB) as a value of
this property

=> TreeTable is very slow while displaying it.

4) open property editor ("..." button) for it

=> NetBeans goes to Hollywood...
(100 of CPU, not responding)
Comment 1 Jan Jancura 2004-06-02 10:19:57 UTC
*** Issue 42111 has been marked as a duplicate of this issue. ***
Comment 2 _ tboudreau 2004-06-02 11:07:05 UTC
This may be a dumb question, but what can a user usefully do with a 500K string 

Probably I can do something about this, but I don't see much point.  Having a property 
sheet that supports 500K string properties is of no benefit to our users, and making it 
support that means spending engineering time that could be spent doing fixes users will 
actually benefit from ("I need an infinitely scalable property sheet" just isn't in the top 10 
things we need to fix).

Under what circumstances will the debugger generate a 500K string property?  And why on 
earth are you doing that?  It surely impacts the debugger's performance as well.

As far as I'm concerned, the fix for this is "Don't generate 500K properties, that's a dumb 
thing to do."  Convince me there's a valid use case here.  And tell me how to reproduce the 
situation with the debugger in some reasonable usage scenario.

Note that the problem may just be calculating the preferred size of the cell.
Comment 3 Jan Jancura 2004-06-02 12:32:45 UTC
I do not understand your question. The described behaviour is bug, and
it should be fixed. If PS is not able to deal with some large strings
it should test it, and do something - throw "ToLargeStringException",
display some part of string only, or...

The original bug has occurred during displaying of value of some
variable in debugger. We can not restrict the length of strings in
user applications.
Comment 4 _ tboudreau 2004-06-02 13:02:01 UTC
> We can not restrict the length of strings in
> user applications.

But you can certainly detect whether the debugger is being asked to do something crazy 
or not.  And you certainly do know that Node.Property objects are presentation layer 
objects, and you can certainly detect if your Node.Property is going to return a 500K 
string, and truncate it, because you know in fact that the debugger has a UI, that that UI 
has reasonable limitations, and that in fact debuggers do not operate in a theoretical 
universe where all values can be infinitely large, but in a practical one where limitations 
exist.  All of which has nothing to do with what size value the user program can return, 
and everything to do with the debugger placing reasonable burdens on the UI in which it 

Do we really think somebody out there has a 4.8 kilometer wide monitor that is going to 
successfully display the thing?  What's next, "cannot display a string longer than 

I can probably do something for the inline display of such properties, and probably make 
that fast.   

For editing them, either inline or in the custom editor, the performance characteristics will 
be those of JTextField and JTextArea, respectively.  If they do not handle 500K of data 
passed into setText() well (this would not surprise me), there's nothing I can do about it.  
Which is exactly why this should be fixed in the debugger, NOT in the property sheet.
Comment 5 Jan Jancura 2004-06-02 13:30:29 UTC
I do not agree:
1) You know the limits of your piece of code. I do not know the
technology (and UI) used to display Strings in custom editors. You are
providing some "platform".
2) You can check the limits on one place, and do some correct
things... Otherwise we should check limits on many places in modules code.
3) You can deal somehow with large files. Why you do not use NetBeans

BTW what is the limit?
Comment 6 _ tboudreau 2004-06-10 19:21:19 UTC
Fixed in trunk - performance should be reasonable now.  Tested with 
both property sheet and property panel.

Note that word/line wrap is now off in the custom editor for huge 
strings - usage of JTextArea.setText() + word/line wrap for this 
simply doesn't scale.  A custom implementation of 
javax.swing.text.Document (such as the new output window uses) could 
work, but is hardly justified.

C:\space\nb_all\core\src\org\netbeans\beaninfo\editors>cvs commit -
m "#44152 Performance problems when debugger produces >512K long 
strings, part 1"
cvs commit: Examining .
Checking in;
new revision: 1.26; previous revision: 1.25
Checking in;
/cvs/core/src/org/netbeans/beaninfo/editors/,v  <--
new revision: 1.20; previous revision: 1.19
Processing log script arguments...
Mailing the commit message to (from
commit -m "#4
4152 performance problems with >512K long strings from debugger, 
part 2"
cvs commit: Examining .
cvs commit: Examining editors
Checking in;
 <--  PropU
new revision: 1.35; previous revision: 1.34
Checking in;
ava,v  <--
new revision: 1.13; previous revision: 1.12
Checking in;
ava,v  <--
new revision: 1.5; previous revision: 1.4
Checking in;
new revision: 1.14; previous revision: 1.13
Processing log script arguments...
Mailing the commit message to (from 
Comment 7 Jan Jancura 2004-06-11 12:11:57 UTC
Its much better now!
Thank you.