JAVA преступно недооценена

Автор оригинала: jackson.sh
  • Перевод
Точка зрения невежественного студента информатики

image


Вероятно, вы прочитали заголовок этого поста и подумали: «Что этот парень курит? Java повсюду!» Вы правы, Java по-прежнему доминирует в отрасли и c ее помощью запускаются одни из крупнейших в мире критически важных приложений. Но распространение Java — это не то, о чем я говорю, я говорю о шумихе вокруг нее. Я провожу много времени с неопытными программистами. А что любят делать неопытные программисты? Быть взволнованным и самоуверенным в отношении таких инструментов, как языки программирования. Ни один из студентов CS, с которыми я встречаюсь, не восхищается Java, и я думаю, что так не должно быть.

Молодые/наивные разработчики (включая меня) часто попадают в ловушку фетишизации новых языков и инструментов в ущерб производительности и здравомыслию. До работы в Halp (теперь принадлежащей $TEAM) у меня были почти романтические отношения с серверным TypeScript. Я думал, что экосистема node.js была самой крутой вещью: мне понравилась идея транспилированного кода, отладки в реальном времени, огромной библиотеки пакетов и даже странных и фрагментированных систем сборки. Когда я действительно использовал его в разработке и поговорил с более опытными инженерами, магия быстро исчезла.

У меня была иррациональная привязанность к экосистеме JS, потому что это была горячая новинка; это было шумихой. Реальность не оправдала моих ожиданий. Сегодня я получаю удовольствие от чудесных вещей, которые я ожидал от JavaScript, когда набираюсь опыта в Java. Я чувствую себя обманутым тем, что шумиха не привела меня к Java раньше. Java — это весело писать, она продуктивна и пользуется среди новых разработчиков несправедливой репутацией динозавра.

Эргономика — вот что делает Java отличным языком программирования


Это нельзя недооценивать: на Java просто приятно писать. Во многом это связано с мастерством, которое JetBrains вкладывает в IntelliJ IDEA. Все заполняется автоматически, переход к определению выполняется быстро, использование find работает хорошо, а рефакторинг выполняется легко. Однако в чем действительно проявляется Java, так это в опыте разработчиков со сторонними библиотеками.

Зависимость тяжелых рабочих нагрузок и отраслевые тенденции


Мой опыт ограничен, но я чувствую, что ветер сдвинулся в сторону либерального использования внешних зависимостей. Not Invented Here уже не в моде, в моде — Not Invented There. В частности, разработчики JavaScript с большой вероятностью будут включать сторонние библиотеки даже для таких тривиальных операций, как заполнение числа слева. Я не думаю, что нынешняя привязанность к сторонним зависимостям особенно вредна, но изменения API в восходящем потоке могут нанести ущерб нетипизированным базам кода JS/Python.

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

Номинальный набор экономит время


У динамической/неявной/слабой/любой типизации есть ряд недостатков. Когда зависимость изменяет метод API, и ваше приложение дает сбой во время выполнения, а не во время сборки, это проблема. Когда разработчик должен вернуться к реализации метода, чтобы выяснить, какие типы передать, это пустая трата времени. Подсказки типов TypeScript и Python немного решают эту проблему, но им не хватает возможности проверять переданные типы во время выполнения без дополнительного кода.

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

interface Dog {
    bark: () => void;
}

/* The developer has to manually implement
a heuristic check for interface adherence!
When they update the interface, they have
to update the type guards too! */
function isDog(pet: object): pet is Dog {
  return (pet as Dog).bark !== undefined;
}
const dog: any = {bark: () => console.log('woof')};

if (isDog(dog)) {
    // TS now knows that objects within this if statement are always type Dog
    // This is because the type guard isDog narrowed down the type to Dog
    dog.bark();
}

Есть что-то в объявлении типа AND необходимости написания логики валидации для указанного типа, что меня действительно беспокоит. Приведенный выше код выглядит так, как будто кто-то использовал не тот инструмент.

В отличие от определений TypeScript, системы номинальных типов Java снимают нагрузку с мозга программиста, кристаллизуя определения типов и гарантируя защиту типов по умолчанию.

Снятие ответственности за оптимизацию


Разработчики Java могут с уверенностью доверять JVM, чтобы делать лучшие приложения. Независимо от того, реализуют ли они многопоточное приложение или хранят большой объем данных в куче, они могут быть уверены, что не выстрелят себе в ногу из-за управления памятью или гонок данных. Это преимущество прежде всего по сравнению с C++, который содержит множество ножных ружей.

Это часть эргономического опыта Java. Когда разработчику нужно меньше беспокоиться о технических деталях, он может больше сосредоточиться на текущей проблеме.

Святой Грааль продуктивности


Сколько языков вы можете вспомнить, которые удовлетворяют следующим условиям?

  1. Качественный менеджер пакетов и система сборки (Maven)
  2. Номинальный набор
  3. Большое сообщество
  4. Автоматическая оптимизация

Я думаю, что единственным подходящим инструментом является Java, но дайте мне знать, если есть другие!

