Re[4]: Java в shareware
От: Иль  
Дата: 02.03.23 15:08
Оценка:
vsb>А какие альтернативы? Спринг бут это 90% жава "рынка". Библиотек, конечно, миллион, но по буту хотя бы есть ответы на все возможные вопросы.

Есть ответы на базовые и/или стандартные вопросы. Есть ответы на некоторые нестандартные вопросы. Но тут уже надо чтобы совпала версия спринга, по которой отвечали и той, которую используешь. А ответов на большинство нестандартных вопросов нет.

vsb>Не, если есть много времени и желания заниматься интересным, я бы даже на com.sun.net.httpserver-е сделал веб-сервер, работающий с базой через JDBC, с кучкой своих велосипедов и итоговым размером жарки в пару сотен килобайтов. Которую потом вполне реально можно в полноценный бинарник преобразовать размеров мегабайтов в 15. Но... Так не делают.


ИМХО спринг часто ошибочно воспринимают как такое самостоятельное универсальное решение. В реальности же помимо самых базовых вещей — (spring core кажется оно называется) — типа позднего связывания через Reflection (что, кстати, не так уж и сложно сделать и без спринга при желании) и т. п. — спринг просто объединяет кучу сторонних библиотек. Но что мешает использовать те же самые библиотеки без спринга? Т. е. не подтягивая кучу ненужных зависимостей через Spring Boot?

Например Srping data прикольная вещь для больших проектов. Но иногда она не нужна. А надо, допустим, исполнить запрос к БД хотя бы через тот же spring jdbc. Так вот spring boot отдельно spring jdbc не подтягивает, а только в комплекте с чем-то монструозным.

vsb>Ну речь же о том, чтобы сделать веб-сервер, работающий с базой, а не чтобы запустить jar. Исполняемую жарку можно сделать тремя консольными командами примерно, без всяких грэдлов, но цель же не в этом. Это всё технические мелочи. Какая вообще разница, как её запускать. Честно признаться никогда не понимал этой моды. Всё равно скрипт пишут в том или ином виде. Одним параметром больше.


Можно, конечно. Но зависимости (а без них что-то писать это уж совсем хардкор) придётся класть рядом. Не всегда это удобно. ИМХО проще переупаковать все зависимости в один jar и его уже класть куда надо, контролировать его версию и запускать простейшей командой.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.