replaceAll для StringBuilder с поддержкой регулярных выражений?

String.replaceAll — это просто удобный метод для Matcher.replaceAll. Matcher - это "фактический" способ использования регулярных выражений в Java, который допускает гораздо более сложные варианты использования.

Более того, все, что можно сделать с помощью методов регулярных выражений на String, можно сделать с помощью аналогичных методов на Matcher. Прелесть в том, что Matcher работают не только с String: Matcher можно получить для любого CharSequence (интерфейс, реализованный StringBuilder, StringBuffer, String и CharBuffer). Итак, вы можете просто сделать:

import java.util.regex.*;

...

StringBuilder sb = new StringBuilder();
sb.append("This works with StringBuffers");
Pattern p = Pattern.compile("\\Buffer\\B");
Matcher m = p.matcher(sb);
System.out.println(m.replaceAll("uilder"));

Выведет This works with StringBuilders.

Рабочая демонстрация.

Regex не изменяет изменяемый CharSequence внутри. Regex анализирует CharSequence, чтобы вернуть String, где String — результат. StringBuffer является исключением, так как существует особая обработка - поскольку StringBuilder является CharSequence, вы должны изменить его с результатом совпадения.

Что вы можете сделать вместо этого:

// Class
private static final Pattern MY_PATTERN = Pattern.compile("my|regex");

{ // Method
    StringBuilder builder;
    // ...

    Matcher m = MY_PATTERN.matcher(builder);
    builder.replace(0, builder.length(), m.replaceAll("<b>$0</b>"));
}

Посмотрите демонстрацию тестового кода!

Я не хочу идти по этому пути, потому что StringBuffer медленнее.

Верно, но с обычной оговоркой о преждевременной оптимизации и, что более важно, современные JVM используют escape-анализ для удаления StringBuffer. /Vector/HashTable блокируется в некоторых случаях, поэтому после оптимизации производительность будет примерно такой же.

Apache Harmony Исходный код Matcher кажется полностью переработанным для использования с StringBuilder вместо используемого в настоящее время StringBuffer, просто перейдите в другой пакет. Вроде не таскает за собой много зависимостей. Лицензия Apache, которая находится в начале файла, может быть неплохой даже для коммерческого проекта.

Код GNU Classpath также можно использовать повторно, но лицензия там сложнее (вам нужно опубликовать измененную версию Matcher, но, вероятно, не остальной код). То же самое касается оригинальной реализации Sun, которую можно найти здесь в проекте OpenJDK.