Массив байт

размер массива храниться в Int вы же не сохраняете в масив строк размер

String [] arg = new String["Сто двадцать восемь"]

размер массива храниться в Int
вы же не сохраняете в масив строк  размер

это я в курсе . просто из такого вопроса

но валидатор не принимал, хотя результат такой же. Почему нельзя решать через массив байт?

не видя самого кода я сделал вывод , что byte это слишком мало, каков вопрос , таков ответ.ж

не видя кода можно было сделать множество выводов ))) вплоть до того какой метод read используют, (возвращают они разное в зависимости от перегрузки), до того что просто забыли что возвращают int) я думаю что человек на 8 уровне Core знает объем значения byte, из этого и исходил мой ответ вам)

исходя из этого кода

try(FileInputStream  reader = new FileInputStream(args[0])){
        int [] arg = new int[128];
        while(reader.available()>0) {
             arg[reader.read()]++;
        }
        for(int i = 0;i<arg.length;i++){
             if(arg[i]!=0){
                 System.out.println((char)i + " " +arg[i]);
											}
        }

просто хочу добавить , что метод read() возвращает не само значение byte, а его представление в 32х битном виде, то есть диапазон byte в Java лежит от -128 до 127, а возвращаемое значение метода read() лежит в диапазоне от 0 до 255. Если массив типа int то проблем нет , ну и конечно если бы использовался read(byte[]), то может быть и проблемы не возникло

не возникло бы... так как кодировка Ascii 127 символов так что ArrayIndexOutOfBoundsException не грозит ему в любом массиве...размер которого [128] и тогда уж от -1 до 255 кроме 0

правда на счет 0 не уверен)) да read(byte[]); - не может 0 вернуть)) тут напутал)

read(byte[])

читает конкретно массив байт и тут

byte [] arg = new byte[128],

конкретно всё прокатит

?

Мы тут развели дисукусию не на чем , вся проблема , как мне кажется, в том , что

Методы	                          Описание
int read()                            Читает один байт из потока

если было бы

byte read()

то проблем не было бы , а раз он int , то это выражение не верно

arg[reader.read()]++;

все верно в этом выражении, то что возвращает read() - это codePoint, автор использует его как индекс в массиве... и инкрементит значение при повторе.

всё верно ,если

int [] arg = new int[128];

если, как в вопросе

byte [] arg = new byte[128]

то не прокатит

в условии задачи

Программа запускается с одним параметром - именем файла,
который содержит английский текст.

в таблице ascii английские буквы лежат в диапазоне до 128 символов

Я не могу с вами общаться так как вы постоянно редактируете свои сообщения, я пишу ответ на одно, потом читаю другое

в таблице ascii английские буквы лежат в диапазоне до 128
символов

Всё верно , если бы читали с помощью read(byte[]), то всё бы прокатило , потому , что он возвращает количество реально прочитанных байт, а read() может вернуть от 0 до 255, поэтому ввлидатор и не хочет принимать . P.S

Я не могу с вами общаться так как вы постоянно редактируете свои сообщения, я пишу ответ на одно, потом читаю другое

Я тоже ошибаюсь , как и все, и поэтому пытаюсь быстро испрвить .

Вы не понимаете ни то о чем говорите, ни код автора Проблем с методом read() - нет

Ответ Ксения уже написала 3 часа назад если вы не поняли то объясню, в массиве байт как только результат инкремента превышает 127 , значение становится отрицательным

try(FileInputStream reader = new FileInputStream(args[0])){ int [] arg = new int[128]; while(reader.available()>0) { arg[reader.read()]++; } for(int i = 0;i<arg.length;i++){ if(arg[i]!=0){ System.out.println((char)i + " " +arg[i]); } }

почему валидатор не принимает так: byte [] arg = new byte[128];

Потому что символ может встречаться больше 127 раз.

А если он встречается 10000000 раз?

Мне кстати оч понравилась ваша идея

arg[reader.read()]++;

Значение после max_value +1 становится min_value как у любого примитива целочисленного) 10кк эт инт еще)

а ну да)) Ну я хотел сказать если значение будет больше чем влезает в int, то все, пиши пропало)?

ну так станет отрицательным значение))

короче непонятно, почему он int принимает, а байт нет, хотя int тоже может кончиться) надо было еще с short попробовать

Ну Валидатор просто тестирует своим файлом))) там видимо в тексте один и тот же символ повторяется много раз))

Ну такой текстовый файл, чтобы один и тот же символ встречался столько раз, сколько в int не влезет - это в реальной жизни большая редкость. А чтобы в байт не влезло - так это любой файл, где больше пары страниц текста.

Сейчас решил задачу Нити и байты, там в принципе тоже самое почти, прочто массив int [256] сделал. После решения посмотрел правильный ответ, а там массив byte [256])))))То есть в этой задаче вероятность того что символ встретится больше 127 раз меньше?))

выглядит так, что они подогнали правильное решение под файлы которыми проверяют))

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