Comments 16
Жду 3 часть! Спасибо!
То есть, причина слова static в исходниках - неспособность старых JDK самостоятельно разобраться, что куда класть?
не понял вопрос)
Пардон, я имел в виду что в Java ручками делалось - и продолжает делаться - то, что с новыми языками оказалось автоматизировано.
Ну вот в котлине нету такого слова (я в курсе о @JvmStatic). Котлин не задействует часть рантайма JVM - или самостоятельно понимает, что во что компилировать?
Если мне не изменяет память, то под капотом Kotlin все равно проставляет static поля, но в котле это слово не вынесено и не пишется(за исключением как раз @JvmStatic), чтобы переложить это на JVM, то есть меньше ручных ошибок и другой уровень абстракции)
Да какая тут автоматизация? Просто немного другой синтаксис и немного другие умолчания. Типа того, что помечаем inner class-ы, вместо того чтобы помечать static class-ы. Аналогичная история с компаньонами и просто объектами.
В мире, который медленно глупеет, переходя к вайбкодингу, все это ещё кому то нужно?
JPMS не спрашивают?
Куча не всегда делиться на поколения. Это зависит от выбранного GC. Например, если взять тот же Shenandoah — он выполняет сборку мусора по регионам, без деления на поколения.
Согласен с вами, тут самый частый вариант это именно битье)
Shenandoah тоже поколенческий сборщик. Единственный кто временно был не таким это ZGC, но и тому в итоге сначала добавили опционально включение поколений, а потом перевели полностью из-за сложностей в поддержки двух моделей. Деление по регионам характерно для всех параллельных сборщиков, при этом сами регионы все ещё принадлежат поколениям.
Бесполезные знания, которые передаются от отца к сыну.
JVM + Память + GC без боли: моя шпаргалка для собесов в Java. Часть 2