<Swing Dev> Extension method for AbstractDocument.Content?

[Paulo Levi]

Hi Pavel.

On Thu, Jun 21, 2012 at 2:13 PM, Pavel Porvatov
<pavel.porvatov at oracle.com>wrote:

> Hi Paulo,
>
>  Hi. I've noticed that DefaultStyledDocument has a slowness issue when
>> inserting text. Even if you subclass it and expose the faster method:
>> protected void insert(int offset, ElementSpec[] data)
>>
>> the body of the method still uses a stringbuilder to append all char[]
>> inside of the data before actually inserting into the content.
>>
>> This is because the only method for insertion in the default content
>> interface is:
>> public UndoableEdit insertString(int where, String str)
>>
>> Now if there are going to be extension methods in java 8, it would be
>> nice to have a
>> public UndoableEdit insert(int where, int index, int length, char[] str)
>> default {
>>   return insert(where, new String(index, length, str);
>> }
>>
> In which class do you suggest to add the new method?

It would need to be part of AbstractDocument.Content with the new extension
method feature in order to be able to be part of the public interface of
Content and be useable generally without casts. I suppose you can also just
modify the current method
DefaultStyledDocument.insert(int offset, ElementSpec[] data)
by using 'getContent() instanceof GapContent', casting and using the
GapVector (superclass of GapContent) replace method directly, instead of
going through the public Content API, which needs to a string (thus the
stringbuilder, creating a string that is only used as a char [] holder.


with a adequate specialization in GapContent (that obviously doesn't call
>> the string version), and that that new method is used in the
>> protected void insert(int offset, ElementSpec[] data)
>> method (and where it makes sense)
>>
> I'm not sure I understand correctly the last sentence. Could you please
> clarify that, please?
>

It's how i understood the new extension methods work; you provide a simple
no-state implementation in the interface (which is possible in this case
with AbstractDocument.Content.insertString(int where, String str) ) and
then implementations specialize the method for speed.
I was also speculating that this is maybe not the only place where such a
method makes sense.


Anyway, the speed penalty of the buffered insert (which you have to extend
DefaultStyledDocument or use reflection to access anyway) of first creating
a new large string with all the text that is only going to be
String.toCharArray() in the next method is very significant if your text is
actually something you'd like to buffer (like war and peace for instance).
Either way that the bulk insert method is improved, either by instanceof
cast or new public api in Content taking advantage of extension methods, i
think it should be fixed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120621/9c6adf3f/attachment.html>