Как я возненавидел Java

Весьма претенциозный заголовок, не находите? Впрочем, после недавнего проекта для меня он стал близок к истине. Я, если не возненавидел, то точно сильно разочаровался в Java и её экосистеме.

С Java я и мои ленивые распиз бравые коллеги познакомились по долгу учёбы. Небольшой проект, размером в семестр, казалось бы, что может пойти не так? Оказалось что многое, и даже очень.

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

Поэтому здесь не будет громких заявлений в духе "Java — говно, Python — лучше всех!". Я всё ещё считаю Python — лучшим второстепенным языком, который прекрасно решает многие задачи, но не любые, иногда его лучше заменить на что-то более производительное. Java же, наверняка хороша чем-то по-своему, но просто не для меня.

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

А что за проект-то собственно?

И правда, что я заладил "проект" да "проект"? Прошу любить, жаловать и не жаловаться — "Student Archive". Мде, полное название оригинальностью не блещет... "STAR" — во, так-то лучше. Это наша первая попытка в EdTech.

Мы попытались автоматизировать то, что у нас не получилось сделать вручную — собрать архив лабораторных работ, методических материалов и прочих полезностей студента. Не, ну а что? Оно всё равно годами не устаревает.

На этот семестр стояла задача написать бэкенд. Для этого был выбран классический REST API, без всякого хипстерского выпендрёжа вроде GraphQL или gRPC.

Через семестр к этому мракобесию ещё предстоит вернуться, чтобы написать к нему графический интерфейс.

Почему Java? Честно, я бы с радостью туда вообще не лез, но предмет "Платформонезависимое программирование " к этому обязывал.

Отвратительная документация

Для начала — маленькое лирическое отступление: что я считаю хорошей технической документацией?

• Хорошо структурирована
• Снабжена примерами кода (но не состоит из них полностью)
• Отдельные страницы индексируются поисковиками
• Желательно содержит мануал по старту работы с технологией
• Не сгенерирована из комментариев к коду

Если брать мир Python, то там отличная документация написана к Django. Несмотря на объемность фреймворка, всё очень хорошо расписано, отлично гуглится, и даже есть несколько пошаговых инструкций по созданию небольших проектов.

Что же мы видим, например у Hibernate-ORM?

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

1. Через XML-файл, в котором вручную описываются все таблицы, типы данных и связи между таблицами, затем поверх этого пишутся POJO (или "простые старые Java-объекты"). По мне, так этот способ дикость. Как минимум потому, что приходится одну и ту же работу выполнять дважды. По неясной причине документация фокусируется именно на этом способе, фактически игнорируя второй, более "новый" способ (мне кажется забавным употреблять слово "новый", говоря о Java-мире. Сложилось впечатление, что инновации там происходят раз в 15 лет, но существующий софт совершенно игнорирует их чтобы избежать рефактора)
2. "Новый" же способ заключается в описании моделей через обычные классы, на поля которых навешиваются аннотации, обозначающие обязательность, связи и пр. И никакого XML! Увы, но по этой штуке документации практически нет.

И тут возникает один вопрос — какого чёрта одна библиотека реализует настолько разные способы описания моделей? В смысле, почему бы не разбить её на две части?

Во-вторых документация отвратительно структурирована, а страницы совершенно не гуглятся.

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

Нерабочие туториалы

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

Напоминает времена, когда я несколько лет назад пытался изучить Vue.js. Там скрипт инициализации проекта начал кидаться ошибками несовместимости версий в ответ на попытки подключить линтер. В общем Spring Boot тоже пошёл лесом.

Платный софт и пакеты

Возвращаясь к Hibernate. Одно время я подумывал о том, чтобы писать модели, используя XML.

Естественно, поскольку я человек крайне ленивый стремящийся оптимизировать противные задачи, я стал искать хоть какие-то инструменты, которые избавят меня от необходимости писать XML вручную. Что поделать, меня на физическом уровне отворачивает от этого формата. И почему в Java мире его так любят? Весит относительно много, читается тяжело, парсить — больно.

Подошло бы что угодно: GUI, DSL...

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

Может есть какие-то альтернативы Hibernate? Нахожу парочку каких-то решений с закрытым исходным кодом и опять же платных. Серьёзно? Кажется я слишком привык к Python-миру, который держится на куче энтузиастов, которые выкладывают свои, бесспорно, огромные труды, в открытый доступ. Мде, Даня, добро пожаловать в суровый мир Enterprise-разработки.

Надо что-то делать

Пока я экспериментировал, пытаясь сделать "хорошо" неумолимо приближался дедлайн. Поэтому пришлось засунуть перфекционизм подальше и писать как придётся. В конечном счёте в основу лёг Spark, какой-то малоизвестный и минималистичный веб-фреймворк, достаточно неплохая документация которого поместилась на одну страницу. Ну а доступ к базе данных организовали с помощью JDBC, прямо в коде бросив сырые SQL-запросы. Умеем, практикуем!

За нехваткой времени в итоге многие эндпоинты были брошены возвращать 501 Not Implemented. Только т-с-с-с!

Впрочем какая разница, если в итоге проект был сдан на "отлично"?

Вместо вывода

За время разработки я понял одно: Java — это огромная кроличья нора с кучей легаси, в которую невозможно нырнуть с места. Понадобятся годы кропотливого ковыряния в паршивой документации, чтобы получить цельную картину хорошего приложения.

Гудбай Java, нам с тобой не по пути. А я погнал учить C# для следущего гигантского проекта.