Почему валидатор не принимает решение с try with resources?

Я иду дальше, просто решил спросить. Решение было ну прям абсолютно таким же через копипаст. просто удалил блок try/catch.

Поосторожней со словами "абсолютно такое же", в 90% длительные разборки на эту тему заканчиваются "ой, проморгал и правда не такое же". Но в данном случае это уже не важно, все-равно не разобраться, не зная в чем ошибка, высока вероятность ты не сможешь воссоздать проблему, фокусируясь на одних вещах, и упуская с виду другие. Мы бы заметили то, что ты упускаешь, но ты не сможешь нам это показать, поскольку не сможешь воссоздать то, что не знаешь. Замкнутый круг. Момент времени, когда можно в чем-то разобраться, это когда задача не принимается, и ты можешь скопипастить код, который не принимается здесь и сейчас. При разборках, что не принималось когда-то, часто напрасная трата времени, поскольку нету возможности точно воссоздать проблему, момент уже пройден. Прошло да и прошло. Перевернули и идем дальше

Хорошо, спасибо. Пусть так. А можно у вас еще немного времени отобрать? есть вопрос не по этой теме. Он куда более конструктивный

Конечно можно, только совет на будущее, старайся избегать конструкций "работал ли кто-то с...", "а кто-то слышал о..", "а можно задам вопрос", это плюс 1-2 лишние цепочки в коммуникации, то есть ты вынуждаешь человека сказать "да" , а потм еще ждат когда ты ответишь, такие вопросы очень часто просто игнорируются по причине банальной нехватки времени. Поэтому обычно принято так, "Можешь подсказать, есть такой вопрос:" и сразу его задаешь. Так и ты быстрее ответ получишь. И другим сэкономишь время. Опять же, чисто практический момент, потом ты сам к этому прийдешь, когда у других увидишь ) я просто проговариваю, чтобы ты учел это уже сейчас, поскольку проценто ответов на конкретные вопросы выше. Здесь проблема в асинхронной коммуникации, будь это мессенджер, тогда твой вопрос был бы валиден, но здесь, я вот зашел на сайт, прочитал твой коммент, может и мог бы ответить. А вопроса нет. А когда следующий раз зайду я не знаю, может завтра, может через месяц. Но то такое, задавай )

Окей, принял. Прохожу сейчас чтение/запись данных на сайтах через URLConnection и вот это вот все. URL - это ведь адрес конкретного ресурса (файла) на сервере, типа html документа, картинки, видео. Вот я обратился создал подключение к серверу по URL. С чтением все понятно - программа обращается к этому файлу по конкретному адресу и читает его - ок. Но запись куда идет? Мне кажется вряд ли она будет дозаписывать/перезаписывать этот самый файл? или она создает и пишет в какой то другой временный файл по соседству? или создается а-ля новый URL с какими то дополнительными необязательными (факультативными) параметрами и потом берешь ответ на него? или сейчас по URL находится не файл, а чаще всего некая программа сервера и ты обращаешься напрямую к программе и она тебе что-то отвечает? и вообще может ли это быть именно программа при переходе по URL. Или она вообще не пишет, а рисует белым мелом на асфальте слово хватит? Я понимаю что, например, при отправлении сообщения где нибудь в телеге программа обращается к серверу и записывает туда (чтобы это ни значило) само сообщение, адресата и т.п. и работает вероятно по тем же принципам. Но где находится физически эта запись которую потом обрабатывает серверная программа? и что с этой записью потом происходит после обработки и дачи ответа Прошу либо ответ, либо если лень объяснять - материал где это нормально написано, мне пока не удалось найти, но вероятно потому что не знаю как это искать. Вообще люблю почитать подобные статьи.

Практические вопросы лучше задавать с практическими примерами. В целом, имея адрес сервера ты с ним можешь вести диалог, диалог подразумевает какой-то ввод и от тебя. Например ты получаешь информацию через обычный GET запрос, отправляешь через POST. Не стоит ставить знак равенства между URL и html :) На той стороне урлы может находиться всё что угодно. Почитай как устроена сеть и тебе станет всё более понятно. Если сильно вкратце, то когда ты отправляешь запрос на какой-то адрес типа www.google.com один из ДНС серверов раздупляется, какой именно ip адрес прячется за этим буквенным сочетанием, и перенаправляет твой запрос туда. Ожидаемо, что компьютер в конечной точке уже решает что именно с ним делать, отправлять ли ответ и какой именно. Вот простенький пример того, как отправить данные посредством URLConnection

public static void main(String[] args) throws Exception {
    URL url = new URL("http://my_server_url/api");
    URLConnection urlConnection = url.openConnection();
    System.out.println(new String(urlConnection.getInputStream().readAllBytes(), StandardCharsets.UTF_8));

    urlConnection = url.openConnection();
    urlConnection.setDoOutput(true);
    OutputStream outputStream = urlConnection.getOutputStream();
    outputStream.write("request body".getBytes(StandardCharsets.UTF_8));
    outputStream.flush();
    outputStream.close();
    System.out.println(new String(urlConnection.getInputStream().readAllBytes(), StandardCharsets.UTF_8));
}

Само собой сервер должен знать как с этим работать, именно для этого существуют стандарты сетевой коммуникации, чтобы ты как разработчик и я, как разработчик могли вместе писать разные системы, способные общаться между собой.

