За что вы любите Java/JVM?
Final Results
49%
Простой и читабельный язык
35%
Безопасность, сложно выстрелить в ногу
29%
Продвинутая JVM
73%
Мощная экосистема. Много библиотек и фреймворков
56%
Крутой инструментарий (IDE, профайлеры и т.д.)
36%
Кроссплатформенность
21%
Производительность
60%
Большое сообщество, много вакансий
28%
Возможность выбрать другой JVM-язык
23%
Обратная совместимость
This media is not supported in your browser
VIEW IN TELEGRAM
🙏 Заключительная речь Себастьяна Дашнера на вчерашней конференции SnowOne
❤20👏8🔥3🤔1
Замечали ли вы, что при отладке Java-приложений Step Over иногда может работать дико медленно? Ставите брейкпоинт на некоторой строке, потом шагаете по строкам, нажимая много раз F8, и бац, на каком-то из методов дебаггер тупо встаёт и долго не возвращается из метода. Иногда ждать приходится так долго, что проще убить процесс и начинать всё дебажить заново.
Некоторые могут начать винить в этом «кривую IDE», но это ограничение самой JVM. Абсолютно то же самое будет наблюдаться, если вы будете делать Step Over через jdb. Дело в том, что когда виртуальной машине шлётся команда StepRequest, то она полностью переключается в режим интерпретатора. Если метод большой и вызывает много-много других методов, то интерпретация может занять очень длительное время.
Какой выход из данной ситуации? Смириться, ведь это ограничение JVM. Но есть один простой трюк, который можно применять: использовать не Step Over (F8), а Run to Cursor (Alt + F9). Вы просто ставите мышь на следующую строку и нажимаете Alt + F9, потом опять на следующую строку и так столько раз, сколько нужно. Чуть-чуть неудобно, но если привыкнуть, то вполне рабочий вариант.
Кстати, вы можете спросить, а почему, например, IDEA так не делает по дефолту? Можно же бы было (просто) сделать так, чтобы IDEA автоматом ставила брейкпоинты на следующих строках, и всё бы летало? На самом деле, проблема в том, что в таком случае могут начаться проблемы с concurrency: какой-то поток может прийти в эту строку раньше, чем тот поток, на котором вы сейчас находитесь. А Step Over гарантировано продолжит работу в текущем потоке. Это безопаснее.
Думаю, можно бы было замутить какие-нибудь умные брейкпоинты с условиями, которые запоминали бы ID текущего потока, а потом вставало бы только, если ID совпадает. Но пока ни у кого руки не дошли.
P.S. Отладку ещё может сильно замедлять галочка “Show Method Return Values” в Debug View. Она отключена по умолчанию, но вы её могли случайно включить и забыть отключить.
#debug #intellijidea
Некоторые могут начать винить в этом «кривую IDE», но это ограничение самой JVM. Абсолютно то же самое будет наблюдаться, если вы будете делать Step Over через jdb. Дело в том, что когда виртуальной машине шлётся команда StepRequest, то она полностью переключается в режим интерпретатора. Если метод большой и вызывает много-много других методов, то интерпретация может занять очень длительное время.
Какой выход из данной ситуации? Смириться, ведь это ограничение JVM. Но есть один простой трюк, который можно применять: использовать не Step Over (F8), а Run to Cursor (Alt + F9). Вы просто ставите мышь на следующую строку и нажимаете Alt + F9, потом опять на следующую строку и так столько раз, сколько нужно. Чуть-чуть неудобно, но если привыкнуть, то вполне рабочий вариант.
Кстати, вы можете спросить, а почему, например, IDEA так не делает по дефолту? Можно же бы было (просто) сделать так, чтобы IDEA автоматом ставила брейкпоинты на следующих строках, и всё бы летало? На самом деле, проблема в том, что в таком случае могут начаться проблемы с concurrency: какой-то поток может прийти в эту строку раньше, чем тот поток, на котором вы сейчас находитесь. А Step Over гарантировано продолжит работу в текущем потоке. Это безопаснее.
Думаю, можно бы было замутить какие-нибудь умные брейкпоинты с условиями, которые запоминали бы ID текущего потока, а потом вставало бы только, если ID совпадает. Но пока ни у кого руки не дошли.
P.S. Отладку ещё может сильно замедлять галочка “Show Method Return Values” в Debug View. Она отключена по умолчанию, но вы её могли случайно включить и забыть отключить.
#debug #intellijidea
👍19🤩2
На конференции SnowOne Иван Крылов прочитал полезный доклад «От Java 11 к Java 17». Правда в одном месте он сказал весьма странную вещь относительно hashCode(), на которую я бы хотел обратить внимание.
Во-первых, что если не переопределить hashCode(), то хеш-код объекта будет якобы получаться в результате хеширования адреса объекта, поэтому такой хеш-код будет плохого качества. Уж не знаю, почему Иван, который пол жизни занимается компиляторами и JVM, работал в Oracle и участвовал в разработке HotSpot, сказал такое :), но всё-таки важно опровергнуть сказанное.
Хеш-код по дефолту вычисляется как случайное число при первом вызове и в дальнейшем сохраняется в заголовке объекта. Такое поведение существует очень давно, с Java 6 точно, возможно ранее (копать не стал).
По этому поводу Андрей Паньгин ещё в 2013 году написал статью на Хабре, где возмущался, что многие продолжают считать, что там используется адрес. Во всём была виновата старая документация к Object, где написано следующее:
This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.
(Но даже здесь, как видите, написано, что это “not required”)
Это предложение исправили лишь в Java 9:
The hashCode may or may not be implemented as some function of an object's memory address at some point in time.
В Java 12 решили упоминание адреса убрать совсем, оставив только ту часть, где написано, что возвращаются “distinc integers”.
Второе странное утверждение было в том, что hashCode() лучше переопределять и считать его на основе полей. Ну так это ведь от задачи зависит, разве нет? А если мне нужно сохранить identity? Тогда нужно использовать дефолтный hashCode(). Если же нужно отсутствие identity, то тогда надо переопределять и считать на основе полей. Логика абсолютно бинарная, тут нет никаких «лучше или хуже»: нужен identity – дефолтный хеш-код, не нужен identity – хеш-код на основе полей.
#hashcode
Во-первых, что если не переопределить hashCode(), то хеш-код объекта будет якобы получаться в результате хеширования адреса объекта, поэтому такой хеш-код будет плохого качества. Уж не знаю, почему Иван, который пол жизни занимается компиляторами и JVM, работал в Oracle и участвовал в разработке HotSpot, сказал такое :), но всё-таки важно опровергнуть сказанное.
Хеш-код по дефолту вычисляется как случайное число при первом вызове и в дальнейшем сохраняется в заголовке объекта. Такое поведение существует очень давно, с Java 6 точно, возможно ранее (копать не стал).
По этому поводу Андрей Паньгин ещё в 2013 году написал статью на Хабре, где возмущался, что многие продолжают считать, что там используется адрес. Во всём была виновата старая документация к Object, где написано следующее:
This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.
(Но даже здесь, как видите, написано, что это “not required”)
Это предложение исправили лишь в Java 9:
The hashCode may or may not be implemented as some function of an object's memory address at some point in time.
В Java 12 решили упоминание адреса убрать совсем, оставив только ту часть, где написано, что возвращаются “distinc integers”.
Второе странное утверждение было в том, что hashCode() лучше переопределять и считать его на основе полей. Ну так это ведь от задачи зависит, разве нет? А если мне нужно сохранить identity? Тогда нужно использовать дефолтный hashCode(). Если же нужно отсутствие identity, то тогда надо переопределять и считать на основе полей. Логика абсолютно бинарная, тут нет никаких «лучше или хуже»: нужен identity – дефолтный хеш-код, не нужен identity – хеш-код на основе полей.
#hashcode
👍17🤔3
А давайте небольшой квиз, но без вариантов ответов.
Почему
Пишите свои ответы в комментах.
Почему
java.lang.String не станет value-классом?Пишите свои ответы в комментах.
Итак, правильного ответа по поводу String не прозвучало, поэтому озвучиваю его сам.
Были очень близкие ответы вроде того, что все привыкли, что String имеет identity, поэтому много кто на это завязался. Но в реальности таких людей на самом деле не очень много. Вот вы сами где-нибудь синхронизовались на строках в своих проектах или закладывались на то, что new String("hello") != "hello"? Я вот ни разу. Может, кому-то такое изменение и поломает логику, но если по-честному, то эти люди сами виноваты, что написали такой кривой код.
В другом озвученном ответе было то, что если String станет value-классом, то оператор == будет сравнивать объекты на основе полей, а в String есть поля, которые считаются лениво. Но это не является существенным препятствием, т.к. для String можно было бы кастомизировать поведение оператора == в виртуальной машине и просто не учитывать поля hash и hashIzZero (всё равно ведь оператор == теперь виртуальная функция, ну расширим табличку, добавив специальный случай для String).
Короче, все эти препятствия можно было бы худо-бедно обойти, но вот следующую проблему решить никак нельзя: оператор == больше не будет выполняться за константное время (ведь теперь строки придётся сравнивать по содержимому, а не просто сравнивать ссылки). В мире существует очень много кода, где строки сравниваются через ==. Весь этот код станет тормозить на длинных строках, потому что каждое сравнение станет O(N).
Разработчики JVM никогда не пойдут на изменение, результатом котором станет алгоритмическое замедление одной из базовых операций на одном из самых главных классов стандартной библиотеки.
#string #valhalla
Были очень близкие ответы вроде того, что все привыкли, что String имеет identity, поэтому много кто на это завязался. Но в реальности таких людей на самом деле не очень много. Вот вы сами где-нибудь синхронизовались на строках в своих проектах или закладывались на то, что new String("hello") != "hello"? Я вот ни разу. Может, кому-то такое изменение и поломает логику, но если по-честному, то эти люди сами виноваты, что написали такой кривой код.
В другом озвученном ответе было то, что если String станет value-классом, то оператор == будет сравнивать объекты на основе полей, а в String есть поля, которые считаются лениво. Но это не является существенным препятствием, т.к. для String можно было бы кастомизировать поведение оператора == в виртуальной машине и просто не учитывать поля hash и hashIzZero (всё равно ведь оператор == теперь виртуальная функция, ну расширим табличку, добавив специальный случай для String).
Короче, все эти препятствия можно было бы худо-бедно обойти, но вот следующую проблему решить никак нельзя: оператор == больше не будет выполняться за константное время (ведь теперь строки придётся сравнивать по содержимому, а не просто сравнивать ссылки). В мире существует очень много кода, где строки сравниваются через ==. Весь этот код станет тормозить на длинных строках, потому что каждое сравнение станет O(N).
Разработчики JVM никогда не пойдут на изменение, результатом котором станет алгоритмическое замедление одной из базовых операций на одном из самых главных классов стандартной библиотеки.
#string #valhalla
👍10
JavaRoadmap.jpg
1.4 MB
Roadmap для разработчика Java в 2022 году. Узнали? Согласны?
Можно распечатать и повесить в кабинете.
Сорец
Можно распечатать и повесить в кабинете.
Сорец
👍13🤔3😱1
Роман Кеннке сообщил в рассылке, что проекту Lilliput удалось достичь 64-битных заголовков в JDK (в обычной версии JDK они занимают 96 или 128 бит). Билды Лиллипута можно тестировать уже прямо сейчас.
Следующий шаг - заголовки размером 32 бит.
Кстати, если вдруг вам хочется иметь 64-битные заголовки в продакшене, то можете просто использовать 32-битную JDK.
#lilliput
Следующий шаг - заголовки размером 32 бит.
Кстати, если вдруг вам хочется иметь 64-битные заголовки в продакшене, то можете просто использовать 32-битную JDK.
#lilliput
👏11👍1
Марк Рейнольд предложил переименовать домен openjdk.java.net в openjdk.org. Потому что родительский домен java.net сбивает с толку и вообще был закрыт в 2017 году.
🔥7
🥳 Виртуальные треды попали в mainline JDK. И они уже присутствуют в ранней сборке JDK 19 build 22.
Так что уже можете скачивать и экспериментировать.
#loom #java19
Так что уже можете скачивать и экспериментировать.
#loom #java19
🔥14🎉3
Ежегодный опрос. Какую версию(-и) Java или язык JVM вы используете в продуктовом окружении и в разработке?
Final Results
1%
Java 7 или более старую
28%
Java 8
60%
Java 11
6%
Java 12-16
30%
Java 17
2%
Java 18
5%
Groovy
4%
Scala
16%
Kotlin
1%
Clojure
Забавная ситуация наблюдается с релизом JDK 19: почти все JEP'ы в них либо превью, либо инкубатор. То есть будет много новых фич, но все они только для того, чтобы поиграться, но не для продакшена. Из стабильных только JEP 422: Linux/RISC-V Port, но я не думаю, что кто-то из читателей этого канала использует такую архитектуру. Все остальные JEP'ы нестабильные:
JEP 405: Record Patterns (Preview)
JEP 424: Foreign Function & Memory API (Preview)
JEP 425: Virtual Threads (Preview)
JEP 426: Vector API (Fourth Incubator)
JEP 427: Pattern Matching for switch (Third Preview)
Также возможно успеет попасть JEP 428: Structured Concurrency (Incubator), и он тоже инкубатор.
PS. Зато нас похоже ждёт вкусный LTS-релиз Java 21, где будет стабильный Loom, паттерн-матчинг и FFI.
#java19
JEP 405: Record Patterns (Preview)
JEP 424: Foreign Function & Memory API (Preview)
JEP 425: Virtual Threads (Preview)
JEP 426: Vector API (Fourth Incubator)
JEP 427: Pattern Matching for switch (Third Preview)
Также возможно успеет попасть JEP 428: Structured Concurrency (Incubator), и он тоже инкубатор.
PS. Зато нас похоже ждёт вкусный LTS-релиз Java 21, где будет стабильный Loom, паттерн-матчинг и FFI.
#java19
❤9😱1
Результаты опроса по версиям Java и языкам. Проценты красным и зелёным - относительно прошлого 2021 года.
Пара выводов. Во-первых, Java 8 впервые больше не самая популярная версия (в прошлом году она была чуть-чуть выше Java 11), а самая популярная теперь Java 11. Во-вторых, Java 17 приятно удивила и перегнала даже Java 8, отбросив ту на третье место.
#java8 #java11 #java17
Пара выводов. Во-первых, Java 8 впервые больше не самая популярная версия (в прошлом году она была чуть-чуть выше Java 11), а самая популярная теперь Java 11. Во-вторых, Java 17 приятно удивила и перегнала даже Java 8, отбросив ту на третье место.
#java8 #java11 #java17
🔥6👍3😢2
🥳 Сегодня нашей любимой Джаве исполняется 27 лет. Её первая публичная версия вышла 23 мая 1995 года.
🎉20❤3🔥1
JetBrains хочет убить старый добрый интерфейс полностью изменить интерфейс IntelliJ IDEA. Как вам?
(В комментах некоторые пользователи уже накидали говна).
#IntelliJIDEA
(В комментах некоторые пользователи уже накидали говна).
#IntelliJIDEA
👎28💩8👍7🤮1