Не очень понятно по каким проблемам... Наверное по toUpper?

Изначально. При проектировании Java была заложена возможность хранить строки как UTF-16 (short) массивы.
Это с точки зрения внутреннего (internal) способа хранения. В Java строки ВСЕГДА в Unicode.
Если вы грузите данные из внешних источников которые ASCII или национальные кодировки
то вы обязаны их конвертить byte[] => char[] где char тоже всегда 16 битный.

Далее. Как я уже говорил. Начиная с какого-то коммита Java-9 внутренний формат стал более экономным. Latin/utf-8
Но и в Java <9.0 и начиная с девятки следующий код будет иммитировать совершенно одинаковое поведение.

Тоесть интерфейс String::charAt() возвращает всегда 16 битный char. И это жосткий requirement.


При этом строка s1 по идее должна внутри выделять utf-8 массив символов а вторая строка - ascii.

Тоесть форматы хранения и представления - разные.

Существуют быстрые (по времени) конструкторы которые конструируют строку из char[]. Этим пользуются
библиотеки билдеров StringBuilder для быстрых конкатенаций.

Кроме того у java-строки есть другие свойства. Например она - иммутабельна. Вы не можете изменить внутри
строки символы. Попытка делать replace() просто приводит к генерации нового объекта типа java.lang.String
где символы уже заменены. Эти опции - кивок в сторону чистого функционального программирования без concurrency.
Она (строка) также - финальна. Вы не можете унаследоваться от нее и переопределить поведение.
Она инкапсулирует длину и хешкод для оптимизации алгоритмов над ней.

Я попробовал фрагмент Войны и Мира на функции String::toUpper()/toLower(). Все отработало успешно
для кириллицы и французского. Никаких национальных настроек я не делал. Все по дефолту.
Тоесть функция toUpper скорее всего включала в себя известный сет маппингов для известных
языков.

Тест кейсы могу привести если интересно.

Какие конкретно части стандарта Unicode инкапсулированы внутри java-string я не знаю. Но я могу поискать информацию
если вам интересно.

В типичном backend - приложении строки - самая прожорливая часть кучи. Весь современный веб стоит на процессинге
данных типа XML/Json которые в свою очередь порождают массу справочников и фабрик и прочих компонент
которые будут выделять строки и много.

Любое приложение типа бизнес-процесс которое работает с БД будет так или иначе использовать кеши со строками.
Любое приложение активно формирующее отчеты xml/Excel, PDF, html также активно будет много выделять и
использовать строк.

Я не имею ничего против вашего списка. Я просто вношу дополнения.

2 All.

Кто продвинут в Unicode. Помогите транформировать этот тестовый текст
MSVC и GCC: совместимость кодировок исходников
в последовательность с comnining characters.

Я расширю этот тест для функций upper/lower чтоб посмотреть как комбинации себя ведут на разных API.

Потом сделаю это для C#/Python/e.t.c.

С++ изначально находился в невыгодном положении. Он делегировал "строковый тип" не языку а библиотекам.
И мы имели CString, std::string, TString e.t.c. Это все строки. Или обертки над строками. Каждая со своим интерфейсом
и со своим поведением и со своими правилами внутреннего предсталвения. Некоторые из них могут зависеть
от дефиниции макроса _UNICODE

И господин Бьярне и комитет все эти годы занимались чем угодно только не этим вопросом. Можно сказать что в С++
строки развивались по scrum-agile. Итеративно. Решая сиюминутные потребности.

Волевого решения "из центра" - не было.

Возможно. Если хранить вместе со строкой признак кодировки.

Даю линк на репозитарий OpenJDK. Он во многом похож на Оракловый.
https://github.com/unofficial-openjdk/openjdk/blob/jdk/jdk/src/java.base/share/classes/java/lang/String.java

Возможно я ошибся в кодировках. Там


Я еще просмотрю историю коммитов. Возможно что-то проскочило из того что я говорил. А это транковая ветка.
Соотвествует JDK которой еще нет в релизе.

Да в этих комитетах - царит какое-то разложение. Есть у них хоть один proposal который ужесточает стандарт?
И делает его более... недёжным что-ли. Предсказуемым на разрядности int к примеру.

Вот честное слово я уже не верю в комитеты. Если-бы толстая корпорация типа yandex взяла управление
в свои руки и сказала - ша бротва! Мы делаем свой С++. И там будет мать ево Unicode-строка как
фундаментальный образующий тип языка. А все синонимы мы просто выкосим нахер. И опубликуем как форк С++
стандарта по версии yandex. Я-бы встал и поаплодировал.

И жизненных примеров много. Когда источником нового языка была именно корпорация а не всякие бл...ские комитеты.