Изоморфы наступают

сложно одним фором и одним ифом решил, в 6 строк уложился))

Делал через сравнение и двумя переменными (мин знач и индекс), передавал в pair саму переменную, все нормально приняло. Поэтому не совсем понял, что значит значение должно быть элементом массива, а не целочисленным значением, если по условию задания, то это как раз должно быть целочисленное значение, которое является элементом массива, вернее в массиве есть такое же значение. Массив то примитивов, никаких уникальных объектов там нету, в любом случае в pair пойдет копия значения.

Имел в виду , что в значение Map Pair<Integer, Integer>" , необходимо передавать сам элемент массива array[0] (например) , в противном же случае , если я сначала создам переменную , а потом присвою ей значение массива элемента массива , и попытаюсь эту переменную закинуть в Map Pair<Integer, Integer>, то в таком случае валидатор будет жаловаться . В моем случае это было именно так

Ну, валидатор на это не реагирует. У меня есть отдельная копипаста по этому поводу. Осознание ошибки это половина дела, и очень вредно делать неверные выводы. Поскольку ты маскируешь основную проблему. А валидатор это такое чучело на которое можно повесить все что угодно. Мы джава профессионалы, пусть и будущие, и мы не должны повторять подход язычников к примеру, которые не могли объяснить что такое гром, и придумывали богов всего. Причинно-наследственная связь серьезная штука, должны быть веские и аргументированные основания для формирования утверждений. Почитай текст ниже, это кому-то писал ответ, такая ситуация часто повторяется, не принимай на свой счет, просто попытайся схватить суть, о чем речь. Это важно. Когда не будет валидатора, а будет работа - не там будешь искать ошибку, неделю потратишь...там где справился бы за минуту.

Часто встречаю подобное, это работает следующим образом. Есть программа, которая принимает на вход слово. И сравнивает это слово (без учета регистра) например с "амбал". Программа должна выводить в консоль: 1. результат сравнения true/false. 2. Оригинальное введенное слово. Ты пишешь:

String word = reader.readLine();
boolean isSameWord = false;
if (word.equals("амбал")) {
  isSameWord = true;
}
sout(word);
sout(isSameWord);

Программу валидатор естественно фейлит, слово АМБАЛ, АмБал проверку не пройдет. Ты делаешь изменения:

word = word.toLowerCase();
...

валидатор естественно фейлит. Проверка уже работает корректно, но ты изменяешь слово, выводится "амбал" вместо допустим "АмбАл". Ты дальше меняешь:

word1 = word.toLowerCase();
if (word1.equals("амбал") ..
sout(isSameWord);
sout(word);

Валидатор принимает! И ты приходишь к выводу: 1. Нужно использовать исключительно метод toLowerCase, без него валидатор не примет. 2. Порядок вывода важен! В первых двух случаях у тебя был другой порядок вывода, но валидатор не принимал, порядок видно не устраивал... Но эти выводы ошибочны. У тебя ошибка была в другом месте, и валидатор пропустил бы и другие варианты сравнения - через equalsIgnoreCase(), и тд. Также валидатору в данном случае все-равно какой порядок вывода, твой код не принимался из-за неверной работы самого алгоритма. Но ты будешь в твердой уверенности, что твой код приняло только потому, что ты поменял порядок вывода и использовал конкретный способ. У тебя были факторы А и Б. Фактор А (порядок вывода и способ) не принципиален валидатору. Фактор Б - это ошибка, принципиален. Твой код не принимается, ты грешишь на фактор А, меняешь код, меняешь, пока у тебя И фактор А меняется, и фактор Б попутно становится верным. Валидатор говорит - ок! И ты: "у меня без фактора А валидатор не принял..."

у меня Arrays.binarySearch() = -1, т.е. элемент не найден

это дженерики

Спасибо, так узнал про .indexOf - решение красивое получилось.