edit: Как отметил Jwosty, конкурент Java — Microsoft C# имеет все эти характеристики и больше/новые языковые функции. Я никогда не использовал C# вне игрового движка Unity, но я собираюсь изучить его.

Удивительное отсутствие в университетской программе


В настоящее время я учусь в Университете Колорадо в Боулдере; это отличная школа, но она точно не известна за CS. Однако большая часть наших учебных программ по информатике для старших классов беззастенчиво украдена из CMU или Стэнфорда. За время учебы в CU я использовал следующие языки программирования:

  1. C++. Этот язык был выбран для всех необходимых основных курсов: компьютерные системы, операционные системы, структуры данных и т. д. Этот язык является разумным выбором, поскольку он обеспечивает прямое управление памятью, создание модулей ядра и представляет множество проблем и возможностей для обучения.
  2. Python и Julia. Как и следовало ожидать, эти языки были любимцами профессоров численных вычислений и дискретной математики.
  3. Scala. Этот язык использовался в Principles of Programming Languages, в первую очередь для его функционального программирования и функций сопоставления шаблонов. Хотя Scala использует JVM и взаимодействует с Java, у него совсем другой опыт разработки, чем у Java.
  4. Веб-языки (HTML/CSS/JS). Они использовались только в одном курсе под названием «Методы и инструменты разработки программного обеспечения», посвященном отраслевым тенденциям.

Я заканчиваю этот семестр, а Java не появлялась ни разу; Я считаю это позором.

Заключение


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

Java и JVM были раскручены до небес в 90-х и начале 2000-х, но я не думаю, что они когда-либо должны были исчезнуть! Опыт разработки, который я получил с IntelliJ и Java, заслуживает восхищения.

Мне любопытно, почему Java вообще потеряла ажиотаж. История культуры программистов плохо документирована, и если у вас есть понимание, напишите мне или оставьте комментарий (на reddit/Hacker News).
Timeweb
VDS и инфраструктура. По коду Habr10 — 10% скидка

Похожие публикации

