С момента появления Java in 1995 много всего изменилось в мире как в часте софта так и железа. Изменился также и релизный цикл выпуска новых версий. Они начали появлятся гораздо чаще и привносить в язык много интересных возможностей. Язык буквально на глазах преображается и не отстает от трендов индустрии.
Язык Java прошел большой жизненный путь и за это время вокруг него сформировалось много разлычных мифов и слухов. Часть из них рождались в холиварных спорах о том какой язык лучше. Часть имеют под собой реальное обоснование и связанны с различными ограничениями софта\железа существовавшими на тот момент, но с течением времени утратившим свою актуальность. В этой статье мы постараемся сфокусироваться как раз на мифах утративших свою актуальность.
Нужно компилировать Java код перед его запуском
Любой Java разработчик знает, что главная фича Java это виртуальная машина исполняющая байт код и за счет этого достигается высокая кроссплатформенность. Для получения байт кода нам необходимо компилировать наши программы. По сравнению со скриптовыми языками это можно рассматривать и в положительном ключе и в отрицательном. Как минимум в холиварах такая тема часто поднималась раньше.
Начиная с Java 9 у нас появился довольно интересный инструмент jshell. Это утилита командной строки, которая вошла в состав Java Development Kit (JDK) и была добавлена в рамках JEP 222. При помощи нее вы можете исполнять Java код. На самом деле процесс компиляции в байт код никуда не делся. Он просто теперь происходит "под капотом" и у вас создается иллюзия, что Java код можно исполнять так же "просто" как это делается в скриптовых языках.
В Java 11 была добавлена фича по запуску Java программы, хранящейся в одном файле исходного кода, через java launcher. Это новшество было превнесено в JEP 330. Комниляция опять же никуда не делась. Она происходить "под капотом", а скомпилированный байт код хранится в памяти на время исполнения. У вас опять же создается иллюзия, что как и со скриптовыми языками, вы сразу "скармливаете" ваш исходный код java launcher и исполнение происходят без компиляции.
Java "медленная" ))
Самая обсуждаемая тема, когда встречаются "адепты" разных языков и начинают меряться фичами ))
Надо признать, что совершенного языка программирования, который бы "рвал как Тузик грелку" все остальные языки, пока не придумали.
В теории можно попытаться подобрать набор тестов, тестовых данных и окружение для того чтобы убедить "толпу" адептов в чем угодно.
Возможности могза человека существенно ограничены и человечество придумывало различные подходы и методологии для того чтобы постараться выжать максимум из доступных на данный момент для человечества возможностей наших физических оболочек. Как следствие мы в IT шли по пути придумывания все большего количества абстракций и специализации практически во всем. На мой взгляд особенно это проявилось в языках программирования.
На первых этапах своей жизни Java действительно сильно проигрывала в производительности и возможно с тех пор за ней закрепился такой миф. Изначально перед ней ставились другие задачи и как показало время она хорошо их закрывала. Благодаря этому она получила такое распространение и популярность. За время своего существования в ней произошло много разных изменений существенно повлиявших на производительность в большую сторону.
Я считаю, что в целом сравнивать скажем ассемблер или машиные инструкции с другими языками и в том числе с Javа не имеет под собой особого смысла.
Мы не пишем большие системы на ассемблере или машинных инструкциях не потому, что они плохие. Делая выбор на чем строить очередную систему мы ишем компромисы с учетом важных для нас приоритетов. Опять же идеальный язык программирования пока не изобрели и мы решаем для себя ради чего и чем готовы пожертвовать.
Когда речь идет о бизнесе, то там часто во главу угла ставят экономическую целесообразность или говоря проще выгоду. Работать бесплатно или в убыток такое себе удовольствие (да простят меня фаны опенсорса, хотя если копнуть глубже, то открыть исходный код еще не значит отказаться зарабатывать на нем, но это отдельная история).
Можно ли технически написать большую бизнес систему на ассемблере, С или любом другом языке? В теории можно на чем угодно, что потом можно будет перевести в машиные инструкции и что сможет исполнять процессор, но цена вопроса будет совершенно разной. Как минимум в случаи бизнес систем нужно учитывать в том числе и тот факт, что "жизнь программы" как правило не заканчивается выпуском первого релиза, если она востребованная. Нужно учитывать последуещее ее развитие и поддержку.
И вот тут часть языков "отваливается". Шучу ))
В чем компромисс Java? Там есть Just-In-Time компиляция. Если мерить время старта, то Just-In-Time компиляция будет играть против нас. Да, есть проекты, которые пытаются всеми правдами и неправдами ускорить время старта. Например такой проект как CRaC или вообще компилировать сразу приложение в нативный код как это делают в C\C++ (проект graalvm). В целом возможно именно из-за этого Java не получила широкого распространения на десктопах, хотя казалось бы на писал один раз и запускаешь на чем угодно.
Тут очень важно понимать, что ничего не бывает "бесплатно". За все нужно платить и выигрывая в чем-то одном мы проигрываем в чем-то другом. Тут самое главное понять, что для вашего конкретного проекта критично, а чем можно пожертвовать, но жертвы будут всегда.
Если мерить производительность после "прогрева" виртуальной машины JVM, то ситуация в последних версиях будет радовать. Появилось много разных сборщиков мусора существенно влияющих на производительность в определенных кейсах. Нужено подобрать правильный для вашего кейса, но это тема для отдельной статьи )) В самом языке появилось много конструкций позволяющих писать эффективный код. Опять же можно подобрать набор тестов, данных для тестов и окружение, чтобы доказать, что в части случаев Java будет быстрее С. Я даже такое встречал на просторах интернета. Код программы в инструкции переводит компилятор. Можно ли найти\подобрать компилятор С генерирующий для ряда кейсов "плохой" байт код? Ну думаю идею с подгонкой сравнений вы поняли.
В конечном итоге на каком бы языке вы не писала в итоге процессор будет исполнять нативные инструкции. Для процессора не существует наших высокоуровневых языков. Он понимает только свои инструкции и в данном контексте меня раздражает даже сама фраза "язык Java в части случаев быстрее С". Это применимо к любому языку потому что в конечном итоге процессор исполняет свои инструкции и для него не существует такого понятия как Java, C или любой другой язык программирования. В целом еще можно говорить про эффективность генерируемого нативного кода тем или иным компилятором там где это уместно.
Важно в теме производительности правильно расставлять акценты. Можно обсуждать на сколько эффективный нативный код мы получаем в каждом кейсе для определенной версии компилятора, но не нужно говорить про эффективность языка. Язык это абстракция на которой мы "думаем" наши программы и не более того.
Итого:
- Достаточно ли производителен язык Java для бизнес приложений?
- Для части приложений да. Нужно всегда отталкиваться от требований к производительности, которые могут быть зафиксированы в SLA и регулярно производить нагрузочное тестирование. Вы можете выбрать любой язык, который позволит вам достаточно долго оставаться в рамках допустимой производительности и при этом доставлять вам и вашей команде удовольствие от кодирования. Тут конечно нужно не забывать про масштабируемую архитектуру системы в целом.
- Есть ли бизнес приложения, где его скорости будет недостаточно?
- Все будет зависить от железа и "прямоты рук", но да могут быть кейсы где "прямых рук" будет недостаточно. Из-за специфики его архитектуры такой как наличие виртуальной машины и GC вы будете иметь накладные расходы, которые могут оказаться существенными.
- Есть ли другие не бизнес приложения в которых можно даже не пытаться использовать Java?
- Опять же из-за специфики архитектуры такой как наличие виртуальной машины и GC даже не нужно пытаться решать системные задачи на нем. Пример: драйвера, операционные системы и тому подобное. Хотя например для программирования чипов банковских карт он очень даже хорошо вписывается по сравнению с конкурентами. Да. Там накладные расходы выше, но он гораздо удобнее. Те кто в теме не дадут соврать.
Если этот "поток" сознания будет вам полезен и понравится, то буду дальше писать про остальные мифы.