Что вас раздражает в фреймворках?

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

Магия на аннотациях, но XML-дрисня как по мне ещё хуже.

Ломбок должен сдохнуть.

+1, нормально оно никогда не заработает.

Почти всё вышеперечисленное, а особенно пункт 3, да.

Прям с языка снял. Два чая этому регистранту.

Ограничения. А чтобы их обойти нужно писать другой фреймворк. Больше всего хлебнул с Cypress (JS), там столько костылей и неочевидных вещей, что они нахрен перечеркивают все плюсы. В итоге работа сводится к тому, что я экономлю время на детсадовских задачах, а потом страдаю на всех остальных.

Поддерживаю. Сплошная магия.

Раздражает, что похерили JBuilder и его огромную библиотеку визуальных компонентов JBCL. В Netbeans кроме Swing и, этсамой, забыл название, ничего нет для работы с СУБД и представления данных.

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

просто ты старпер.

но да, магия бесит.

плюс раздражает что вместо программиста «на языке» теперь у нас есть тьма программистов «на библиотеке».

Фреймворка это такая хрень которая автоматизирует то что не надо автоматизировать, потому что написать вручную то что автоматизируют фреймворки займёт ничтожно малое количество времени.

«Мне нужна библиотека, а не фреймворк»

JavaFX

О, точно!

ИМХО главаня проблема в sping это не xml, не декларативное кофигурирование, главная проблема это фабрики фабрик, из-за них нельзя посмотрев стек понять почему объект сконфигурирован так а не иначе, приходится перезапускать spring приложение несколько раз ставя брейкпоенты в конструкторы фабрик. Эту штуку мне кажется уже пора объявлять антипатерном.

Согласен про spring boot, это автоконфигурирование ничего хорошего не дает и то что WebMVC перезапускается по минуте никак не помогает быстро разобраться с проблемой.

Я для своих проектов spring больше не использую.

+1, нормально оно никогда не заработает.

На работе с ним столкнулся, суровый энтерпрайз его использует, проблем не доставлял, работал как часы, в контексте java8 мне lombok понравился.
Для себя я такое не использую, я уже давно для себя выбрал kotlin, там просто нет надобности в такой библиотеке.

Пфф, ща вообще зерокодинг в тренде, а ты тут про библиотеки.

Поддерживаю!

Их наличие, жду не дождусь армагеддона после которого останется гипертекст как он задумывался изначально с текстом и смешными картинками, а «java» будет непонятной надписью на заборе.

а «java» будет …

сигаретами и мопедом!

Точно, блиин...

Ломбок должен сдохнуть.

Поддерживаю.

Всё остальное в ОП в принципе терпимо. Единственное, что меня прямо вот сильно бесит, так это повсеместное использование yaml для любых конфигов. JSON тоже не люблю, но вот yaml это вообще из разряда наркомании.

Ломбок должен сдохнуть.

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

Какие-то свои плагины для сборки. Например id ‘org.springframework.boot’ version ‘1.4.3.RELEASE’.

Не для сборки, а лишь для перепаковывания всех зависимостей в один Jar. Опять же, java почему-то игнорирует параметры -cp, -classpath если используется с параметром -jar.

Магия. Вообще сложно найти фреймворк для Java без магии. Это одна из причин, по которым я долго пользовался спрингом без бута. Там есть возможность писать код почти без магии. Мне нужно, чтобы я написать main, чтобы я там всё сам сконфигурировал и запустил. Никаких автоматических сканирований всех моих классов в проекте. Ничего такого. Всё должно идти из main-а. Весь граф вызовов и прочего должен находиться через Find Usages. Каждый класс должен создаваться через конструктор, или через фабрику, но не через магию.

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

Что касается кодогенерации, то эта вещь довольно полезная, но почему-то редко используемая напрямую, хотя поддерживается ещё с 5-й Java. Жаль, что кодогенерация ограничена лишь новым кодом и модифицировать (то есть препроцессить) существующий нельзя. Тогда бы и Lombok был бы человеческим.

Помимо вышеперечисленных пунктов, больше всего бесит монструозность фреймворков. Еще пяток лет назад был проект на монолите (spring) и все вполне неплохо работало даже на моем тщедушном ноуте. На проде конечно там был сервер с жирным ОЗУ. Потом этот же проект разбили на «микросервисы» и на моем ноуте он уже запуститься не может. А на проде целый кластер. Нагрузку держит дай боже, но после ковида там и так нагрузки нет.

Ну и еще порой быдлокод глаза мозолит. Как-то полез во внутренности хибернейта и был неприятно удивлен качеством кода. Помню точно, что был кусок где в блоке try кидается исключение, в самом же catch оно ловится и преобразовывается и выкидывается обратно. Бред.

Раздражает что они сложные и я не могу их понять, а еще мне никто не предлагает их понимать и я по прежнему работаю на телефоне.

То, что люди их создающие не используют их по назначению. И это не только касается фреймворков, но и самого ЯП в частности. Поэтому имеем, то что имеем.

Магия.

Магия появилась не от хорошей жизни. Сейчас приложение должно реализовывать кучу всего oauth2, cors, микросервисы (которые пишут разные команды), работа с дб, кластеры и, если не использовать общую магию, то повесишься. Вообще эта магия воображаемая - достаточно в неё погрузиться и заюзать, и приходит понимание, что тот же spring boot писали весь и весь грамотные пацаны и к этому буту есть куча навеса, который сходу начинает работать. Продавцы захотели, чтоб в проекте на буте появились «кластеры», два дня и есть кластерная конфигурация с hazelcast.

если не использовать общую магию, то повесишься

Не согласен. Всё вышеперечисленное прекрасно работает без всякой магии.

Вообще эта магия воображаемая - достаточно в неё погрузиться и заюзать, и приходит понимание, что тот же spring boot писали весь и весь грамотные пацаны

Погружался. Отвращение усилилось.

Продавцы захотели, чтоб в проекте на буте появились «кластеры», два дня и есть кластерная конфигурация с hazelcast.

Это маркетинговый миф. Оно так не работает. Чтобы приложение работало в кластере, его нужно изначально проектировать и разрабатывать исходя из этого требования.

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

Чтобы приложение работало в кластере, его нужно изначально проектировать и разрабатывать исходя из этого требования.

Конечно и это достаточно легко при использовании того же boot.

Всё вышеперечисленное прекрасно работает без всякой магии.

весь вопрос во времени - сколько займет реализация. Да и что такое магия?

@Autowired
IService service;

@Autowired
List<IOService> services;

А «кластерную конфигурацию» я не за два дня, я за две минуты в jelastic-е мышкой натыкаю.

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