Java: Swing: Text components and Document: AbstractDocument

AbstractDocument

Features

Locking

Since JDK 1.4, the locking mechanism is almost acceptable, except that writeLock/Unlock have to be public, and that InterruptedExceptions are converted into non-specific errors.

Content

Element structure

Element implementation is good in principle. BranchElement has little leak. The AttributeSet implementation has a few kinks.

ElementEdit needs to clone the arrays.

DefaultDocumentEvent breaks if there are multiple ElementChanges for the same element.

Bidirectional text

Composed text

No support here, rather anti-support: Composed text destroys the Undo history.

New methods

The following methods/fields are new (not in Document):

public static final
{
    SectionElementName, ParagraphElementName, ContentElementName, BidiElementName: String;
    ElementNameAttribute: String;
}

public
{
    property documentProperties: Dictionary;
    property asynchronousLoadProperty: Integer;
    property documentFilter: DocumentFilter;

    bidiRootElement: Element;
    paragraphElement(Int): Element;

    replace(position, length: Int, String, AttributeSet)
        throws BadLocationException;


    readLock;
    readUnlock;

    dump(PrintStream);
    
    listeners(Class): Array[EventListener];
    documentListeners: Array[DocumentListener];
    undoableEditListeners: Array[UndoableEditListener];
}

protected static final
{
    BAD_LOCATION: String;
}

protected
{
    listenerList: EventListenerList;
    content: Content;
    attributeContext: AttributeContext;

    insertUpdate(DefaultDocumentEvent, AttributeSet);
    removeUpdate(DefaultDocumentEvent);
    postRemoveUpdate(DefaultDocumentEvent);

    newBranchElement(parent: Element, AttributeSet);
    newLeafElement(parent: Element, AttributeSet, start, limit: Int);

    fireInsertUpdate(DocumentEvent); fireRemoveUpdate(DocumentEvent);
    fireChangedUpdate(DocumentEvent);
    fireUndoableEditUpdate(UndoableEditEvent);

    currentWriter: Thread;
    writeLock;
    writeUnlock;
}

Diff

1.3.0 (112):

defaultI18NProperty; putProperty(RUN_DIRECTION) updates bidi if i18n; insertString updates i18n; isLeftToRight is always true without i18n; updateBidi is private and handles Change DocumentEvents; default paragraph direction taken from RUN_DIRECTION attributes
notifyAll (but not in readUnlock); InterruptedException printed; render readLock fixed
+getListeners

1.3.1 (119): Undo names from UIManager; MultiByteProperty (as String)

1.4.0 (130): MultiByteProperty is Object; counting writeLock (+notifyingListeners flag); DocumentFilter

+ getDocumentListeners + getUndoableEditListeners

+ isComplex (Indic/Thai); calculateBidiLevels uses Bidi constructor with flags

1.4.2 (140): replace checks for void operations; MultiByteProperty is String again; AttributeContext.reclaim not called anymore

1.5.0 (151): generified; surrogate characters are complex; Segment used internally; Undo event type fixed; DocumentEvent.getChange always uses equals

1.6.0 (157): isComplex code moved to SwingUtilities2

Use

Subclasses

PlainDocument

DefaultStyledDocument

HTMLDocument

Locking

The following classes lock (read/writeLock/Unlock) the document iff it is an AbstractDocument.

JTextComponent

BasicTextUI

ComponentView

html/HiddenTagView

html/ImageView

Bidi structure

Apparently for proper handling of bidirectional text, getBidiRootElement() (and inspection of the bidi structure) and isLeftToRight() are required.

This happens in the classes:

DefaultCaret (paints a handle for the bias if it noticed bidirectional text)

ParagraphView

TextLayoutStrategy

GlyphPainter2 requires it: (#4430777).

Miscellaneous

JEditorPane - calls getAsynchronousLoadPriority() and maybe starts a reader Thread. Since that is a property of the Document anyway, there is no need for the test at all.

DefaultEditorKit.DumpModelAction - calls dump().

html/MinimalHTMLWriter - tests for BranchElement for handling paragraphs.