FULL PRODUCT VERSION :
java version "1.6.0_23"
Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
Java HotSpot(TM) 64-Bit Server VM (build 19.0-b09, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7600]

A DESCRIPTION OF THE PROBLEM :
Handling of decomposed unicode characters require ~20 times more in JDK 1.6 and JDK 1.7, than in the JDK 1.5.

My short test require about 270ms for JDK 1.5, but about 5000ms in JDK 1.6 and JDK 1.7.

MacOS has much worse results: JDK 1.5: 2100ms, JDK 1.6: 41s


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Just try to add many decomposed unicode chars into JEditorPane.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Performance should be almost the same like for JDK 1.5.
ACTUAL -
Performance slower in 20 times.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.text.Normalizer;

import javax.swing.JEditorPane;
import javax.swing.JFrame;

public class TestSpeed {
    public static void main(String[] args) throws Exception {

        // Prepare text (1000 lines with 100 chars)
        // Since JDK 1.5 doesn't have Normalizer,
        // you need to prepare it something else, from file, for example.
        StringBuilder o = new StringBuilder();
        for (int i = 0; i < 100000; i++) {
            if (i % 100 == 0)
                o.append('\n');
            o.append(Normalizer.normalize("ü", Normalizer.Form.NFC)); // u with umlaut
        }
        
        // Create UI
        long st = System.currentTimeMillis();
        JFrame f = new JFrame();
        final JEditorPane e = new JEditorPane();

        // Set prepared text
        e.setText(o.toString());

        f.setContentPane(e);
        f.pack();
        f.setSize(800, 700);

        f.setVisible(true);
        long en = System.currentTimeMillis();
        System.out.println("Time=" + (en - st) + "ms");
    }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Use composed unicode chars, which only 2 times slower.