Материал также доступен в качестве видео:
Привет, мой юный или не очень друг.
Сегодня я расскажу, почему не стоит тебе учить Java.
Конечно, вряд ли ты меня послушаешь, раз уж ты почему-то здесь, но все-таки.
Для начала, давай договоримся, что ты не из этих колхозников, которые путают Java с JavaScript, который еще более отвратительное поганое отродье сатаны (но как раз его-то рано или поздно тебе учить придется, потому что мы посланы на эту землю страдать).
Сегодня ограничимся чистой Джавой.
Первая причина, по которой язык Java надо предать огню, это выдуманная каким-то старым пер$%^м мифическая проблема ромба, она же проблема бриллианта, множественного наследования.
Допустим, ты вырос в нормальной семье, и у тебя двое родителей.
Ты унаследовал от них лучшие черты, и наслаждаешься своим генетическим совершенством.
Но если бы ты жил в мире Джавы, тебе бы это не светило.
Что если у обоих твоих родителей есть голова?
Если это так, это же неразрешимый парадокс, вселенная перестанет существовать!
Мало этого, если у родителей будут совершенно разные органы, у одного только голова, а у другого только тело, и ни будет ни одного пересечения, с точки зрения Java двое родителей это криминал по определению!
Тебе придется выбрать лишь только одного родителя (помнишь эти вопросы в детстве, кого ты больше любишь – маму или папу?), и размножиться от него почкованием.
Что до другого, он тоже может быть, но только в виде бестелесной оболочки (интерфейса).
В общем, отец, сын и святой дух.
Самое смешное, что когда авторы Java поняли, какую странную систему они сотворили, то передумали, но было уже поздно, легаси уже тянуло их на дно.
Теперь чертов второй и остальные родители могут иметь воплощение (дефолтные методы), но только наполовину, и это воплощение фактически висит в воздухе, что всех жутко бесит.
Вторая вещь, за которые авторы Java получают лучи ненависти, это чертова проверка эквивалентности.
Допустим, ты умный мальчик, и уже знаешь, что «равно» у нас бывает одинарным, а бывает и двойным, а у особо одаренных лэнгвидж дизайнеров бывает и тройным, за что они точно попадут в ад.
И вот ты, довольный собой, хочешь сравнить два числа типа Integer, или две чертовых строки (не подозревая пока что в Джаве они иммутабельны и иногда создаются новые, а иногда находятся в пуле имеющихся), или что-то еще такое, что на вид не сложнее кубиков в песочнице.
Не тут-то было! Нельзя просто так взять и сравнить что-то в Джаве, с помощью гребаного знака равно, даже если ты подкован и помнишь, что оно должно быть двойное.
Хотя нет, можно, но не Integer а int.
А на Integer кстати двойное равно как будто будет работать (The JVM is caching Integer values. == only works for numbers between -128 and 127), но через раз неправильно, поэтому для элементарного сравнения ты должен использовать адски длинное слово equals.
С ним твой код приобретает потрясающий нечитабельный вид помойной ямы, но выхода нет - перегрузить оператор двойное равно мы не можем, это тебе не С++.
Двойное равно здорово бросалось бы в глаза при поиске по коду той самой проверки, которая тебе так нужна для отладки, но нет.
Оно будет бросаться в глаза только в сотнях, тысячах не несущих смысловой нагрузки строк проверок на null, которые, поверь, ты будешь ставить где надо и где не надо, нахлебавшись NPEшек в первые два дня своего промышленного программирования на Java.
Вот там-то как раз equals тебе не светит (как только ты захотел хотя бы единообразия, раз уж нет наглядности), ведь не можешь же ты просто так взять и проверить равенство с другой переменной и равенство с пустым значением с помощью одного и того же оператора!
Equals на пустом значении закономерно вызовет NPE (NullPointerException), потому что нельзя разыменовать null.
Также нельзя использовать equals на int и паре других доисторических типов , но об этом ты хотя бы узнаешь на этапе компиляции, а не после выкатки в ПРОМ как в случае двойного равно.
Короче, крутись как хочешь, метайся между простыми типами и объектами, между равно и equals, но чтоб все работало, и без багов.
И последнее про это.
Как переопределять equals и hashCode советую выучить как Отче наш, уж это-то точно спросят на собеседовании, поскольку объем знаний ПМ обычно этим и ограничен, ибо какой-нибудь SOLID он забыл в тот день, как стал ПМ - как страшный сон. Ну а техлид разгильдяй и профакапит митинг, и поэтому будет назначено второе собеседование - ведь погонять кандидата по Москве несколько раз - вообще милое дело.
Идем дальше.
Допустим, ты добавил переменную в класс.
Нельзя же просто так взять и прочитать ее, не говоря уж о записать!
Ее немедленно нужно спрятать ото всех модификатором private, приговаривая при этом «моя прелесть».
В общем, приватная у нас будет переменная, и кому попало она не отдастся.
Для каждой, буквально каждой чертовой переменной, потребуются геттер и сеттер, как сутенеры в шубах и с золотыми цепями для девушек низкой социальной ответственности.
В 99% случаев они нафиг не нужны, потому что будет просто чтение и присвоение, безо всякой дополнительной логики, но эти геттеры и сеттеры как саранча сожрут все свободное место в твоем коде, будут выжигать твои глаза, и сниться тебе по ночам.
Хотя, если ты из Индии и тебе до сих пор платят за килобайты, извини братюня, мне бы не хотелось отнимать у тебя хлеб.
Тогда, нужно даже больше геттеров и сеттеров! Почему бы не добавить в индустриальный стандарт разработчика какой-нибудь сеттер геттера или геттер сеттера, и увеличить код хотя бы в два раза? Хорошего кода ведь много не бывает!
Забегая вперед, работая с каким-нибудь ОРМ ты даже не сможешь аннотировать чертовы переменные, тебе придется аннотировать эти поганые геттеры и сеттеры.
Если тебе пришло в голову, что ты хозяин своей программы, и можешь изменять имена переменных, учти, что ты просто раб своего кода, и поэтому после опечатки бегом пошел и поменял это имя в коде как минимум в четырех местах, иначе все будет падать.
Конечно, IDE постарается тебе помочь, но только дай ей волю, только согласись в запарке на какой-нибудь невовремя всплывший диалог, и ИДЕ как услужливый дурак накосорезит по всему проекту так, что ты раз и навсегда дашь зарок не принимать от нее помощь.
Следующее.
Представь, что тебе надо сделать простейшее CRUD приложение, на десктопной Джаве (для тех, кто не в курсе Create Read Update Delete - про базы данных) .
Как думаешь, сколько у тебя уйдет, чтобы сделать это на какой-нибудь Jtable?
Дело в том, что Java Swing настолько отвратителен, что ты потратишь адское количество времени, на написание DDL, объектной модели, ORM, обвязки, реакций на каждый шорох в UI, на каждый одинарный клик мышки. В какой-нибудь доисторической Delphi у тебя ушло бы 10 минут на все твое приложение, но нет, это же промышленная платформа, это Джава.
Мало этого.
В NetBeans твои cвингерские формы хранятся в отельных файлах в своем формате, в Eclipse - в несовместимом с NetBeans коде, который компилируется в форму на лету, а в Идее вообще нет встроенного механизма, и надо использовать плагин от какого-то криворукого коллеги по опасному бизнесу, который был в спячке и не слыхал про первые два формата, поэтому придумал свой.
Это что за долбаный зоопарк? Я не хочу запускать ракету на Марс, я просто хочу делать формы, чтоб на них были кнопочки и поля, так почему нельзя было договориться о едином удобном подходе? Комьюнити, я что, слишком многого прошу?
Возможно, ты мыслишь стратегически, и мог бы сделать и универсальную обвязку, как я, которая бы просканировала entity в проекте, и построила бы весь вспомогательный функционал налету, включая пользовательский интерфейс со всплывающими каскадами окон, после чего CRUDы штамповались бы у тебя как пирожки.
Но бьюсь об заклад, именно в твоей компании найдутся дураки на букву М, которые скажут, что рефлексия (reflection) в Джава это медленно и ужасно небезопасно, это ай-ай-ай, и поэтому она в проекте запрещена к такой-то матери. Только тайп сейф, только хардкор. Ну и на null не забывай проверять, как минимум в половине строк проекта должны быть проверки на null. Про Options эти динозавры пока не слыхали, а лямбды к ним завезут лет через 10. Да и вообще какой смысл переходить с Java 1.5, если она изысканно хороша в свой первозданной красоте и в ней ничего не сломалось?
Ну ок.
Допустим, ты решительно отринул плебейский Swing, и вообще отказываешься от всех задач по легаси, сразу обрубив для себя 2/3 из доступных на рынке труда вакансий.
Ты хочешь заниматься только модными новыми проектами, и исключительно веб.
Конечно же, там будет не что-то, а замечательный фрымворк Spring. Ты думал, это в Свинге ногу сломишь? Да только чтоб разобраться в азах Спринга, нужно потратить пару недель.
Но отлично, что там хотя бы добавили аннотации, потому что от вида xml файлов меня уже просто тошнило.
Спринг к тому же еще и тяжело отлаживать, а еще он адски долго собирается и запускается.
Аспектное программирование? Ну поиграйся, поиграйся, а потом выпилишь к свиньям, или уволишься, и оставишь удовольствие выпиливать последователям.
Еще по поводу отладки.
Как-то мне нужно было написать плагин к Jira, так сборка и запуск реально занимали полчаса - и это на пустой базе данных.
Не мне одному осточертело ждать, и там сделали даже специальный костыль, который подменял лишь один класс для отладки, но зато делал это быстро.
Когда я говорю быстро в этом контексте, это значит несколько минут. Просто молниеносно!
Проблема была лишь в том, что в процессе отладки в половине случаев этого было недостаточно, и все равно требовалось пересборка на полчаса!
Да что ж ты будешь делать!
Только ради этого я купил PCI-E SSD, их и на рынке-то практически не было тогда, потому что трудно было представить себе идиота, приложение которого настолько требовательно.
В общем, когда ты прослушаешь этот ролик, подумай хорошенько, стоит ли тебе изучать именно Java.
Пока тебя не затянуло в это блади энтерпрайз легаси болото.
Я желаю тебе только добра.
Поверь мне, выход есть, он рядом, нужно просто протянуть руку и сорвать сладкий плод - он ждет тебя.
А чтобы я записал продолжение, подписывайтесь – только так я смогу понять, какая именно тема интересна.
И когда у меня освободится время, и обязательно займусь этим для вас.