Комментарии 93

    +12

    OutOfMemoryError

      +1

      И NullPointerException... Аж слезу пустил вспоминая J2ME :)

      +17

      Google Translate сочится из всех щелей; тяжело читать

        –14
        Ява тормозит. Ява сложнее более современных языков вроде c#. Ява скандально известна аффилированностью с корпорацией Oracle, которая решила внезапно повести себя по-свински. Ява считается устаревшей и теряет популярность. Ява должна умереть, я считаю: ) Но когда-то, до появления дотнета, она была очень актуальна. Сегодня кому надо скорость, пишут на c++. Кому надо гибкость и кросплатформенность (правда без интерфесный форм) пишут на неткоре или под винду с формами, короче c#. Кому нужны скриптовые языки, то есть питон и т.п. Ява как скрипач — не нужна. Но программисты будут еще долго востребованы, потому что тонны легаси в старомодных проектах. Начинать новый проект на яве выглядит безумием.
          +17
          Я когда сидел в период с 2010-го по 2018 в проекте на java 1.6, с фреймворками из начала 2000-х, struts, JSP, самописные скрипты ant и начинал волком выть, особенно когда начал параллельно для себя делать проекты на nodejs reactjs. Просто глоток свежего воздуха по сравнению с затхлой java. Все ваши аргументы повторял каждый день.

          Потом мигрировали на java 1.8, 11, пошли другие проекты с spring, maven и так далее. Я свое мнение поменял. Все довольно таки круто. Cерверное приложение я предпочту делать на java, чем на node.js. Java развивается как язык.
            +4
            Ява тормозит.

            Современные JIT-компиляторы очень близки по производительности к нативным программам. Огромное кол-во языков умеют работать на них, даже те, которые изначально задумывались иначе.

            Ява сложнее более современных языков вроде c#

            Не вижу особой разницы, о чем идет речь? Есть разного рода сахар вроде свойств, linq и тд. Но с точки зрения внутренностей, между CLR и JVM для обычного пользователя особой разницы нет. Если речь идёт о бойлерплейте, то оба языка не идут ни в какое сравнение с go/python.

            кросплатформенность (правда без интерфесный форм)

            Особенно без интересных форм. Кроссплатформенность дотнета выросла с момента релиза net core, но все еще находится на достаточно низком уровне, для написания бэкенда есть тысячи куда более надежных решений.
              +5

              Я бы сказал, что C# даже посложнее в плане языковых фич, но дает больше возможностей.


              Кроссплатформенность дотнета выросла с момента релиза net core, но все еще находится на достаточно низком уровне

              Почему этот уровень низкий?

                –1
                Тут правда. Она низкая хотя бы потому, что неткорь появился недавно. А яве 100 лет в обед. Поэтому яву можно запустить везде. А неткорь только на последних линуксах (к примеру). И то там с версиями разброд, как обычно у MS, музей версий. Есть такое дело. 5ка хорошая и выше.
                  –1
                  Дело не в этом. Джава с самого начала планировалась как кроссплатформенная и такая есть. А C# изначально планировался бегать под виндой онли и сейчас в него кроссплатформенность потихоньку допиливают.
                    –9
                    У меня главная претензия к неткорю — то что файлы получаются с расширением .dll. Под линуксом. Что совершенно никак не представляется считать труЪ. Интересно, можно ли это как-то исправить, чтобы было .so?
                      +5

                      Эти dll и на винде не настоящие — в них по сути запихан IL код. Вы можете скомпилить прогу в dll, а запустить ее где угодно без перекомпиляции, поэтому нужен один формат на все платформы. А само расширение сложилось исторически, переименовывать его сейчас во что-то другое нецелесообразно.

                        +5

                        .dll в .NET это же ни разу не .so

                        Это как просить переименовать .jar в .so

                        В остальном - "так исторически сложилось" :)

                  +4
                  Скажите, почему тормозит буквально любое гуевое приложение на яве? Из примеров: idea и родной ораклячий девелопер.
                    0

                    Потому что GUI нужен кому?
                    Microsoft для Windows и Apple для Mac, никто другой инвестировать в это ресурсы не будет.

                      +4
                      Ну вот тогда получается, что гуевая кросплатформенность, так усиленно продвигаемая, существует, но работает хреново. А у дотнета ее по факту нет, зато под виндой хотя бы работает идеально. Но есть ксамарин, обещают обещать его допилить.
                        –3
                        Усиленно продвигается просто кросплатофрменность. Гуевая кросплатформенность это так, приятный бонус, который 90% джава разработчиков даже нормально варить не умеют, потому что джава не гуев.
                          +1
                          Ну если убрать гуй, то тогда инструменты близки. .NET тоже опенсорс нынче.
                            0
                            Я сейчас ступаю на хрупкий лед предположений, но лично я, с моим поверхностным знанием С#, пришел к следующим выводам.
                            в С# больше синтаксического сахар, плюс он как более молодой язык посмотрел на некоторые грабли на которые наступила Java и сделал выводы. Его основная область применения десктопные приложения, в основном виндовые, но в последнее время сделан ряд шагов к кросплатофрменности.
                            в Java больше возможностей для fine-tune-инга чему способствует проработанная Memory Model и целый зоопарк Garbage Collector-ов на все случаи жизни. Очень большое количество внешних библиотек на все случаи жизни, на мой взгляд намного богаче чем у C#. Используется для серверов из которых 99% Linux.
                              +3
                              Ну да, когда я пробовал писать на яве, все там было как-то сурово. А на дотнете пишешь и не думаешь. То есть порог вхождения ниже. Тут и студия помогает, и фреймворк, и сам язык. Можно писать даже не сильно понимая сути. Хорошо это или нет, не знаю. Я противник винды и вообще всего что делает МС, но надо отдать должное, дотнет и все что вокруг него чудо как хороши.
                                +3
                                Возможно когда Вы писали на Javа Вы были зеленым новичком, а в C# пришли уже с каким-то багажом знаний поэтому у Вас возникло такое впечатление. Потому что лично для меня между ними особой разницы нет. Единственное C# для меня чуть сложнее для понимания из-за обилия синтаксического сахара. Java немного более многословная, но это окупается тем, что ты четко понимаешь, что делает каждая строчка.
                                  0
                                  А вот я наоборот. Пришёл из .NET в мир Java 1.8. И реально офигивал от того, насколько в Java всё неудобно и примитивно. Начиная от тяжелейшего и многословного синтаксиса и заканчивая потерей информации о generic-типах в рантайме (!!!). Помучавшись немного мы перешли на Kotlin. Вот тогда стало гораздо легче.
                                    +2

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

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

                                      0

                                      У Type Erasure два минуса:


                                      • на генерируемом и/или модифицируемом в рантайме коде можно налететь на проблемы
                                      • есть класс задач, которые было бы легче решить, если есть возможность узнать generic класс.
                                        0
                                        Я как-то с трудом себе представляю зачем в рантайме модифицировать код. Приведите пару примеров. Хотя бы более-менее жизненных и не решаемых текущими способами.

                                        И про второе аналогично. Чем не хватает текущих способов? И какие задачи это бы решило?
                                          0

                                          Первое нужно тем, кому не хватает производительность jvm и они пытаются её тюнить. Насколько это эффективно — не знаю, я в такие дебри ни разу не забирался. Среднему разработчику — это нафиг не сдалось.


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

                                          0
                                          Я согласен, что Type Erasure имеет минусы. Просто говорю, что это достаточно узкие случаи и прикладные разработчики с ними сталкиваются крайне редко.
                                  +3

                                  > Java больше возможностей для fine-tune-инга чему способствует проработанная Memory Model и целый зоопарк Garbage Collector-ов на все случаи жизни

                                  Все как бы немного наоборот - зоопарк сборщиков это не то что бы преимущество, а просто следствие отсутствия value objects, в итоге нагрузка на сборщик неизмеримо больше, чем в C# или Go, где by value обьекты присутствуют. Я помню в Minecraft было нормой выделять 600 мб/с мусора из-за использования векторов/матриц. В библиотеке JBullet автору приходилась написать инструментацию байткода для использования пула векторов/матриц. В C#/Go такие проблемы отсутствуют как класс.

                                    –1

                                    Это просто говорит о том, что Minecraft не очень хорошо написан. А зоопарк сборщиков нужен для того чтобы можно было подобрать необходимый баланс между throughput и latency или чтобы работать на куче в десяток терабайтн

                                      0

                                      >C4ET4uK 07.05.2021 в 08:04 Это просто говорит о том, что Minecraft не очень хорошо написан

                                      Там такая история, что первоначально позиции были заинлайнены в объекты, и метод перемещения выглядет как-то вроде setPosition(1, 2, 3), что обновляло 3 поля примитивных типа без выделения памяти. Но такой подход очень неудобен, т.к. простейшие векторные вычисления превращаются в спагетти. В итоге было переписано в код вида setPosition(new Vector(1, 2, 3)) что моментально увеличило нагрузку на GC до 600 мб/с. Ну и pointer chasing если это массивы объектов (а их в Minecraft много)

                                        0
                                        Ну вот сейчас задним числом можно сказать, что можно же было оставить setPosition(1, 2, 3), а внутри хранить мутабельный вектор.
                                          +1

                                          Мутабельные векторы тоже так себе идея. Если где-то случайно зашарить объект по ссылке не склонировав, то внезапно позиции рандомных объектов связаны и поди отладь что не так

                                            0

                                            Просто геттер должен возвращать закэшированную немутабельную копию. Мне показалось это достаточно очевидным, чтобы не упоминать.

                                              0

                                              >Просто геттер должен возвращать закэшированную немутабельную копию

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

                                                0
                                                Ну вообще рантайм умеет в скаляризацию, и может аккуратно этот объект разобрать на запчасти и разложить на стеке. Но без гарантий.
                                                  0

                                                  Про escape analysis много говорят при обсужлении темы тормозов Java, но по факту он работает только для небольшой горстки тривиальных случаев.

                                    0
                                    Его основная область применения десктопные приложения, в основном виндовые, но в последнее время сделан ряд шагов к кросплатофрменности.

                                    Вот любопытно, сколько на одно выпущенное десктопное приложение сейчас приходится игр, сделанных на Unity. Не окажется ли так, что основная область применения C# сегодня ― это кроссплатформенный геймдев?

                          • НЛО прилетело и опубликовало эту надпись здесь
                              +3
                              Наверное, потому что Idea огромная и делает множество тяжеловесных вещей параллельно с работой пользователя
                                –1

                                Потому что они написаны на фреймворке который умер более 10 лет назад. Хотя по сравнению с электроном все равно работает быстро.

                                  +2
                                  В Idea тормозит не гуй, а миллиарды кешей, синтакс анализ и куча других фишек. Можно сравнить с Visual Studio и заметить что последняя тормозит на wpf куда сильнее
                                    0
                                    Скажите, почему тормозит буквально любое гуевое приложение на яве?

                                    Это не соответствует действительности.


                                    Из примеров: idea

                                    idea это не любое приложение, это лучшая среда разработки для java, kotlin и кучи других языков. Можно было бы сказать, что она тормозит, если бы было другое приложение со сравнимым количеством фич, которое работает быстро. Но его нет.


                                    и родной ораклячий девелопер

                                    Почему тормозит девелопер сказать не могу, так как не пользуюсь. У девелопера есть нетормозящие аналоги сделанные на других языках?

                                  +6
                                  Ява скандально известна аффилированностью с корпорацией Oracle, которая решила внезапно повести себя по-свински.

                                  Java — это open source под GPL, в который контрибьютят несколько десятков компаний. И сам язык, и компилятор, и виртуальная машина, и стандартная библиотека, и всё остальное свободны. Oracle принадлежит только торговая марка.
                                    +3
                                    Ну да. Нас тут недавно начальство спросило, что мы думаем о миграции с Oracle сборки Java. В итоге начали анализировать, на что можно перейти, и выяснили, что вариантов где-то примерно 10 штук — и это даже не считая например IBM J9. То есть зависимости от Oracle на сегодня практически нет, более того, благодаря им же на сегодня open source сборки практически не отличаются от сборок Oracle по наличию каких-либо фич (Flight Recorder, скажем, был открыт в 2018).
                                    0

                                    На java написано огромное количество больших сервисов, как старых так и новых.
                                    Вполне хватает библиотек, чтобы не писать все с нуля.
                                    Единственное что умирает, так это ваши "кросплатформенные" десктопные приложения.
                                    Современная кроссплатформенность — это Mobile плюс Web, там C# и не пахнет.
                                    Кому нужны скриптовые языки? Python пригоден для прикладных задач типа DevOps и ML.
                                    Единственное с чем соглашусь что не стоит начинать новый проект на Java… когда есть Kotlin (но Java тоже придется выучить)

                                      –4
                                      Кросплатформенность это бэкенд + морда (возможно, на телефоне). Напомню, на всякий случай, что на айфонах JVM нет и не планируется, и правильно делается. Только через транслятор в си. А что касается бэкенда, то для него, в частности, web API, c# и его netcore это пожалуй лучшее, что сейчас можно придумать. В целом c# сегодня наиболее универсальный язык для всего. Есть ограничения по кросплатформенности, пока это единственный минус. А еще родная VS прекрасна. Под линуксом, правда, ее нет, только VS Code. А idea платная. В бесплатной версии нет даже форм. Eclipse чудовище. В чем разрабатывать под явой — неясно. А на c# запустил стандартную студию и программь, а там есть все.
                                        +9
                                        Но ведь это просто ваши вкусовые предпочтения и не умение в java и ее инструментарий, мне например VS кажется убогим и кривым поделием, и судя по полуряности Rider'a я не одинок. Я бы мог назвать еще ряд минусов С#, но зачем? Это просто другой язык, да похожий, но при этом со своей идеологией и областью применения. Судя по вашим комментариям вы плотно занимаетесь GUI, и почему-то ругаете Java, что она плохо умеет в GUI, Так ведь она и не собиралась. Java это backend, надежный, высоконагруженный, многопоточный backend, и она с этим отлично справляется. Что касается IDE, вы знаете, за все время работы я всего два раза сталкивался с ситуациями, когда работодатель не предоставлял мне Ultimate Idea и из них ровно 0 раз когда она мне при этом была действительно нужна. В конце концов учитывая текущие зарплаты разработчиков жаловаться, что профессиональный инструмент которым зарабатываешь на хлеб с маслом стоит денег… ну я даже не знаю как это назвать. А то, что для использования VS нужно Windows покупать, а на линуксе только урезанный VS Code есть, это тоже в минусы C# запишем?
                                          –3
                                          Разумеется, обозначенные минусы VS действительно минусы. Винду кстати сейчас вроде покупать не обязательно. Но могу ошибаться. Технически она работает, обновляется и выглядит почти как живая даже без денег. А идею можно да, купить. Но только если ты реально плотно сидишь на именно разработке и именно на яве.
                                            +1
                                            Технически Ultimate Idea тоже покупать не обязательно. Можно пользоваться Trial-ом и каждый месяц сбрасывать счетчик или пользоваться EAP-ом. Технически оно работает, но делать так, конечно, не надо. А кому еще нужна Ultimate Idea, кроме тех кто плотно сидит на разработке Java?0_o
                                              –1
                                              Ну я там спринг увидел в платных опциях.
                                                +1
                                                Триал и EAP позволяют пользоваться всеми возможностями Ultimate версии. Или я не понял Вашу мысль.
                                          0
                                          c# сегодня наиболее универсальный язык для всего. Есть ограничения по кросплатформенности, пока это единственный минус

                                          Так этот минус как раз и противоречит универсальности.


                                          А еще родная VS прекрасна. Под линуксом, правда, ее нет

                                          Универсальна, но нигде кроме венды не кроссплатформенна, vs прекрасна, но нигде, кроме венды её нет. Шикарная штука, я щитаю — надо брать! :)


                                          только VS Code

                                          Отстой отстойный. Если "большой" VS на него похож, то это минус, а не плюс.


                                          А idea платная.

                                          В той же степени, что и VS


                                          В бесплатной версии нет даже форм.

                                          свингового уи дизайнера что ли? А кто-то ещё пишет на свинге?


                                          В чем разрабатывать под явой — неясно.

                                          вот в идее и разрабатывать. Если нужны спринговые фишечки, то пинать работодателя — пусть покупает рабочий инструмент.

                                          +3
                                          Единственное с чем соглашусь что не стоит начинать новый проект на Java… когда есть Kotlin

                                          Или дождаться рекордов с тонкими потоками (их там снова не переименовали случаем?) в основной Джаве. Это закроет подавляющую часть преимуществ Котлина.

                                          И Вальхаллу заодно дождаться бы. Тогда по скорости перекладывания джейсонов посоревноваться можно будет много с кем. Не то чтобы это имело смысл, но приятно же.
                                            0

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

                                              0
                                              Осенью рекорды. Почему надо обнвовляться на неLTS версию я даже для себя обосновать не могу. Не говоря уже о других.

                                              А что там из Вальхаллы приехало уже? Ключевое вроде даже не начали в основные билды заносить.
                                                0

                                                Обоснований куча. Для меня это шанс обновляться маленькими шагами, а не огромным скопом. Плюс возможность иметь фишки раньше. Не надо относиться к неLTS как к бетам.

                                                  0
                                                  Не надо относиться к неLTS как к бетам

                                                  Увы приходится. Продакшен, деньги вот это вот все. Обоснование должно быть достаточным чтобы обосновать даунтайм и миллионы денег. Миллионы денег не из моего кармана, но обосновать зачем неLTS версия в проде надо будет.

                                                  Хорошо если на 17 удастся до НГ перейти. Даже в это слабо верится, но хотя бы надежда есть.

                                                  неLTS это именно беты. Там в каждой есть критические баги. Которые никогда не будут исправлены в текущей версии. Обновляться на следующую это ловить потенциальные новые баги.
                                                  Править jdk самим это вообще ужас. Кастомные сборки jdk, даже связываться не хочется.

                                                  Для меня это шанс обновляться маленькими шагами, а не огромным скопом.

                                                  Обосновать зачем пересаживаться на новую LTS весию я могу легко.
                                                  Начать с: Попробуй найми людей на jdk9.
                                                  И заканчивая миллионом оптимизаций между 9 и 11. Эти оптимизации экономят много серверов.
                                                  В итоге даже два месяца работы отбиваются легко. Обосновать как нефиг делать.

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

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


                                                    неLTS это именно беты. Там в каждой есть критические баги.

                                                    Можно примеры таких багов?


                                                    Единственный баг, который реально словили за всё время — описан в этой статье (сами с ним не разобрались, а просто на бою накинули ресурсов). При этом наверняка были какие-то тонкости, которые время от времени решали, но это было быстро и незаметно.


                                                    Поэтому я всё-таки склонен считать, что релизы это именно релизы. Для достаточной уверенности можно не использовать preview features (я использую), и подождать хотя бы первого Update.


                                                    А вот как обосновать хотя бы пару недель два раза в год для пересаживания на неLTS с учетом потенциальных багов в ней я не знаю.

                                                    Ваши "2 недели 2 раза в год" — как-то очень завышено. В среднем это от 1 часа до 1 дня. Иногда (12 -> 13 и 13 -> 14) уходило по 5 минут на Find & Replace. Как раз то, что даже можно не пропихивать бизнесу, а просто взять и сделать, потому что обсуждать дольше (естественно, речь про один среднего размера проект на единицы микросервисов, а не "целый банк").


                                                    Единственное, что меня реально пугало бы в любом отдельно взятом проекте — миграция с 8 на 9+.

                                                      +1
                                                      Можно примеры таких багов?

                                                      Да. Можно поискать по трекеру. Все что задело 11, 16, 17 версии точно есть и во всех промежуточных. Все что задело 16 и 17 и не связанно с новым функционалом с большой вероятностью есть и в 15.

                                                      SIGSEGV bugs.openjdk.java.net/browse/JDK-8254790
                                                      GC падает bugs.openjdk.java.net/browse/JDK-8246468

                                                      Еще можно вот так по разным минорам 11 посмотреть. Они почти все есть и в более новых jdk www.oracle.com/java/technologies/javase/11-0-8-bugfixes.html
                                                      Чем свежее минор, тем более поздние версии jdk в которых баг исправлен будут.

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

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

                                                      У меня проект немного побольше. И времени тоже уйдет немного побольше. Я не просто так такие сроки написал.

                                                      Пусть даже я тоже могу взять и сделать. Пару недель времени спрятать мы все можем.
                                                      Проблема в обосновании возникет после того как прод развалится. Надо будет выйти и рассказать зачем я обновил jdk и что я буду делать чтобы прод так же второй раз так же не развалился. Вариант ставить сделующие неLTS jdk и верить что в них мы не развалимся очень слабый. А других в общем-то и нет. Я после такого сам себе скажу что надо откатываться на LTS.

                                                      Что делать с LTS версией в таком случае понятно. Накати последний минорный релиз, если повторяется ищи конкретику и пиши баг репрот. Поправят.

                                                      Единственное, что меня реально пугало бы в любом отдельно взятом проекте — миграция с 8 на 9+.

                                                      Миграция 9 -> 11 у нас как раз и заняла что-то ближе к 2 месяцам. На основе этого я и предсказываю сроки таких же обновлений.
                                                        0

                                                        Спасибо за ответы.

                                          +5

                                          Java тормозит на запуске, особенно холодном, что сильно заметно по GUI и консольным утилитам. Но горячий сервер-то не должен тормозить, особо нет причин для этого. JVM это state of the art.

                                            0
                                            JVM это state of the art

                                            Не всякая JVM. Точнее не так — state-то они state, но каждая по-своему. Что, в общем-то, логично, разным приложениям нужны разные оптимизации. Кому-то например нужен быстрый старт — у них внутренние формы всех классов, грубо говоря, дампятся на диск, и от того Java не тормозит на запуске. А кому-то не нравится появляющаяся из-за дампа дырка в безопасности, и там загрузка множества классов идёт "честно", но подольше.

                                              0

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

                                              То, что на Java часто овериндженирят - это уже другой вопрос.

                                              0

                                              Есть способы ускорить холодный запуск. Например CDS

                                                0

                                                Кому важен холодный старт те сейчас обычно компилят граалем в нативный код. Тем более что и в спринге наконец подъехала поддержка(честно говоря не ожидал с учетом того сколько у спринга завязано на рантайм)

                                                +1
                                                Ява тормозит

                                                Джава-пожалуй один из самых быстрых языков с gc, пожалуй только го может сравниться, но очень сильно зависит от сценария использования(go гибкий, но в своей нише очень хорош)


                                                Ява сложнее более современных языков вроде c#.

                                                Это джава-то сложная? По-моему один из самых простых языков синтаксически, большнство джаву хетят как раз за отсуствие сахара и примитный синткасис, но сам язык предельно простой.


                                                Ява считается устаревшей и теряет популярность

                                                Кем простите считается?

                                                –9
                                                При использовании сторонних библиотек в Java вы всегда точно знаете, какие типы нужно передать методу

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

                                                много народу так поначалу думало
                                                  +2
                                                  null и Object смеются над этим утверждением


                                                  Ну я лично все реже встречаю код, где Object в качестве типа данных используется. Иногда встречаю еще, в пережитках пришедших из java 1.4.

                                                  И null все чаще заменяется Optional, что имхо повышает шанс, что люди подумают, что передать в метод и что могут получить.
                                                    +1

                                                    Optional не стоит использовать как параметр метода. (Rule 14, Recipe 15)


                                                    https://blogs.oracle.com/javamagazine/the-java-optional-class-11-more-recipes-for-preventing-null-pointer-exceptions

                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                        0

                                                        Я привел ссылку, проблема в другом: вызывать метод становится неудобно: приходится оборачивать аргумент в Optional.ofNullable() (или в Optional.of(), Optional.empty()) во время вызова.

                                                          +3
                                                          Давно уже изобрели аннотации @NotNull и @Nullable
                                                          Они компайл тайм. Не влияют на скорость, отлично показывают и гарантируют ожидаемые параметры. Рекомендую.
                                                            0
                                                            Что-то не могу найти, как @NotNull останавливает компиляцию с ошибкой. В лучшем случае это хак (а по-видимому это вообще не про типизацию, а про реайлтайм проверку).

                                                            Java и C# отталкивают именно из-за этой особенности. Никогда целиком не понятно, какого типа у меня переменная.
                                                              0
                                                              Да, извиняюсь. Идея это делает. jvm в рантайме падает или не падает в зависимости от настройки той же Идеи.

                                                              Идея слишком раслабляет. Начинаешь путать что именно ту или иную штуку делает.

                                                              Хотя в общем какая разница? Когда одна IDE у всех это удобно. Одни проверки, одни дефолты. Не надо как плюсовики мучаться.

                                                              www.jetbrains.com/help/idea/nullable-and-notnull-annotations.html#nullable
                                                                +3
                                                                Если вы добавите сигнатуру @NotNull в сигнатуру функции, то Intellij станет ругаться «у этой функции есть пользователи, которые теоретически в неё могут передать null»? Любое изменение в коде должно гарантировать совместимость типов. В целом, можно конечно на основе этой аннотации придумать статический анализатор типов, который будет считать все объекты T|null, кроме помеченных @NotNull. Но…
                                                                1) Такого анализатора, наверно, нет.
                                                                2) В Java нет и не будет ничего подобного тип-суммам, поэтому такой подход чужероден
                                                                3) Нет синтаксиса разворачивать такой тип, кроме if (a != null), который слегка неочевиден.
                                                                4) В реальной разработке тип T нужен намного чаще, чем T|null, то есть именно он должен быть по умолчанию.

                                                                Лучше не жевать кактус, а сразу взять Kotlin для нового проекта, по-моему.
                                                                  0

                                                                  Ну вам же только что сказали, что есть. Да оно будет высвечивать жёлтое предупреждение об ошибке. Далее — можно в билде мавена настроить, чтобы и он тоже падал, при обнаружении нарушений данного контракта. Ну что поделаешь, Java был создан, когда нулл был в тренде. Гослинг, если мне память не изменяет тоже каялся по поводу включения понятия null в Java… но отменять десятки лет обратной совместимости… в общем не стоит оно того.

                                                                    0
                                                                    Но ведь это есть и работает.
                                                                    Статический анализатор тоже есть. Он как раз в Мавен плагином подключается и фейлит сборку при соответвующих настройках.

                                                                    Проблема на самом деле ровно одна: Что считать дефолтом? Все Nullable и размечаем только NotNull или наоборот все не NotNull и размечаем наоборот Nullable. Размечать и то и то оверкилл.

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


                                                                      Не совсем так. Multi-Catch:

                                                                      try {
                                                                         ...
                                                                      }
                                                                      catch (IllegalArgumentException | IllegalStateException e) {
                                                                        ...
                                                                      }
                                                                      
                                                                        0
                                                                        Насколько я понимаю, тут переменная просто приводится к общему родительскому типу. Это так же далеко от тип-суммы, как если объявлять сразу catch (Exception e).
                                                                          0

                                                                          Нет, не просто приводится. Этот блок действительно ожидает именно один из указанных типов исключений. Более того, там есть дискриминация по типу. То есть если сделать вот так:


                                                                          private void handler() throws IOException {
                                                                              try {
                                                                                 ...
                                                                              } catch(IOException | SQLException e) {
                                                                                  throw e;
                                                                             }
                                                                          }

                                                                          То вашей ошибкой компиляции будет "Unhandled exception type SQLException".


                                                                          UPD: насколько я понимаю, в Java на этом же синтаксическом принципе в итоге будет основан conditional flow из JEP-305 — правда там пока без Union.

                                                                    +1
                                                                    Java и C# отталкивают именно из-за этой особенности.

                                                                    Не знаю на счёт Java, но в C# эту проблему решили в 8-й версии языка. Плохо, конечно, что так не было сделано с самого начала. Но по крайней мере, прогресс не стоит на месте.
                                                            +1
                                                            Что «нужно передать» — это сигнатура метода. В ней не бывает null. Так что это вы сказанули не подумав.

                                                            Да, type erasure портит дело в рантайме, никто не идеален, и JVM тоже. И система типов Java далеко не идеальна, хотя для практики обычно достаточна. Я бы тоже хотел систему типов, ну хотя бы как в Scala… ой, погодите, но ведь когда мне этого очень хочется — я беру и пишу на Scala? И потом это запускаю в той же JVM, вместе с кодом на Java. То есть у меня есть среда, где можно запускать код, написанный на разных языках, взаимодействующих друг с другом.

                                                            Насчет же гонок и управления памятью, хочу отметить, что подзаголовок гласит:
                                                            >Точка зрения невежественного студента информатики
                                                            что в общем есть чистая правда (там описано, какой у него опыт). Так что я бы не тратил время на споры с автором вообще. А уж тем более на споры с переводом )
                                                              0
                                                              У нета есть c#, f# и даже прости господи бейсик: ) Бейсик кстати классный язык.
                                                                0
                                                                Ну еще и f# есть. И что? Я про систему типов вообще-то говорил.
                                                            +5
                                                            Это вы еще .NET не попробовали.
                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                +2

                                                                >На Линуксе же он работает только пока не начнёшь подключать родные библиотеки С++

                                                                Что вы имеете в виду? Проброс исключений C++ через фреймы CLR? Конфликты между пользовательскими обработчиками сигналов и тех что устанавливает CLR? Разница в ABI у C++ библиотек? Отсутствие COM/Winapi? Отсутствие C++/CLI?

                                                                Оборачивал библиотеки на C и не увидел проблем, кроме несуразностей вроде присутствия Unicode-маршалинга как Utf16 в P/Invoke и отсутствия Utf8 (но не знаю как с этим в .net core)

                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                    0

                                                                    >Виндовые дефолты отовсюду торчат.

                                                                    Есть такое. Более того, в рантайме есть PAL (по крайне мере, раньше было) - это, по сути, реализация подмножества Windows API средствами Unix, чтобы первоначально Windows-only код весь не переписывать (этакий простецкий winelib). В итоге и семантика виндовая, зато полная совместимость... В mono тоже был слой эмуляции Виндовой подсистемы (в основном I/O)

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

                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                        0

                                                                        Не знал, что Хабр не умеет в отложенное схлапывание нескольких уведомлений в одно, это забавно. Сам я личной почтой вообще не пользуюсь, поэтому про какие-то уведомления даже не думал.

                                                                          0
                                                                          отдельное уведомление о новом ответе

                                                                          А вот кстати раньше вроде не было такого, заметил это относительно недавно.

                                                                +2
                                                                JAVA преступно недооценена

                                                                По крайней мере в России, это конечно же не так. Но если будет так, то тоже не против. Меньше конкуренции, еще выше ценники.
                                                                  –3

                                                                  Бедный мальчик ...

                                                                  Джава это вообще не язык, это дрочево с блекджеком и всем остальным, тех, кто так и не втащил си!

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

                                                                  Джава - это священная корова которая выглядит очень красиво, мычит акт ангел поёт и кушает золото и младенцев, но никто никогда так и не дождался от нее молока, неимоверными трудами и затратами можно выделить пару жалких капель.

                                                                  Студенты вообще народ восторженный и максималисты поэтому джава и родилась и проштырила индустрию так долго но теперь то с джаавой уже вообще всем все понятно!

                                                                  Ан нет! Нашелся вот прозорливець )

                                                                  В статике нет ничего кроме автоподстановки и за это "удобство" ты платишь кандалами типизации.

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

                                                                  Но адепты статики предпочитают концентрироваться на детальных описаниях ужасов такого столкновения а не на ничтожных шансах его вероятности.

                                                                  Язык программирования должен решать повседневные задачи и при этом вызывать минимум эмоций и хороших м плохих.

                                                                  Мы все дышим воздухом каждую секунду и без воздуха никто не может прожить больше пары минут, но никто не приходит в восторг от акта дыхания и не ставит алтари "во славу живительного кислорода" зато если вдохнуть чего-то другого то да можно и кайфануть и озадачиться вопросом :зачем все эти люди просто дышут когда могли бы торчать!?

                                                                  Да потому, что миру нужны уборщики и водители, массажисты и продавцы, художники и программисты а не торчки!

                                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                  Самое читаемое