• Методы расширения в Java
    0

    Спасибо!

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

    Да. От своих слов не отказываюсь.


    Тем самым добавляя в Джаву синтаксический сахар, который вам не нравится ))

    Скорее "поддерживая популярные технологии, даже если они кривые, потому что люди хотят". Мы в первую очередь делаем IDE удобную для всех, поэтому и поддерживаем. Но это не делает ломбок джавовее.

  • Методы расширения в Java
    +3

    Хм. При чём тут мой бог? Ничего не понял.


    Я, кстати, тоже участвовал в поддержке ломбоковских extension-методов в IntelliJ IDEA. Кстати, баги всё равно возможны. Наверняка ещё остались инспекции, квик-фиксы, рефакторинги, которые не ожидают такой подставы, что метод — вовсе не метод.


    Интересно, что Stream.toList() появится в 16-й Java, причём будет там отличаться от Collectors.toList() (в отличие от последнего, возвращает неизменяемую коллекцию). Удачи потом баги фиксать.

  • Анбоксинг в современной Java
    0

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

  • Java 16 — новые синтаксические возможности языка
    0

    Не забываем про обратную совместимость.

  • Анбоксинг в современной Java
    +1

    Я говорил про свой собственный тип-обёртку, а не Integer. Читай внимательнее.

  • Java 16 — новые синтаксические возможности языка
    0
    Если класс не объявлен явно как final или sealed, то по логике вещей он как раз non-sealed.

    Этот вопрос обсуждали, естественно. Смысл в том, что хорошего дефолта нет, а если сделать, что дефолт = non-sealed, то люди будут просто по забывчивости или лени открывать свои иерархии. Поэтому надо явно указывать.

  • Java 16 — новые синтаксические возможности языка
    0

    Я же тебе сказал, в amber-spec-comments, даже ссылку приложил.

  • Анбоксинг в современной Java
    +1

    Такие преобразования выполняются на платформенно-независимом IR задолго до кодогенерации, поэтому на ARM проблем быть не должно. Но если у кого-нибудь есть ARM под рукой, можете измерить. Что касается компиляции в нативный код — если это делать с помощью GraalVM, то она щёлкает боксинг как орехи уже давно. Там эскейп-анализ и скаляризация наголову выше, чем в C2. Они даже хвастались, что Objects.hash(i, j, k) будет работать с той же скоростью как и явный аналог типа ((31+i)31+j)31+k, то есть они и от массива-варарга, и он боксов в каждом элементе избавляются на раз.

  • Java 16 — новые синтаксические возможности языка
    +1

    Ну вот да. Я, кстати, не стал специально писать про смысл open в module-info, но и Реми, и Брайан сами про это упомянули. Maccimo, иди ворвись и скажи им, что они не потрудились :-)

  • Java 16 — новые синтаксические возможности языка
    +1

    Ну так и быть, вкинул слово 'open'. А то Maccimo вряд ли сам напишет. Посмотрим.

  • Java 16 — новые синтаксические возможности языка
    0

    Со словом open другая проблема — это уже ключевое слово! Да-да, только оно используется исключительно в файлах module-info.java, означая, что в данном модуле все классы доступны в рантайме (к примеру, для грязного рефлекшна). Кажется, что это может привнести некоторую путаницу: если класс объявлен open, это может быть воспринято в том же контексте (другим модулям разрешено лазить в потроха класса).

  • Java 16 — новые синтаксические возможности языка
    +1

    Ну теоретически можно сделать контекстно-зависимое ключевое слово open, которое является ключевым только в списке модификаторов. Собственно, слово sealed так и добавлено: вы спокойно можете иметь метод sealed или переменную sealed.

  • Java 16 — новые синтаксические возможности языка
    +2

    Чего ж ты не написал свои гениальные идеи в мейлинг-лист? :-) Кстати, ещё не поздно: фича не финализирована, ключевое слово вполне можно поменять. Иди в amber-spec-comments и предлагай! На Хабре-то тебя Брайан не прочитает :-)

  • Java 16 — новые синтаксические возможности языка
    +3

    Всё просто. Shape — это интерфейс. Рекорды могут реализовывать интерфейсы. Есть у него точка в виде поля или нету — никого волновать не должно. Квадрат может быть удобно задать центром и длиной стороны, а может быть углом и длиной стороны. В одном из случаев метод, который возвращает центральную точку, не будет тривиальным геттером, а будет вычислять значение. Должна быть возможность тривиальным образом сменить одну реализацию на другую, не сломав ни одного клиента. Абстракция! Рекорд по определению имеет прозрачную структуру, он не обеспечивает абстракции.


    Ну вот IDEA же как-то с этим справляется

    Тут, например, можно почитать на эту тему.

  • Java 16 — новые синтаксические возможности языка
    +1

    Это и называется flow typing. И в Java он не реализован и не будет. Об этом я и говорю. Вместо этого в джаве вводится новая переменная — такого синтаксиса в Котлине нет.

  • Java 16 — новые синтаксические возможности языка
    +1

    Согласен, написано немного запутано.

  • Java 16 — новые синтаксические возможности языка
    0

    Байткоду-то какая разница? В байткоде это тоже может быть две области. Байткод тут ни при чём.

  • Java 16 — новые синтаксические возможности языка
    +9

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


    Возможность наследования убила бы инварианты рекордов. Например, совершенно непонятно как правильно автоматически сгенерировать equals для рекорда, если его можно наследовать. Ломбок не заморачивается семантикой и дизайном языка, он просто пихает фичи. Ломбок как раз является синтаксическим сахаром в отличие от рекордов, которые несут семантическую нагрузку.

  • Java 16 — новые синтаксические возможности языка
    +3

    Это не стандарт, а соглашение. Стандарт говорит "Accessor methods can have arbitrary names" (JavaBeans 1.01a, 7.1). В разделе 8.3 действительно описывается именование на get/is, но в разделе 8.2 ещё раз подчёркивается "However, within Java Beans the use of method and type names that match design patterns is entirely optional".


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

  • Java 16 — новые синтаксические возможности языка
    +1

    Тогда вам совсем вынесет мозг такой пример:



    Здесь область видимости переменной паттерна состоит из двух несвязанных кусков, разделённых телом if'а.

  • Java 16 — новые синтаксические возможности языка
    +5

    На мой взгляд, это слишком легкомысленное замечание. Во-первых, речь не только о сахаре. Например, рекорды — это модельная сущность, nominal tuple, тип-произведение, если хотите. Это штука с сильной семантикой, а не просто синтаксический шорткат. Во-вторых, "взяли из Котлина" — это просто неверно. Синтаксически эти штуки непохожи на Котлин, а, например, instanceof patterns вообще в Котлине прямого аналога не имеют. У Котлина иной путь — flow typing, который в Java никто тащить не собирается. Sealed types — это больше не фича языка Java, а фича виртуальной машины: проверка иерархии делается на уровне VM, и там надо было аккуратно поработать с раздельной компиляцией и т. д. И теперь как раз котлиновские sealed-типы адаптируют, чтобы они были sealed-типами на уровне JVM. И, кстати, sealed-интерфейсов в Котлине не было, и теперь их затаскивают в Котлин из Java. Тоже берут сахар? Даже текстовые блоки синтаксически похожи совсем не на Котлин (где они плохо сделаны), а на Swift. За каждой из этих фич годы исследований и дизайна, а не просто "давайте сделаем как в языке X".

  • Java 16 — новые синтаксические возможности языка
    +1
    Обратите внимание, что методы чтения именуются не стандартным для Java способом.

    Хм. String.length(), Collection.size(), Process.pid(), Process.exitValue(), Runtime.availableProcessors(), Runtime.freeMemory(), ThreadGroup.activeCount() и т. д. Я бы не сказал, что префикс get — это прямо "стандарт".

  • Java 16 — новые синтаксические возможности языка
    0
    java  --enable-preview --source 16 Outer.java 
    Inner_1
    jdk16.Outer$Inner$StaticClass@6b67034
    Point[x=1, y=2]

    А зачем здесь preview? В Java 16 это стандартная фича.

  • Java 16 — новые синтаксические возможности языка
    +1

    Никто нигде никогда не обещал, что в цепочках if-else будет анализ на exhaustiveness. Он планируется в switch, когда там прикрутят паттерны. Но пока этого нет.

  • Java 16 — новые синтаксические возможности языка
    +1

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

  • Анбоксинг в современной Java
    +1
    Мне практически нигде и никогда за последние, скажем так, три года не было нужды писать

    Хм. Удивительно. А мне довольно часто приходится писать и читать такие циклы. Видимо, задачи сильно разные.

  • Анбоксинг в современной Java
    +1

    Это всё долгий и отдельный разговор, но


    И пока что мне ещё никто не ответил, как в Kotlin решаются проблемы с Entity или как сделать билдер, или как преобразовать неизменяемый объект в билдер, а потом из билдера получить новый объект. Или ещё 100500 юскейсов которые отрабатывает Lombok.

    В Котлине билдеры не нужны вообще. Для этого есть copy.

  • Анбоксинг в современной Java
    +1

    Разработчики языка не равны пользователям языка. Ну и насчёт большинства ещё неизвестно.

  • Анбоксинг в современной Java
    +2

    У forEach другие проблемы.

  • Анбоксинг в современной Java
    +6

    Это последний пункт.

  • Анбоксинг в современной Java
    +5

    Такого не будет, не переживайте.

  • Анбоксинг в современной Java
    +2

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

  • Анбоксинг в современной Java
    0

    Какие недостатки вы видите?

  • Анбоксинг в современной Java
    0
    То, что EliminateAutoBox оптимизация здесь сработала, скорее, повезло

    Может повезло, а может и специально такие сценарии обрабатывали.


    не предоставив сопоставимую по скорости альтернативу :(

    Думаю, можно создать свою тривиальную обёртку, если где-то необходимо работать с боксами, а Integer.valueOf не дожимает производительность.

  • Меня перевезли в другую страну и через две недели выставили на мороз — потому что передумали нанимать
    +3

    Кажется, для этого до сих пор надо сходить в офис МТС и подключить международный роуминг. Если человек не выезжал раньше, то мог не знать. Конечно, стоило погуглить, но кто ж знал. У меня так несколько знакомых напарывались в свою первую загранпоездку.

  • Маленькие оптимизации в Java 9-16
    +2

    Переходите на Java 15!

  • Как будет выглядеть программирование в 2025 году?
    0

    Вера в супер-пуперские AST-преобразования, конечно, серьёзная. Мы вот в Java уже больше 15 лет имеем Structural search & replace, который делает пользовательские AST-преобразования и весьма неплохо. Но я не представляю, чтобы миграция между несовместимыми фреймворками описывалась через него. Там всегда куча именно семантических краевых случаев, которые идеально не покроешь. Если вслепую массово применить к большой кодовой базе, посадишь пачку загадочных багов, которые потом запаришься отлаживать. Тем более в языке без статической типизации.

  • IntelliJ IDEA: Structural Search & Replace
    0

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

  • JPoint 2020: новый формат, новые возможности
    +1

    Не уверен.