Спасибо, пока что все равно решительно не понятно как они общаются и куда и как он что-то пишет. Я не отождествлял url и html, я написал что там например может находиться. Зачем в вашем коде дважды открывается коннект (строка 3 и 6)? после выполнения строки 9 с write данные сразу отправляются на сервер или только после выполнения flush? Про существование протоколов я знаю, что это набор правил или документ который описывает что например 3 первых байта означают кодировку, следующие 2 байта версию этого протокола и т.д. (конечно я образно говорю), чтобы декодировать набор байт в что то осмысленное. Про DNS в целом вроде тоже представление имею, что компьютеру нужен конкретный IP адрес, который берется с доменного имени через DNS сервера (а-ля справочник). Но все равно не понятно что, как и куда "пишется". Я писал раньше например программу на VBA для парсинга одного сайта чтобы брать от туда данные о физических свойствах некоторых веществ при разных условиях (температура/давление) и вбивать их ексель документ. Тогда я менял url запрос в коде подставляя нужные параметры через факультативные части URL типа "...?T=25&Plow=200&...". Но я ничего не "записывал" на сервер. Я только отправлял определенные url запросы. Общий механизм/принцип того что я делал тогда и пытаюсь делать сейчас - разный или нет?

Зачем в вашем коде дважды открывается коннект (строка 3 и 6)? Там есть определённые ограничения, типа нельзя отправить данные если они уже вычитаны. Потому я открываю два соединения. Вообще именно URLConnection не самый лучший класс для знакомства, он очень низкоуровневый, хотя и позволяет работать не только с HTTP. Именно для работы с HTTP методами было бы лучше юзать HttpURLConnection класс. Касательно флаша, я не тестировал, но привычка осталась :) Потому я его всегда юзаю. Вполне возможно, что это не обязательный шаг. что, как и куда "пишется". В данном случае ты формируешь конкретный запрос составленный по определённым правилам, он уходит на сервер, ничто и никуда не пишется - просто идёт передача данных. Сервер принимает решение как обрабатывать запрос который к нему пришёл. Это может быть http сервер, или сервер игры, или сервер чат системы, все они ожидаемо работают по своему. Твой пример с экселем очевидно работал через GET запрос, там ты ничего не отсылаешь кроме параметров в самой урле. Кроме GET существует еще ряд запросов, которые отсылают данные, в том числе файлы например

То есть вы хотите сказать, что, то что находится на сервере инкапсулировано и под конкретным URL может находится вообще все что угодно и вдаваться в это не нужно, нужно только понимать как составлять различные запросы типа GET, POST, PUT и т.д.? Правильно понял? Если так, то в принципе становится понятно что происходит. Тогда другой вопрос - где про эти запросы можно почитать подробнее не подскажете? И эти запросы и их конструкции всегда разные для разных протоколов ftp, https, udp, tcp и т.д.?

Денис в принципе норм ответил, про твой пример про телегу. Но вопросы хорошие URL описывает какой-то ресурс, что там с ним сервер сделает, запишет файл, прочитает, или ничего - зависит от того, что ты пропишешь в своей джава программе. Представь что сервер имеет УРЛ, это некая точка входа, например твой метод в программе:

handleRequest(InputStream inputStream) {
 ...
}

а дальше, что ты с этим входящим сделаешь в этом методе, что сделаешь то и будет. Разные протоколы ftp, udp, tcp я пока советую вообще не трогать, для того чтобы разобраться тебе нужно отмести все лишнее и сфокусироваться на чем-то одном, если ты начнешь все в одну кучу валить, ты себе просто шансов не оставишь чтобы разобраться. Также на низкоуровневых штуках тоже не заморачивайся пока. Для джавы основной протокол это HTTP , там простая система, отправляется HTTP запрос, получается ХТТП ответ. Разбери структуру HTTP request/response, как выглядит, что туда входит. Сервер получает запрос, что-то делает, и отправляет ответ. Есть HTTP методы, которые позволяют маркировать различные типовые операции, хотя вполне можно настроить так, чтобы удалять GET запросом, а добавлять DELETE. что тебе почитать: гугли

клиент серверная архитектура
REST vs SOAP
веб сервер
HTTP методы
HTTP статус коды
структура HTTP запроса
JSON

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

Спасибо большое всем ребят. Все встало на свои места. Вопросов больше нет :)

Я подумал что не готов отвечать на вопросы которые обязательно последуют, но добавил бы еще про почитать: TCP + UDP Хотя это и является достаточно низкоуровневым знанием, это очень сильно упрощает восприятие дальнейшего материала, который построен уже над этим слоем.

и под конкретным URL может находится вообще все что угодно Аккуратно в дырочку. Именно так. и вдаваться в это не нужно, нужно только понимать как составлять различные запросы типа GET, POST, PUT и т.д. Не вполне. Когда тебе нужно общаться с конкретной системой, тебе нужно понимать что она от тебя ждёт и что ты получишь в ответ, называется это волшебным словом API (Application Programming Interface). Если ты общаешься с HTTP сервером, то тебе нужно формировать HTTP запросы, если ты общаешься с кастомным сервером игры Линейдж 2, тебе нужно общаться так, как этот сервер от тебя ожидает. Короче в каждом конкретном случае по разному. Зачастую для этого существует документация которая детально описывает как именно общаться с системой. Соответственно, если ты пишешь свою систему и ожидаешь что с тобой кто-то будет общаться, ты пишешь своё API и документацию под него. где про эти запросы можно почитать подробнее не подскажете? Если речь про конкретное АПИ - то в документации к этому АПИ и читать. Про HTTP написано очень много, можно погуглить HTTP методы, библиотеки, тысячи уже готовых решений и документаций ждут тебя. И эти запросы и их конструкции всегда разные для разных протоколов ftp, https, udp, tcp и т.д.? В основном. Ты же понимаешь что спецификации пишут люди. В основном им удаётся договорится в рамках конкретного протокола, но не всегда удаётся в рамках этого протокола удержаться. Правильный ответ только один: читай документацию по продукту, там всегда верная ифнормация.

Понял, благодарю.