всё строго по тз)))

для этого же есть javadoc, который и обьяснит предназначение

Так давай правильные советы)

Ахах, насмешил)

Я посмотрю на объяснение в джавадоке чего то подобного

List<Triple<Pair<Apple, Integer>, Quadri<Integer, Spring, Spring Double>, Float>>

Код должен быть самодокументирующимся

+

для запроса который в снипете сойдёт, за пределы метода не протечёт так что норм, а для большего нужно и больше инфы

Не сойдёт, то что ты предложил - дичь

Там тоже нету дефолтового конструктора - создал свой класс в итоге.

Спасибо, оно заработало как нужно

Не согласен, что класс Pair не нужен. Особенно с приходом в жаву стримов частенько ощущаю его нехватку и в каждом проекте приходится смотреть, какие либы подключены к этому конкретному проекту и в зависимости от этого использовать одну из множества реализаций Pair/Tuple, которая есть почти в каждой либе/фреймворке (это уже о многом говорит - был бы он не востребован, такой ситуации бы не сложилось).

Да, я согласен, что публичное апи, возвращающее или принимающее Pair - не комильфо. Но есть множество применений для внутренней реализации методов, где создание нового класса на каждый чих - это уже оверкил. Например, в тех же стримах часто бывает так, что мы хотим сделать .map, но при этом не потерять контекст (какой объект мы смаппили на вот это новое значение). Тут создание и применение Pair идет обычно рядом, на расстоянии 1-3 строчек. Так что забыть, что же там за элементы положили внутрь Pair - довольно сложно. Лишняя семантика тут ни к чему. Она тут только создаст лишнее нагромождение.

Самый близкий аналог Pair в стандартной библиотеке Java это AbstractMap.SimpleImmutableEntry и его конечно можно использовать, но длина названия класса и отсутствие статического билдера (.of) этому не способствует. Да и название элементов key/value в нем добавляет лишнюю семантику, которая для универсального класса Pair скорее вредна, т.к. далеко не всегда в ней лежат значения, которые семантически можно назвать ключом и значением.

Еще можно List.of() использовать, если Java 9+. Класс вроде бы совсем не для этого предназначен, но лаконичностью использования (по сравнению с AbstractMap.SimpleImmutableEntry) выигрывает. Но проигрывает в другом.

Я совершенно согласен, что такие вещи нужно использовать осторожно. Но не добавлять в ЯП что-то только потому, что существует опасность, что кто-то может это использовать неправильно - это такая себе причина.

Добрый день,
нужен concurrent list в сервисе, можно ли Collections.synchronizedList(List) для этих целей использовать?

да, тоже для стримов используем AbstractMap.SimpleEntry и не паримся, про публичное апи полностью согласен - о том и говорил. но в язык его не вносят же не просто так)

у нас в зависимостях ни одного публичного Pair, о котором бы заявляли - берите и используйте

Прошу прощения не гуглил и в вопрос не так погружен, но Pair это замена кортежей не специально ли разработчики языка отказались от них. В джаве есть pair от лени когда не хочется сделать pojo с описанием полей и т.д.

И делать их каждый раз в каждом проекте заново, да ещё, возможно, и разные под разные цели? Надо соотносить лень и эффективность. А ещё есть принцип DRY.

Добрый день, пишу API, на который в Request body POST-метода приходит json с неэкранированными символами

Пример запроса после которого возвращает 400-ю ошибку

{
    "description":"Новоб"удови у Львові",
    "city":"Львів"
}

Пробовал решить проблему при помощи JSONObject.escape(), но неудачно

Подскажите в каком направлении думать и, если есть возможность, поделитесь ссылкой на документацию (обшарил stackoverflow, их решения не работают)