An unreproducible NullPointerException in NetBeans can be traced to a JTextField returning null from getText(). The cause is probably the application incorrectly calling getText() from a non-EQ thread. Nonetheless, the possibility of a null return value seems to be endemic to the call, even if made from EQ:

        Document doc = getDocument();

Not documented thread-safe, so this ought to have been done on EQ. But unlikely in practice to matter, since the JTextComponent.model was not changing in this case, only its contents.

        String txt;
        try {
            txt = doc.getText(0, doc.getLength());

This is a race condition. Even if called from EQ, Document implementations in general permit modification of the text from any thread. (Even if modifications arising from user key type events happen to be limited to EQ, an application if free to make programmatic modifications from other threads while holding a write lock.)

        } catch (BadLocationException e) {
            txt = null;
        }
        return txt;

So now if the document became shorter between the calls to getLength and getText, null is returned. This possibility is not mentioned in

     * @return the text

which implies that a String representing the current full text of the document will always be returned (so long as the document itself is not null of course). Compare to the Javadoc for getSelectedText which explicitly discusses cases in which null may be returned.