Що вас найбільше бісить у Java?
Java-екосистема — одна з тих тем, де в розробників завжди знайдеться що сказати. Комусь не подобається сама мова, комусь — фреймворки та все, що навколо них, а хтось узагалі не бачить жодних проблем.
Якщо ви зараз працюєте з Java: що вас найбільше дратує в самій мові чи її інфраструктурі? Що хотілося б змінити або спростити?
35 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівА хз... Нашо само джава, коли є котлін ?
.
Коли причепом йде JavaScript. Ну типу ж теж Джава, тиж сенйор?
Та подумаєш, дописали якесь там Script. Java ж 😁
прям от зараз развєсістий срач про те, як це правильно
dou.ua/forums/topic/61973
Хочеться викруткою поколупатися в дупі, а вона не дає.
Жере гигабайти пам’яті.
По мінімуму можна значно менше, але навіть Hello world захвате 60 MB. З досвіду Tomcat/Spring boot чи JEE зазвичай крутиться в районі 6GB. Та там де недоліки там же і переваги GC із дефрагметизацією пам’яті і т.д. А от сама мрдель пам’яті внутрішні структури і т.д. відають суттєво, особливо java.lang.String.
Дуже не вистачає підтримки синтаксису JSON
Record types виглядають як хак який не завжди підходить
У платформи два ключевих недоліка — це JNI який почали виправляти тільки а 22 версії, чепез більше ніж 20 років коли вже в кодовій базі дуже багато чого зроблено. Другий це — шалена перевитрата пам’яті, з цим почали боротись к9-й версії.
Далі там де недоліки, там же і переваги, це особливість. Скажімо GC або байткод, мають як свої плюси так і мінуси. Ситема ексепшенів та сиектрейсм досі еталон для усіх платформ, це одна з кращіх дігностичних систем особливо порібних для серверів.
Просадка комерціного використання Java пов’язана не з платформою, а комерціною політикою Oracle corporation. Власне, та же біда з IMHO кращою з СУБД яку майже витіснив PostreeSQL з ніши RDBMS і багато ще чим.
Критичне падіння попиту на платформу в Україні в 6 разів, пов’язане з безпекою, великі еnterpise — головні користувачі, просто вивели проекти з небезпечної локації.
Розділення на checked і unchecked exceptions вважається найбільшим гріхом Java, і слава богам не потрапила в інші мови
Вважається адептами функціонального програмування, яким exceptions не подобаються як такі. А В С++ можна було робити throw 1 взагалі.7-ї версії ввели autoclosable та multiple catch, що вирішив початкові проблеми, окрім пустого catch блоку.
З
Проблему autoclosable та multiple catch не вирішив. Жодна мова не пішла цим шляхом, хоча сама Барбара Лісков придумала концепцію, звідки вона і з’явилась.
Найближчий родич С# свідомо відмовився. В Java бібліотеках здається теж відійшли від checked exceptions на користь unchecked
Адепти функціонального програмування в цілому кажуть доволі справедливу штуку, exceptions це костиль не визначеності undefined behavior за своєю природою, яке вирішили обійти стрибками по stack trace. В Java ввели певний механізм checked exceptions щоби робити розділення коли певні ситуація вимагають коду обробки помилки. Ідея певним чином вірна та через обмеження часу ще команді Гослінга зроблено було кривою із реалізацією зокрема в стандартній бібліотеці.
На ділі з’явився IOException який треба обробляти усім, а по суті програміст із відмовою обладнання зробити може — нічого. Систему все одно треба відключати фізично якщо вона усе ще працює і обслуговувати роблячи ремонт. Зате залишився Null Pointer Exception — та сама помилка на мільярд (суттєво більше думаю вже рахунок на трійльони) — бо тут треба додавати якраз логічний код який обробляє помилкову ситуацію, наприклад, коли данні не прочитані з бази даних бо їх там банально нема, чи користувач ввів щось не коректно. Це не помилка виключно Java. Новітні мови : Kotlin, Goovy, Scala власне і оновленні версії Jiava бояться в першу чергу із NPE, як із найдорожчою статистично по трудомісткості причиною дефектів в ПЗ взагалі.
В Go Lang наприклад, хоч він і імперативний — через undefined behavior що в базисі, свідомо пішли від механізму exceptions взагалі.
Ексепшени в Джаві стали проблемою коли вкрутили стріми, які ті ексепшени ковтали, і стало непросто розібратися що трапилось.
А в цілому, ідея ексепшенів н.м.п. доволі валідна — ти повинен задекларувати граблі, які можуть статися, а не ловити наслідки зненацька. Хоча, так, я читав ті високолобі опінії що ексепшени не потрібні. Можу погодитись, що десь воно так і є, в інших мовах, але в Джаві воно працює і жити з цим можна.
А от похапешники дуже раді натирити гарних ідей у джави та заімплементити у новій версії. Так що поки ваша джава жива, то і у мене буде робота на PHP :-)
Усі в усіх підивляються, це взагалі нормальна інженерна стратегія. Інша справа, що JEE в свій час скопіювали з PHP таку штуку як JSP, якою сьогодні майже ніхто не користуєттся, та ще році в 2018 було всюди. Зато в Node та React — Server Side Rendereng — став собі нормою.
Хіба JSP не були скопійовані з ASP. Net?
Скорее наоборот
Проблем зазвичай не бачать ті, хто не користувався іншими мовами, як на JVM так і поза нею.
Java розвивається дуууже повільно, виправдовуючись зворотньою сумісністю. Тож, мій список:
1. Зворотня сумісність, котрої насправді не існує. Чомусь Java аплет Укрсиббанку я міг запустити тільки на Java 6. А зараз взагалі не зможу, бо аплети прибрали. Коли мігрував проект на Java 8, тести перестали проходити. Glassfish на нових версіях Java не запрацював з коробки з ClassNotFoundException. Прибирають класи котрими майже ніхто не користується, але якщо це ви — не пощастило. Мені напишуть десяток коментів «я запустив свій старий проект і він працює». І скоріш за все так — проблем менше ніж в Python 2/3.27-му. Коли я побачив ідею з тайп класами в Java, я вже навіть не здивувався. Сподіваюсь за 10 років побачимо.
2. Jar hell розрулювати неприємно. Maven 4 нам допоможе, коли допишуть(в розробці 6+ років). Як менеджити jarи, в яких не записано на рівні стандарту їх назва і версія — загадка. Дякую хоч META-INF є, але не всюди, бо зворотня сумістність жеж. Передаю привіт усім, хто досі збирає fat jars.
3. При цьому тащимо роками Serilization, JUL, знаємо трагедію slf4j, і чому вбудованими тулами користуватись не можна. Але зворотня сумісність.
4. Так, це все потроху змінюють. Serilization, Valhalla виправляють вже 10+ років. Я зрадів коли Java перейшла на швидший реліз цикл, але серйозні зміни робити важко, тож поки обходимося додаванням нових фіч.
5. Неприродній синтаксис нових фіч мови. Я радий що у 8 зявився functional спосіб працювати з колекціями. Але імплеметація виглядає монструозно в порівнянні з іншими. Supplier/Consumer? Серйозно? Коли я знав тільки Java, це здавалось нормально. Після Python і Scala Gatheres сприймається як фейспалм. Мова і до цього була багатослівна, а тепер вибираєш між var і diamond. Правда, можна звикнути, деякі навіть почали отримувати задоволення.
6. Наді мною сміялись коли я розповідав про FP, а потім додають в мову pattern matching. Після 6 років він і досі не працює повністю, обіцяють фіналізувати у
7. Найбільша частина ком’юніті — це Spring+Hibernate. От написали на VirtualThreads Helidon — скільки статей на DOU про нього? Є ще Quarkus/Micronaut, займають незначну частину ринку. Jakarta створює якісь специфікації, щоб вони були максимально схожі на Spring, і всюди в них рефлексія, рефлексія, рефлексія... Код виглядає як список анотацій, і всім це ок.
При цьому, Java має одну з кращих VM, з чудовою швидкодією — плоди років роботи над перформансом. Мова ж опинилась на шпагаті між стильними-молодіжними трендами і зворотньою сумісністю для ентерпрайза, котрий колись замовив сервіс у підрядника і не хоче віддавати гроші на його апдейт. Тож цей статус збережеться ще на довго.
Хороша новина — отакої Java буде ще на декілька десятиліть вперед, або нам, або агентам.
Майже всі оновлення руйнують backward compatibility. Якщо треба підтримувати проект тільки на безпечних залежностях у яких немає критичних вразливостей то оновлювати залежності доводиться доволі часто (дякую ШІ, тепер нові вразливості ледь не кожен день). Але оновлення для бібліотеки робить її немумісною з іншою бібліотекою яка також має під капотом цю бібліотеку. І тепер або А не працює або Б. І бібліотека Б ще не випустила оновлення з потрібним фіксом. І от сидиш на все це і не розумієш навіщо фікс в мінорній версії ламає зворотню сумісність
Це вже не кажучи про EOL для різних версій бібліотек, які декларують підтримку версії лише на2-3 тижні а потім кидають і створюють нову версію бібліотеки і теж дають їй 2-3 тижні.
Якщо вже фіксите, то хоча б в мінорних версіях контракти не ламайте :(
Що нема вже автофіксу компайлтайму! Як колись до 2002
Слава Павлику!
Була бібліотека, ну яку треба було дописувати всім по best practice по кожному кейсу,- cure-Java і ніколи практично не було тієї х
Потім опенсорс справжній прикрили ті міліардери і вшистко, не було вже репозиторію
То були файні часи,- а потім одна грошова монополія,- прямо як в нас зараз
Дошка пошани була на git
Не Java розробник, але недавно довелося попрацювати з Java, тому вставлю свої 5 копійок) я прям прифігів, що у Java нема лінтера, Checkstyle каже тобі що не так, але йди фіксь сам 🤯
В сенснсі з коробки нема ? Checkstyle та PMD, як власне і IDEA Inspections вже напевно 20 років як є. В проектах SonarQube90-х років минулого сторічча, масса технологій розроблялась разом з поатформою і ріні Rust, D та Go lang роблять власні вбудовані : Junit, Maven, PMD , AspecjJ, Lombok або Spring. Дуже довго Java була мовою програмування номер один, і усі технології для рішення стандарних проблем розробки сиали копіюватись усіма, а подекуди прямо інтнегруватись з кробки, особливо в Rust.
Оскількі Java як і Python та JavaScript родом з середени
Це напевно недолік для тих кому хто не давно працює, або з інших тех стеків і треба щось зробити по швидкому.
Покажіть аналог Spring поза джавою і дотнетом. Rust якраз взяв геть іншу філософію, ніяк несумісною з Java. Скоріш зі Scala вже
працював з Rust 2 роки, у Rust нема а-ля Spring швидше через те, що там таке фізично не вийде імплементувати то все, хоча спроби є. Також Rust він не те щоб популярний для бекенд розробки, комюніті відносно невелике, не знаю як зараз, але2-3 роки тому, коли я з ним працював, то там екосистема була мега сирою по мірках бібліотек для бекенд розробки, що вже казати про мірки повноцінного фреймворку.
Щодо інших мов/технологій, у Node.js наприклад є NestJS в якості аналогу Spring, звісно він до Spring не дотягує у багатьох речах банально тому що це набагато більш молодий фреймворк
Подивився на NestJS, дійсно схоже. Мабуть, у джавістів спрацювала м’язова пам’ять коли писали на js. Хоча і Laravel з Symphony туди ж
-
перепрошую, тупанув, я мав на увазі не лінтер, а форматтер, але і автовиправлення помилок лінтеру це от те чого також дуже не вистачало)
Що існують інші мови.